While reviewing this myself I realised the server DTLS cookie support I implemented is far too naive. Have marked as draft until I have time to improve it.

Codecov Report

Attention: Patch coverage is 95.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 98.56%. Comparing base (dc8daad) to head (ac751f1).
Report is 5 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17441   +/-   ##
=======================================
  Coverage   98.56%   98.56%           
=======================================
  Files         169      169           
  Lines       21948    21968   +20     
=======================================
+ Hits        21633    21653   +20     
  Misses        315      315           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64: +2400 +0.281% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2: +1304 +0.142% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

• The current session cookie algorithm is too naive and doesn't achieve the purpose of HelloVerify (and can be used to DoS the server by creating too many cookies). It should be updated along the lines of the suggestion in the DTLS specification (Cookie = HMAC(Secret, Client-IP, Client-Parameters)).

This is a lot harder than I initially thought, because in MicroPython modmbedtls works with an abstract stream and doesn't have any knowledge of the client IP. Also, adding this will probably add even more code size. But what's currently in this draft is woefully inadequate.

There's two possible ways forward:

1. Add another Python API extension, so the server code does something like s = ctx.wrap_socket(s, server_side=1, client_cookie=hmac_result) or s = ctx.dtls_wrap_socket(...). This offloads the responsibility (and code size cost) for calculating a secure cookie to Python code (and we could provide a sample implementation or a thin wrapper in micropython-lib that does it correctly). The server code can choose to pass a constant string here, at the cost of potentially becoming a DDoS vector if exposed to untrusted clients.
2. Drop DTLS server support, support DTLS client only. This makes testing a little harder as we'll need a DTLS server endpoint, but a simple no-op server should be easy enough to stand up (and safe to stand up on the public internet if it implements Hello Verify!)

Leaning towards (2) at the moment because I think the use case for DTLS client in MicroPython is much stronger than the case for needing a DTLS server, but that would mean removing functionality that was in v1.25 (albeit not fully compliant in that version). @keenanjohnson you implemented the original DTLS support in #15764, do you have any thought about this?

In regards to your question @projectgus , I personally don't see a lot of use for the DTLS server on an embedded device. However, I do think that having the server implemented in micropython does make the unit testing vastly less brittle. Every time I have tied unit tests to some sort of live public service (like you suggest in option 2), I have personally regretted the choice in the long run as it tends to be brittle, people start to encounter all sorts of spurious local test failiures, etc etc.

Given that our main usecase for the server is just unit tests, I feel like moving the cookie calculation to python isn't the worst as long as we caveat the potential for a DDOS in the docs or something in case anyone ever comes along and has a real use case for the server.

Thanks for thinking of me and great work on the project as always.

Attention: Patch coverage is 95.00000% with 1 line in your changes missing coverage. Please review.

The line missing coverage here will only be hit if a heap allocation fails part-way through setting up the SSL context, not an easy code path to cover with unit testing.