Re: [TLS] three ECHO issues

[Christopher Wood <[e-mail]>]

Thanks for raising these issues! Please see inline below.

On 8 Mar 2020, at 8:18, Stephen Farrell wrote:

> 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;-)

We kept maximum_name_length so as to not change “too much” in the 
PR. As this is orthogonal to the overall change, it can be addressed 
separately. Can you please file an issue and propose text?

>
> 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;-)

Yes, this will be a pain to implement. But variance between the inner 
and outer CH is permitted, and indeed a goal.

> 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:-)

Can you elaborate on why it’s ugly? What could we do differently? Text 
suggestions are welcome!

Thanks,
Chris