Hiya,
On 30/04/2022 10:05, Ilari Liusvaara wrote:
On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote: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.)I don't think compression method like ECH uses would work here.
Possibly so. But I don't think we want two potentially interacting compression hacks do we? My main point is that this draft isn't yet in a place where all one needs later is codepoint registrations and PQ alg implementations. I think this aspect demonstrates that lack of readiness, no matter how one resolves compressing, unless one never compresses, which seems undesirable to me.
However, I did come up with compression method:
1) Sub-shares in CH may be be just replaced by a group id (two octets).
The replacements can be deduced from length of the whole share.
2) First sub-share copies from first octets of share for the designated
group.
3) Second sub-share copies from last octets of share for the designated
group.
This can be decoded regardless of if the sever knows what the referenced
groups are. The compression can also never run into loop, as recursive
references are not allowed.
So for example, if one wants to send x25519, p256, x25519+saber and
p256+saber, one can do that as:
- x25519: <x25519 share> (32+4 octets)
- p256: <p256 share> (65+4 octets)
- x25519+saber: <x25519 id><saber share> (2+992+4 octets)
- p256+saber: <p256 id><x25519+saber id> (2+2+4 octets)
Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression
itself.
So yes that could work. We'd need to think through how it'd interact with the ECH scheme were both to end up standardised.
- 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;-)No. The private key is held by the client, and client sends the public key to use in its client hello. Furthermore, every connection should use different public key.
Ok. (Sorry I was looking at [1] too and had that in my head when writing the above, which ought be ignored as mine was a silly comment:-)[1] https://datatracker.ietf.org/doc/html/draft-perret-prat-lamps-cms-pq-kem
- 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:-)Whatever public key the keygen() operation outputs.
As above.
- 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.Well, avoiding HRR impiles that client is willing to bloat its client hello even for servers that do not support PQ. And for such clients, using PQ at all requires servers to priorize it (send HRR even if acceptable share is present).
I don't understand the above sorry;-) ISTM one would need to analyse/guess what'll happen with this scheme and HRR before being done. Maybe someone's done that but if so, I'm surprised there's no mention in the draft.
- 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.Just yeet McEliece. Its keys are just too large for it to be practical in TLS, even if the keys did not bust hard limits. After removing McEliece from consideration, all the finalists and alternates can trivially be supported (albeit FrodoKEM busts some soft limits).
Nonetheless, this is another respect in which the draft text has to remain incomplete because we're IMO progressing it too soon.
- 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 thatI think that having recommended = Y for any combined algorithm requires NIST final spec PQ part and recommended = Y for the classical part (which allows things like x25519 to be the classical part). That is, using latest spec for NISTPQC winner is not enough. This impiles recommended = Y for combined algorithm is some years out at the very least.
I agree, and something like the above points ought be stated in the draft after discussion in the WG. Cheers, S.
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.)The intuition is that if you concatenate the shared secrets and feed the result to a KDF, unless the KDF is really broken, predicting the output is going to require predicting both shared secrets. There is no similar intuition for TLS 1.1 and earlier hash combiner. Just running the same data through both would give something that turns out to be as strong as SHA-1, but the combiner does not do that. It instead does something else that is cryptographically completely unsound. I am bit surprised I never saw anyone claim that the TLS 1.0 and TLS 1.1 (IIRC, I checked that the combiner had not been inherited from SSLv3) hash combiner was a backdoor. I have seen much less weird things called backdoors.- 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 guessThe keygen() operation is defined by the generic KEM model, which NISTPQC uses. So all the candidate specifications define what the keygen() operation does. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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
