Hiya,
Since I was logged into the github web site (as happens occasionally but not often) and as requested at the TLS session, I translated the text below into github issues in the hope that they might be included in discussion. Links to each below. On 28/02/2021 17:34, Stephen Farrell wrote:
Hiya, I've just got my OpenSSL code "working" for draft-09. The s_client and s_server talk to one another and do ECH; NSS's tstclnt talks to my s_server and does ECH and my s_client talks to cloudflare's test server and does ECH. So this can be made work, which is the good news. (Thanks to Martin Thomson and Chris Patton for help in getting that done btw.) Note that the scare quotes on "working" above are because the code I have now is horrible and needs a lot of re-factoring but I'm not keen on doing that yet if we're considering further breaking changes that might add more horror;-) I have the following specific comments having done this: - This is *much* harder to implement compared to ESNI as it interacts with the rest of the TLS stack/library in many more ways. It should be an explicit goal to reduce that complexity IMO and not increase it further. That complexity leads to *many* new failure modes that not everyone will get right, e.g. incorrect encoding of inner extensions, extension handlers that have side-effects being called twice etc. - Possible fix: organise an interim session (or slot therein) with the explicit and only goal of simplifying ECH. - Possible fix: publish test vectors and require a test vector from anyone proposing any new construct, before accepting their suggested new crypto-wrinkle. - Possible fix: make the spec much more explicit about what goes into the transcript at every possible stage, esp when that changes.
https://github.com/tlswg/draft-ietf-tls-esni/issues/401
- Including the client-sender's ephemeral public key in the AAD means clients cannot use a single-shot HPKE API. That then means that the client key pair has to be separately generated and held onto until HPKE encryption. It'd be a good bit better and simpler were that not the case and a single shot HPKE encrypt API could be used witout exposing that key pair to the stack. - Possible fix: having a value linked to the inner plaintext could suffice maybe?
https://github.com/tlswg/draft-ietf-tls-esni/issues/397
- The SH.random magic confirmation value interacts with ticket handling on the server in some ways I don't yet understand fully. Messing with the lower 8 octets there also breaks internal OpenSSL APIs for handling packets but so do other parts of ECH, so that might be fixable. - Possible fix: re-consider the use of SH.random as a signal - ECH sticks out in the outer CH anyway, so maybe return an ECH in the SH with a value that does the same trick so the observer can't tell from the SH if it was a successful use of ECH, grease or a failure in ECH.
https://github.com/tlswg/draft-ietf-tls-esni/issues/399
- There's no simple, sensible way to decide which extensions to "compress" in the inner that I can see. As a library, one could come up with some vastly complex API to allow applications pretend to handle this, but that'd seem more dangerous than useful. While I made the code generic, it's not at all clear that'll ever be useful. - Possible fix: forget generic compression and define a small set of extension types that can be inherited from the outer with all others being present as needed in inner and outer. For future extensions (e.g. some many-octet PQ key agreement), have the extension definition include the option of "see outer" within the extension encoding.
https://github.com/tlswg/draft-ietf-tls-esni/issues/398
- Given inner and outer can have different sets of extensions, I guess there'll never be a way to make ECH handling constant-time. If so, then that ought be covered as a security consideration. If not, how'd that work? - Possible fix: document potential consequences of ECH never being constant time?
https://github.com/tlswg/draft-ietf-tls-esni/issues/400
- I don't plan on implementing the "MUST check outer.sni==public_name" check ever really. (Unless forced to as part of upstreaming maybe.) - Possible fix: remove that MUST.
https://github.com/tlswg/draft-ietf-tls-esni/issues/396 Cheers, S.
- I've not implemented padding, nor attempted to make greasing as complex as called for, so don't yet have comments on those features as they are in -09. There are probably other times when coding this up where I swore at the spec text but I've forgotten so maybe those weren't so bad in the end:-) Cheers, S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
