Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Again, responding to old emails... > -Original Message- > From: TLS On Behalf Of Stephen Farrell > Sent: Friday, April 29, 2022 8:25 PM > To: TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > - 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;-) Actually, unless the client uses a PQ-KEM private key permanently, no one can do a MITM. It is similar to Diffie-Hellman; the client picks a key share; the server picks a response key share; the both derive the same shared secret. The draft allows (but does not encourage) the reuse of KEM private values (and while it must limit the reuse to what the specification of the KEM allows, in practice, that's not a restriction). Should we modify the draft to forbid reuse? Kyber public/private key generation is fast enough to make this practical. Looking through the TLS 1.3 RFC, I don’t see any text addressing the reuse of ECDHE private values; is that implicit by the definition of DHE? I do see in the text "If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret."; that wording would imply the possibility of not using a fresh (EC)DHE key for each exchange... > > - 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:-) Actually, it's the client that selects the KEM public key. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On 8/11/2022 1:54 PM, Benjamin Kaduk wrote: On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote: Isn't the ANIMA WG working on these scenarios? If there is a formal "enrollment" process for adding a device to a network, that process could include setting the time, and possibly performing updates. I say "possibly" here, because in scenarios like "disaster recovery", the local network may not have global connectivity. But even so, setting the time during enrollment seems logical. https://www.rfc-editor.org/rfc/rfc8995.html#section-2.6 seems to already have some discussion of how to handle the lack of a(n accurate) real-time clock, yes. There is a bit of a missed opportunity here. That section explains how to perform enrollment despite not having a good notion of time on the device, but it does not explain how the device could use enrollment to reset its clocks. Maybe that's obvious and I am just missing it. For example, the device will get some notion of time from the dates in the certificates that are provisioned during enrollment. Maybe that's enough to move from the 10 years scenario to the one year scenario, and then call NTP. But it would probably be better to spell it out. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Why both X25519+Kyber512 and P256+Kyber512? Because there are good HW implementations supporting P256, and (at least for some people) it’s good enough? smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Why both X25519+Kyber512 and P256+Kyber512? Note that Anything+Kyber512, in particular X25519+Kyber512, will be FIPS certifiable after NIST standardized Kyber512.* Best, Bas — * With the tiny caveat that apparently the order of the shares does matter atm. [insert facepalm.] > - X25519 + Kyber512 > - P256 + Kyber512 > - X448 + Kyber768 > - P384 + Kyber768 > > I don't see the point of including finite field groups. I would hope to > hold off on national curves, such as Brainpool and the GOST curves > (although they're likely to be forced on us anyways). I personally see > Kyber1024 as overkill (of course, if you disagree, please say so). > > Of course, it's possible that NIST will tweak the definition of Kyber; > that's just a possibility we'll need to live with (and wouldn't change what > hybrid combinations we would initially define) > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Again, this is late, however Stephen did ask this to be discussed in the working group, so here we go: > -Original Message- > From: TLS On Behalf Of Stephen Farrell > Sent: Saturday, April 30, 2022 11:49 AM > To: Ilari Liusvaara ; TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > > Hiya, > > On 30/04/2022 10:05, Ilari Liusvaara wrote: > > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote: > >> - 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 > > > > I 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. Section 5 is 'IANA considerations', and would be where we would list the various supported hybrids, which we don’t at the moment. Well, if we were to discuss some suggested hybrids (and we now know the NIST selection), I would suggest these possibilities: - X25519 + Kyber512 - P256 + Kyber512 - X448 + Kyber768 - P384 + Kyber768 I don't see the point of including finite field groups. I would hope to hold off on national curves, such as Brainpool and the GOST curves (although they're likely to be forced on us anyways). I personally see Kyber1024 as overkill (of course, if you disagree, please say so). Of course, it's possible that NIST will tweak the definition of Kyber; that's just a possibility we'll need to live with (and wouldn't change what hybrid combinations we would initially define) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Getting started, clock not set yet
On 8/9/22 4:12 PM, Eric Rescorla wrote: n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk wrote: On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote: > 3. Are you aware of some other set of rules for certificate issuance that require revocation after the certificate has expired? Removing certs from revocation lists after the certificate has expired is pretty much required in any scalable deployment which has a non-trivial time horizon (basically any commercial CA). That is because the list would grow without bounds. It's not necessary to solve the 'Getting started, clock not set yet' feature, however. For that case you only need to ignore 'not Before' when validating a TLS cert associated with an NTS call. You can always arrange for the unset clock to be older than the current time, so if the cert is expired based on the unset clock, the cert is expired for real. bob -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
Sorry for the late response; I was going through old emails and came across this; I thought it warranted a response > -Original Message- > From: TLS On Behalf Of Ilari Liusvaara > Sent: Saturday, April 30, 2022 5:05 AM > To: TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > I don't think compression method like ECH uses would work here. > > 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: (32+4 octets) > - p256: (65+4 octets) > - x25519+saber: (2+992+4 octets) > - p256+saber: (2+2+4 octets) > > Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression > itself. That sort of thing is possible. However, it was my understanding that the working group wanted a simple proposal; one with minimal changes to the TLS architecture. The current draft, which treats the hybrid as a single atomic group, meets that. This compression protocol would require something on the server side to parse through the compressed key shares to extract the desired shares (and, of course, handle it if the shares were not present). We'd also need something to distinguish between exactly one key share was presented (that is, the current protocol) and when multiple key shares were given. And, for consistency, we'd have the server use the same TLV format for its hybrid keyshares if it selects a hybrid group. So, the advantage of this compressed design is if the client's proposal was close (e.g. it wanted to negotiate either P256+Kyber or x25519+Kyber), it wouldn't have to guess - it could include all the alternatives, and as long as the server accepted either one, the negotiation would proceed; with the current draft design, the client would have to guess (and if it guessed wrong, we'd take an additional round trip for the HRR). The disadvantage of this design is a bit of additional complexity. Does the working group have a strong opinion about this? > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
