Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Stephen Farrell <[e-mail]>]

Hiya,

On 27/04/2022 16:27, Christopher Wood wrote:
> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, located here:
> 
>     https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

As I guess I've said before, I think progressing this draft
now, even with this WGLC-then-park approach, is premature.

However, I seem to be in the rough on that so can live with
this ad-hoc process (teeth grinding mind you:-) so long as we
park this for a sufficient period *and* are open to changing
anything at the end of the parking-lot period.

Even so, I think this is not yet ready for any such ad-hoc
parking-lot:

- section 1.5 implies a wish to reduce the number of
octets sent - ECH creates a way to point from one part
of the (encrypted, inner) ClientHello to another (the
outer ClientHello). I don't think we want two such
mechanisms, or one mechanism defined in ECH but none at
all here, or even worse a second method. For me, that
implies not "freezing" the structural work here 'till
we see if ECH gets widespread deployment at which point
we should consider re-use of the ECH mechanism. (Or maybe
even consider both cases of re-using octets and invent
another thing, but not 'till we see if ECH gets traction.)

- section 2: if "classic" DH were broken, and we then
depend on a PQ-KEM, doesn't that re-introduce all the
problems seen with duplicating RSA private keys in
middleboxes? If not, why not? If so, I don't recall
that discussion in the WG (and we had many mega-threads
on RSA as abused by MITM folks so there has to be stuff
to be said;-)

- similar to the above: if PQ KEM public values are
like RSA public keys, how does the client know what
value to use in the initial, basic 1-RTT ClientHello?
(sorry if that's a dim question:-) If the answer is
to use something like a ticket (for a 2nd connection)
then that should be defined here I'd say, if it were
to use yet another SVCB field that also ought be
defined (or at least hinted at:-)

- I'm also HRR-confused - if we don't yet know the
details of the range of possible PQ KEM algs we want to
allow here, how do we know that we almost always continue
to avoid HRR in practice and thus benefit from a mixture of
classic and PQ algs? (It's also a bit odd that HRR,
much as I dislike it, doesn't get a mention here;-) I
think the problem is that we don't want HRR to push a
client back to only "classic" groups, if the client but
not the server is worried about PQ stuff while both
prioritise interop.

- section 4: if this cannot support all NIST finalists
due to length limits then we're again being premature
esp. if NIST are supposed to be picking winners soon.
We'd look pretty dim if we didn't support a NIST winner
for this without saying why.

- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and
that needs to be in this draft before it even gets
parked. Regardless of whether or not the WG agree with
me on that, I think the current text is missing stuff
in this section and don't recall the WG discussing that

Nits etc below:

- TLS1.1 and earlier mixed hash functions when deriving
keys on the basis of then-suspected weaknesses in MD5, yet
there were arguments made that that ad-hoc mixing wasn't
useful, so we moved away from that in TLS1.2+. I don't
see an argument or pointer in this draft to a justification
that this (also seemingly ad-hoc?) catenation approach
won't suffer analagous infelicity. Absent that, ISTM trying
to finalise the structural parts of this now may be a
cryptographically bad plan. (Even if in practice that's ok.)

- 1.2: it's longer 2019 - one of the year or tense (of
"include") should change, probably the former given the
idea of parking this for some time

- section 2: the tendency to document APIs (e.g. "KeyGen()")
in protocol documents seems to me a bit of a double-edged
sword - it should help some implementers but OTOH might
mean we fail to consider how implementations with other
internals might perform, so I'd prefer we are more clear
as to how those APIs are optional, but that's really a
matter of style I guess

- section 2: HPKE is now RFC9180

Cheers,
S.