Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
There's an argument that it's worth building in a 256-bit cipher for quantum resistance. Not clear that AES-256 is the best 256-bit cipher though. William On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich wrote: > > Assuming 256-bit AES-CCM suites are needed, I think the better place to > put > > them is in the TLS 1.3 document. > > That's a really big assumption. ;) > > I think the burden is on folks to *prove* (yeah, I know) that additional > cipher suites are needed. > ___ > 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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher as part of the core TLS 1.3 family of techniques, but I don't feel strongly that it should be AES-256. ChaCha? Cheers, William On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich wrote: > > There's an argument that it's worth building in a 256-bit cipher for > quantum resistance. Not clear that AES-256 is the best 256-bit cipher > though. > > Yes, I get that. > > "not clear" is a highly uncompelling argument, tho. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
TLS 1.3 currently has AES-256-GCM and ChaCha20-Poly1305 as 256-bit ciphers. AES-CCM ciphers are more oriented towards an IOT niche where CCM is implemented for lower layer protocols. I'm not sure if there are implementations of AES-256-CCM or AES-256-CCM_8 in use. Joe On Fri, Feb 24, 2017 at 7:12 AM, William Whyte wrote: > Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher > as part of the core TLS 1.3 family of techniques, but I don't feel strongly > that it should be AES-256. ChaCha? > > Cheers, > > William > > On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich wrote: > >> > There's an argument that it's worth building in a 256-bit cipher for >> quantum resistance. Not clear that AES-256 is the best 256-bit cipher >> though. >> >> Yes, I get that. >> >> "not clear" is a highly uncompelling argument, tho. >> > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adding an additional step to exporters
On Fri, Feb 24, 2017 at 11:47:32AM -0500, Hugo Krawczyk wrote: > Martin, > > Which of these two derivation schemes are you proposing? > Are you assuming that all uses of the exporter_secret are known at the end > of > the handshake? If not, you still need to keep an exporter_secret beyond the > handshake. > > Master Secret > | > | > +-> Derive-Secret(., "exporter master secret 1", > | ClientHello...Server Finished) > | = exporter_secret_1 > | > +-> Derive-Secret(., "exporter master secret 2", > ClientHello...Server Finished) > = exporter_secret_2 > > Or: > > Master Secret > | > | > +-> Derive-Secret(., "exporter master secret", > ClientHello...Server Finished) > = exporter_secret > | > +-> Derive-Secret(., "exporter secret > 1", > | what_exactly) > | = exporter_secret_1 > | > | > +-> Derive-Secret(., "exporter secret > 2", >what_exactly) >= exporter_secret_2 > > > (I wrote "what exactly" since I am not sure what do you plan to include > there.) I interpretted it to be something like follows: Master secret + Derive-Secret(label="exporter master secret", context=ClientHello...ServerFinished) + Derive-Secret(label=EXPORTER-FOO, context=) + Derive-Secret(label="exporter", context=) + Derive-Secret(label="exporter", context=) + Derive-Secret(label=EXPORTER-BAR, context=) + Derive-Secret(label="exporter", context=) + Derive-Secret(label="exporter", context=) But I don't know how useful that would be, as it requires knowing all labels one is going to use (or one needs to keep EMS around anyway). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adding an additional step to exporters
Martin, Which of these two derivation schemes are you proposing? Are you assuming that all uses of the exporter_secret are known at the end of the handshake? If not, you still need to keep an exporter_secret beyond the handshake. Master Secret | | +-> Derive-Secret(., "exporter master secret 1", | ClientHello...Server Finished) | = exporter_secret_1 | +-> Derive-Secret(., "exporter master secret 2", ClientHello...Server Finished) = exporter_secret_2 Or: Master Secret | | +-> Derive-Secret(., "exporter master secret", ClientHello...Server Finished) = exporter_secret | +-> Derive-Secret(., "exporter secret 1", | what_exactly) | = exporter_secret_1 | | +-> Derive-Secret(., "exporter secret 2", what_exactly) = exporter_secret_2 (I wrote "what exactly" since I am not sure what do you plan to include there.) Regarding Ilari's comment on HKDF pairings, I have said that an Extract operation needs to always be followed by an Expand operation, but an expand operation may be followed by an expand operation. The point is that the output of Expand is (typically) intended as a key to another cryptographic function. Such function can be HKDF-Expand itself (which is just a specific implementation of a variable-length input/output PRF). Thus, both of the above possible derivations are OK from the point of view of HKDF. Hugo On Fri, Feb 24, 2017 at 12:40 AM, Martin Thomson wrote: > On 24 February 2017 at 16:01, Sean Turner wrote: > > So this isn’t entirely novel right I mean we did something similar wrt > other key schedules? > > I certainly hope it isn't novel. I'm just applying the same > technique: keep independent keys independent. > > On 24 February 2017 at 16:09, Felix Günther > wrote: > > just to clarify: you add an additional HKDF.Expand step, not > > HKDF.Extract, right? > > Yes, you are right, I should have said expand. You need to use expand > to get the label-based separation on type. > > I don't know how I got confused about that. If we need to maintain > extract and expand in pairs (as we have already been burned by), then > I will defer to cryptographers on that. > > ___ > 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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
> There's an argument that it's worth building in a 256-bit cipher for quantum > resistance. Not clear that AES-256 is the best 256-bit cipher though. Yes, I get that. "not clear" is a highly uncompelling argument, tho. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead
> Assuming 256-bit AES-CCM suites are needed, I think the better place to put > them is in the TLS 1.3 document. That's a really big assumption. ;) I think the burden is on folks to *prove* (yeah, I know) that additional cipher suites are needed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adding an additional step to exporters
On Fri, Feb 24, 2017 at 04:40:19PM +1100, Martin Thomson wrote: > On 24 February 2017 at 16:01, Sean Turner wrote: > > So this isn’t entirely novel right I mean we did something similar wrt > > other key schedules? > > I certainly hope it isn't novel. I'm just applying the same > technique: keep independent keys independent. This technique seems to assume there is some fixed known set of exporter labels that are used. Since if you don't know the full set, you need to keep the master exporter secret around anyway. > On 24 February 2017 at 16:09, Felix Günther > wrote: > > just to clarify: you add an additional HKDF.Expand step, not > > HKDF.Extract, right? > > Yes, you are right, I should have said expand. You need to use expand > to get the label-based separation on type. > > I don't know how I got confused about that. If we need to maintain > extract and expand in pairs (as we have already been burned by), then > I will defer to cryptographers on that. The creator of HKDF stated that HKDF should always be used with paired extracts and expands and any derpartion from that should be done with utmost care. Both the existing design and this design fail this: Because exporter secrets are of expanded type, you would need to extract them, and derive-secret is expansion type operation. Note that passing label as salt is definitely very bad idea, since you will get trivial collisions due to how HKDF works internally. And doing so even with hash might be a bad idea. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
