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.
- 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?
- 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.
- 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.
- 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?
- 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.
- 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.
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
