Use the DTLS ClientHello structure in ECH with DTLS #640
Conversation
This PR implements the option if we decide to use DTLS's ClientHello as the payload and AAD, rather than somehow fit TLS's in there. Fixes tlswg#639.
|
NB: This option means needing to reason about injectivity. But the first two bytes of a DTLS ClientHello are different, so I think we're alright on that front? (Although nothing is stopping someone from sending 0xfefd in the legacy version of a TLS ClientHello, so... 🤷 |
I can now report that there is at least one implementation. 🙂 Possibly two if NSS had already done it before all this. Also our Go testing stack if you count that one, but that stack is weird. It was a lot of chasing down of the TLS vs DTLS header (our DTLS stack carries the old style header around because it was the way you spelled it in 1.2), and making sure all the ClientHello processing bits picked up the right now. But nothing fundamentally hard. Just more ways that we pay for DTLS 1.2's sins. |
|
I believe this is the correct resolution. @seanturner @jsalowey @dconnolly are you OK with merging it? |
|
Also got #641. 😞 |
This PR implements the option if we decide to use DTLS's ClientHello as the payload and AAD, rather than somehow fit TLS's in there.
Fixes #639.
I haven't yet gotten this working for BoringSSL (probably will finish that after the holiday), but I suspect this is the more straightforward option for us. @martinthomson what has NSS implemented / would be more convenient for NSS?