Re: [TLS] DSA support in TLS 1.3.
Hi IIari, >From all of the RFCs about suite B that I have read, DSA has never been a part >of it. RSA can be used for signatures and key wrap/transport. Quynh. From: TLS on behalf of Ilari Liusvaara Sent: Wednesday, September 2, 2015 1:49 PM To: Salz, Rich Cc: tls@ietf.org Subject: Re: [TLS] DSA support in TLS 1.3. On Tue, Sep 01, 2015 at 05:58:33PM +, Salz, Rich wrote: > There is a third option: you don't get to use TLS 1.3 until the > government requirements are updated. > > I'm fine with that. I think they already have, with NSA seemingly saying RSA3k is OK for up to TOP SECRET (unless I misunderstood). The same table from NSA that mentions RSA (and the 3k limit) does not mention DSA (the only other signature algo is ECDSA with 384 limit). So maybe even US govt. is not using DSA? -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
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
Hiya, On 04/09/15 01:58, Sean Turner wrote: > Also, I wouldn’t get too wrapped around the updates header because > the meaning has changed over time. At some points it has been used > to point implementers at other related RFCs, but what I think the > IESG has settled onto now (Stephen correct me if I’m wrong) is that > the update header indicates that implementations of the updated RFC > are expected to implement the update (note that expected is too > strong of a word because implementing RFCs is purely voluntary - > there’s no protocol police). Right. Though even that may change as IESG personnel change;-) Anyway, yes the UTA BCP (BCP195. [1]) is almost certainly what you'd reference when you next write an NTP RFC that mentions TLS. I would guess that folks in the NTP wg would be the ones who'd know whether writing a short RFC to make just that change is worthwhile or not. So probably the next step is to ask that question on the NTP wg list. Cheers, S. [1] https://tools.ietf.org/html/bcp195 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RC4 cipher with NNTP (RFC 4642)
Oops - s/NTP/NNTP/g below:-) And since there's no active NNTP wg, I guess asking on some relevant list(s) is the thing to do. If folks there think that a short RFC to just fix this is useful then feel free to get back to me and we can figure how best to progress that. Cheers, S. On 04/09/15 12:57, Stephen Farrell wrote: > > Hiya, > > On 04/09/15 01:58, Sean Turner wrote: >> Also, I wouldn’t get too wrapped around the updates header because >> the meaning has changed over time. At some points it has been used >> to point implementers at other related RFCs, but what I think the >> IESG has settled onto now (Stephen correct me if I’m wrong) is that >> the update header indicates that implementations of the updated RFC >> are expected to implement the update (note that expected is too >> strong of a word because implementing RFCs is purely voluntary - >> there’s no protocol police). > > Right. Though even that may change as IESG personnel change;-) > > Anyway, yes the UTA BCP (BCP195. [1]) is almost certainly what > you'd reference when you next write an NTP RFC that mentions TLS. > > I would guess that folks in the NTP wg would be the ones who'd > know whether writing a short RFC to make just that change is > worthwhile or not. So probably the next step is to ask that > question on the NTP wg list. > > Cheers, > S. > > [1] https://tools.ietf.org/html/bcp195 > > ___ > 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
[TLS] TLS 1.3 Key Schedule
In Section 7.1, the document says: 4. finished_secret = HKDF-Expand-Label(xSS, "finished secret", handshake_hash, L) 5. resumption_secret = HKDF-Expand-Label(master_secret, "resumption master secret" session_hash, L) Why don't we use the master_secret in both the finished_secret and the resumption_secret formula? Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Key Schedule
See: http://www.ietf.org/mail-archive/web/tls/current/msg17184.html On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > In Section 7.1, the document says: > > 4. finished_secret = HKDF-Expand-Label(xSS, > "finished secret", > handshake_hash, L) > > 5. resumption_secret = HKDF-Expand-Label(master_secret, > "resumption master secret" > session_hash, L) > > Why don't we use the master_secret in both the finished_secret and the > resumption_secret formula? > > Russ > ___ > 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] TLS 1.3 Key Schedule
Eric: I looked at Hugo's message in the context of the table in Section 7.1: Key ExchangeStatic Secret (SS)Ephemeral Secret (ES) --- (EC)DHE Client ephemeral Client ephemeral (full handshake) w/ server ephemeral w/ server ephemeral (EC)DHE Client ephemeral Client ephemeral (w/ 0-RTT)w/ server static w/ server ephemeral PSK Pre-Shared Key Pre-shared key PSK + (EC)DHE Pre-Shared Key Client ephemeral w/ server ephemeral If I understand Hugo's message correctly, he is saying that in the second row, the SS must be part of the key derivation. I think we need to consider the bottom row as well. It seems to me that using the master_secret capture the benefits of both the SS and the ES. This meets Hugo's requirement for the second row, and gets the benefits of the ephemeral values for the bottom row. Russ On Sep 4, 2015, at 11:33 AM, Eric Rescorla wrote: > See: > http://www.ietf.org/mail-archive/web/tls/current/msg17184.html > > On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > In Section 7.1, the document says: > > 4. finished_secret = HKDF-Expand-Label(xSS, > "finished secret", > handshake_hash, L) > > 5. resumption_secret = HKDF-Expand-Label(master_secret, > "resumption master secret" > session_hash, L) > > Why don't we use the master_secret in both the finished_secret and the > resumption_secret formula? > > Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 Key Schedule
On Fri, Sep 4, 2015 at 8:58 AM, Russ Housley wrote: > Eric: > > I looked at Hugo's message in the context of the table in Section 7.1: > > Key ExchangeStatic Secret (SS)Ephemeral Secret (ES) > --- > (EC)DHE Client ephemeral Client ephemeral > (full handshake) w/ server ephemeral w/ server ephemeral > > (EC)DHE Client ephemeral Client ephemeral > (w/ 0-RTT)w/ server static w/ server ephemeral > > PSK Pre-Shared Key Pre-shared key > > PSK + (EC)DHE Pre-Shared Key Client ephemeral > w/ server ephemeral > > If I understand Hugo's message correctly, he is saying that in the second > row, the SS must be part of the key derivation. I think we need to > consider the bottom row as well. > > It seems to me that using the master_secret capture the benefits of both > the SS and the ES. This meets Hugo's requirement for the second row, and > gets the benefits of the ephemeral values for the bottom row. > I don't think you are reading that correctly. The point is that in the case where SS is authenticated (e.g., a PSK or a static DH), then the Finished MAC authenticates the ServerKeyShare. If you include ES in the Finished key, then you are using ES to authenticate ServerKeyShare, which apparently makes analysis harder. -Ekr Russ > > > On Sep 4, 2015, at 11:33 AM, Eric Rescorla wrote: > > See: > http://www.ietf.org/mail-archive/web/tls/current/msg17184.html > > On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote: > >> In Section 7.1, the document says: >> >> 4. finished_secret = HKDF-Expand-Label(xSS, >> "finished secret", >> handshake_hash, L) >> >> 5. resumption_secret = HKDF-Expand-Label(master_secret, >> "resumption master secret" >> session_hash, L) >> >> Why don't we use the master_secret in both the finished_secret and the >> resumption_secret formula? >> >> Russ >> > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
