[TLS] three ECHO issues

[Stephen Farrell <[e-mail]>]

Hiya,

Thanks for the new ECHO PR. [1] I think this is the
right direction but I have three issues with how it's
done in the PR right now that I think would benefit
from list discussion before a new I-D is produced or
the PR is merged.

1) Padding. This should be easy but somehow seems to be
hard;-( ISTM the current text is broken as it'd expose
length information about ALPN in the CH and also in the
EncryptedExtensions. I think it'd be good if the list
reached some level of agreement on the goals of padding
here rather than keep making different tweaks that don't
work. I think the goal for padding ought be that we
don't expose information about the content of the inner
CH via the length of any h/s message. If we agree that
(or some similar thing) then hopefully it should be just
a matter of tweaking the algorithm so it works. (I've
raised this before but seemingly not convincingly enough;-)

2) Variance between inner and outer CH. The current
scheme is that almost any variation is allowed. In the
work I've done so far looking at how to code that up,
the trial decryption required becomes a major pain in
the client code as soon as the TLS key-share differs
between inner and outer. I don't know if that affects
other code bases or if that's mostly an OpenSSL thing
but think we ought establish on the list if that level
of flexibility is needed now, or maybe later, or even
never. The cost there is not just working out how to
code it up, but this also creates new complex code
paths that will be rarely executed which is usually a
recipe for sadness later. So, I'd hope other code
bases are checked for this before we merge the PR.
(The problem here could be OpenSSL's internal, eh...
"intricacy" is a polite term I guess, or it could be
me being dim, but it seems real;-)

3) I think we might be better off leaving out the
compression stuff for now, and only figuring that out
later. The current OuterExtensions thing is pretty ugly,
and if the result of (2) above were that we constrain
the variance between inner and outer some more then
a generic compression scheme may not be needed. I do
think we will want some compression thing in the RFC
we end up with, but we might be better off to get
interop without that first and then add compression
later. (That's what I plan to do fwiw, so this is
a less pressing issue for me given I'll be ignoring
it for now:-)

Cheers,
S.

[1] https://github.com/tlswg/draft-ietf-tls-esni/pull/207/files