On 8 Mar 2020, at 10:14, Stephen Farrell wrote:
Hiya,
On 08/03/2020 16:07, Christopher Wood wrote:
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?
Sure. But ECHO vs. ESNI does make a difference here e.g.
due to the ALPN in the inner. If the outcome of (2) below
is to keep the flexibility they may be other extensions
that create length issues, either just in the inner CH
or else there and possibly also in other bits of the h/s.
That said, if the goal I stated above is something on
which everyone's agreed, I'd be happy to craft a PR. But
if that goal is not agreed, then probably any PR I make
won't be useful, hence raising this on the list.
In general I think it’s a fine goal, but I think it’s probably a bit
more challenging to specify this correctly than we might think. Take
ALPN as an example. Servers can’t possibly know what ALPN tokens each
client might offer up in their CH, so how can they express a maximum
limit?
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.
I'm questioning whether that's a good goal or not. In my
analysis of the various extensions, only SNI and ALPN seem
to offer immediate value. Until one gets to new algos,
which may mean PQC, there doesn't seem much more that's
worth supporting really. And when one looks at the level
of complexity to implement generic variance, I'm really
not sure it's worthwhile. That said, I'd hack away at
it as needed if others have taken a look at their code
and found it ok to support. I've just not heard that so
far and am concerned we're trading v, simple text in
the I-D vs. really horribly complex and maybe flakey
code, which doesn't seem like a good plan to me.
Just to be clear: I do like the idea that the analysis
be done on the flexible/full-variance scheme and I also
like the idea of reconstructing a full CH from the
recovered plaintext of the inner CH. Even with all
that though, the ECHO spec can still impose interop
restrictions on inner/outer CH variance to simplify
implementation and make interop easier and more likely.
My guess is that that'd be a worthwhile simplification.
Yep, it can, and that’s something we can tighten down as needed later
on. For example, if we later decide that we never want to duplicate key
shares, we can just make that so. For now, starting general aligns with
the analysis and gives us the flexibility we need to further refine as
needed.
If more variation is needed later (e.g. to help
incremental deployment of PQC algs), then that could
just use a new extension instead of ECHO.
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?
Allowing more than 1 OuterExtensions - that'd break some
code in OpenSSL's generic extension handling. Not sure
how bad that'll be to handle.
Whoops! Good catch. We should remove this paragraph:
Multiple "outer_extension" extensions MAY appear in a ClientHelloInner
(this is a violation of normal TLS rules, but the resulting
ClientHelloInner
is never processed directly). However, there MUST NOT be
multiple "outer_extension" extensions with the same extension code
point.
That’s leftover from a previous version. I’ll do that now.
What could we do differently?
If e.g. we required the same TLS key-share in inner and
outer, then you could just omit most of the octets from
the inner and deterministically reconstruct. With a small
number of such MUSTs, there might be no real need for a
generic compression scheme at all. That's linked to (2)
above though.
If a generic compression is needed, then yes something
ugly will likely be needed, but it could be simple and
ugly, e.g. extension-specific, for those extensions that
would make a difference. (And maybe we could punt on it
too - e.g. require the definition of the PQC stuff to
spec this compression if that's when it actually gets
useful.)
That might work, too. For now, I’d prefer we not get bogged down in
compression as it’s merely an optimization.
Text suggestions are welcome!
Sure. And happy to offer some, but would like to see
guidance from the WG on the mailing list first. (Sorry
for being less github-cooperative about this, but being
logged in there is not my normal state of being:-)
No problem. :-)
Cheers,
Chris
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
