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.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
