Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Jeffrey Walton writes: >Somewhat off-topic, why does TLS not produce a few profiles. One can be >"Opportunistic TLS Profile" with a compatible security posture and include >ADH. Another can be a "Standard TLS Profile" and include things like export >grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a >"TLS Defensive profile" where you get mostly the strong the protocols and >ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot >break the secure channel by tricking a user, etc. +1. At the moment you're stuck with everything-all-the-time (or alternatively one-size-misfits-all) where you have to support every single mechanism and quirk and add-on, when all you want most of the time is to set up a basic secure tunnel from A to B. Having profiles would be a great help, so all the other standards groups that build on TLS can refer to, say, the emebedded- device profile or the PFS-with-PSK profile rather than having to hack around the standard themselves. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Tue, 2015-09-15 at 18:00 -0700, Joseph Salowey wrote: > There has been some discussion to remove anonymous DH as described > inhttps://www.ietf.org/mail-archive/web/tls/current/msg17481.html. ; I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. If that implies that anonymous ECDH ciphersuites are removed too, I'm all for it. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 16/09/15 09:19, Peter Gutmann wrote: > Jeffrey Walton writes: > >> Somewhat off-topic, why does TLS not produce a few profiles. One can be >> "Opportunistic TLS Profile" with a compatible security posture and include >> ADH. Another can be a "Standard TLS Profile" and include things like export >> grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a >> "TLS Defensive profile" where you get mostly the strong the protocols and >> ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot >> break the secure channel by tricking a user, etc. > > +1. At the moment you're stuck with everything-all-the-time (or alternatively > one-size-misfits-all) where you have to support every single mechanism and > quirk and add-on, when all you want most of the time is to set up a basic > secure tunnel from A to B. Having profiles would be a great help, so all the > other standards groups that build on TLS can refer to, say, the emebedded- > device profile or the PFS-with-PSK profile rather than having to hack around > the standard themselves. We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a draft [2] (current in IESG evaluation) for the embedded case. Are those the kind of thing you're after? If so, and you wanted more, the UTA WG [3] (which produced BCP195) would maybe be the best place to see if there's enough interest in doing more. (The embedded one was done in the DICE WG [4] which was setup mostly for that as it's to some extent a different set of folks. And that could be done again if needed.) Cheers, S. [1] https://tools.ietf.org/html/bcp195 [2] https://tools.ietf.org/html/draft-ietf-dice-profile-16 [3] https://tools.ietf.org/wg/uta/ [4] https://tools.ietf.org/wg/dice/ > > Peter. > > ___ > 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] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 4:10 AM, Tom Ritter wrote: > On 15 September 2015 at 20:42, Tony Arcieri wrote: > > +1 for removing anonymous DH > > +1. > +1. Aaron ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/15/2015 06:29 PM, Nico Williams wrote: > On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote: >> On 09/12/2015 10:49 PM, Eric Rescorla wrote: >>> Issue: https://github.com/tlswg/tls13-spec/issues/242 >>> >>> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: >>> >>> "Nobody must ever be *required* to send an alert. Any requirement for >>> sending an alert should be SHOULD, at most." >> >> Using full-duplex TCP, it's difficult to get a fatal alert over the wire >> if you want to close the connection immediately: > > But if you have a fatal error you'll be closing immediately anyways. > Does sending the fatal alert cause a problem other than increase the > likelihood of RSTs? What is the alternative considering that the next > step is to close the connection anyways? I'm trying to explain that any requirement to send fatal alerts will be difficult to implement. With the BSD sockets API, the only way to do that reliable is *not* to close the socket immediately, which is apparently not what you (or existing APIs) expect, and which is where the difficulty lies. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
> This kinda begs the question, who should be responsible for high level TLS > configurations to ease management, maximize security and minimize > interoperability issues. > > For that, I'd argue it falls squarely within TLS WG purview. The security area has a hand in reviewing all of them, as part of the IESG review. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Stephen Farrell writes: >We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a >draft [2] (current in IESG evaluation) for the embedded case. Are those the >kind of thing you're after? Sort of, but since they're not part of the TLS spec they essentially don't exist (I've never seen then quoted, cited, or referenced in any third-party standard that deals with TLS). Another problem is that they're defined as a large collection of (often rather waffly) "don't do this" comments, so as a somewhat wooly blacklist rather than a clear whitelist. So the BCPs aren't really a profile but more like 20-30 pages of hand-wringing. An actual profile of TLS would be something like MUST TLS 1.1 or above, MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication what isn't explicitly permitted is denied). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote: > On 09/15/2015 06:29 PM, Nico Williams wrote: [...] >> >> But if you have a fatal error you'll be closing immediately anyways. >> Does sending the fatal alert cause a problem other than increase the >> likelihood of RSTs? What is the alternative considering that the next >> step is to close the connection anyways? > > I'm trying to explain that any requirement to send fatal alerts will be > difficult to implement. With the BSD sockets API, the only way to do > that reliable is *not* to close the socket immediately, which is > apparently not what you (or existing APIs) expect, and which is where > the difficulty lies. What about SO_LINGER? -- Henrik Grubbström gru...@grubba.org Roxen Internet Software AB gru...@roxen.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On 09/16/2015 01:51 PM, Henrik Grubbström wrote: > On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote: >> On 09/15/2015 06:29 PM, Nico Williams wrote: > [...] >>> >>> But if you have a fatal error you'll be closing immediately anyways. >>> Does sending the fatal alert cause a problem other than increase the >>> likelihood of RSTs? What is the alternative considering that the next >>> step is to close the connection anyways? >> >> I'm trying to explain that any requirement to send fatal alerts will be >> difficult to implement. With the BSD sockets API, the only way to do >> that reliable is *not* to close the socket immediately, which is >> apparently not what you (or existing APIs) expect, and which is where >> the difficulty lies. > > What about SO_LINGER? With full-duplex connections, it does not make a difference. TCP will still detect a data loss event, send the RST segment, and discard the queued fatal alert. -- Florian Weimer / Red Hat Product Security ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
> An actual profile of TLS would be something like MUST TLS 1.1 or above, > MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication > what isn't explicitly permitted is denied). HTTP-2 did this kind of thing, and IIRC are the first to do so. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
> With full-duplex connections, it does not make a difference. TCP will still > detect a data loss event, send the RST segment, and discard the queued fatal > alert. Yes, it might be hard(er) to do the right thing. We should not penalize everyone because of that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] reminder (Re: '15 TLS Fall Interim Logistics)
I’ve also uploaded a draft agenda: http://ietf.org/meeting/interim/proceedings.html As per usual, this interim is going to focus on TLS 1.3 related issues. spt On Sep 15, 2015, at 15:09, Sean Turner wrote: > In case you’re planning on attending the f2f meeting next week please fill > out the doodle poll (http://doodle.com/ei6px58ip59gr85y) to ensure we’ve got > a badge to get you into the building. See you next week! > > spt > > On Sep 02, 2015, at 19:39, Sean Turner wrote: > >> All, >> >> Andrei has graciously offered to host us at Microsoft in Redmond, WA [0]. >> We’re going to need a list of those that plan to attend in person in order >> to make sure there’s a badge for you to get into the buildings. Please fill >> out the following doodle poll if you plan to attend in person: >> http://doodle.com/ei6px58ip59gr85y. >> >> Note that we’re in different buildings/rooms each day. Here are the >> specifics: >> >> 09/21: 16071 NE 36th Way, REDMOND, WA, 98052 (East Campus bldg. 37 room 1727) >> 09/22: 3850 148th Ave NE, REDMOND, WA, 98052 (West Campus Studio H room 1022) >> >> More details as we get them. >> >> The original meeting announcement can be found at: >> https://mailarchive.ietf.org/arch/msg/tls/lfJjrpjZoidONUTIvDWzM5V52ug >> >> spt >> >> [0] For those of you flying, you still fly into Seattle, WA. Don’t be >> confused when you see the doodle poll that says “Redmond, WA". > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 16/09/15 12:18, Peter Gutmann wrote: > Stephen Farrell writes: > >> We have BCP195 [1] that aims for the "general" case (for up to TLS1.2) and a >> draft [2] (current in IESG evaluation) for the embedded case. Are those the >> kind of thing you're after? > > Sort of, but since they're not part of the TLS spec they essentially don't > exist (I've never seen then quoted, cited, or referenced in any third-party > standard that deals with TLS). I'm not sure how to process that comment. You ask for X, I ask is Y==X and your answer is that Y doesn't exist? Seems odd. ;-) Anyway, so far 5 RFCs reference BCP195. [1] I'd say that'll grow over time. Hopefully folks implementing will find it useful too and not only those writing RFCs that need TLS, but I guess we'll see over time if BCP195 got it right or not. [1] http://www.arkko.com/tools/allstats/citations-rfc7525.html > > Another problem is that they're defined as a large collection of (often rather > waffly) "don't do this" comments, so as a somewhat wooly blacklist rather than > a clear whitelist. So the BCPs aren't really a profile but more like 20-30 > pages of hand-wringing. Feel free to collect a bunch of your own emails (hand-wringing or not:-) and shoot those out as an I-D. > An actual profile of TLS would be something like MUST TLS 1.1 or above, MUST > PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication what isn't > explicitly permitted is denied). Yes, life would be lovely if things were so simple. S. > > Peter. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Stephen Farrell writes: >I'm not sure how to process that comment. You ask for X, I ask is Y==X and >your answer is that Y doesn't exist? Seems odd. ;-) There's a difference between "X/Y exists" (but no-one knows about it) and "X/Y exists and is actively used". As I said, I've never seen the BCP quoted, cited, or referenced in any third-party standard that deals with TLS (and by third-party standard I don't mean other RFCs but industry standards like IEC 61850 or IEC 62351). >Feel free to collect a bunch of your own emails (hand-wringing or not:-) and >shoot those out as an I-D. That makes it worse, not better, because it's just creating one more I-D or RFC or BCP or whatever to languish in obscurity. The profiles need to be part of the TLS spec where they'll be noticed and used by other standards referencing it. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Salz, Rich writes: >> An actual profile of TLS would be something like MUST TLS 1.1 or above, >> MUST PFS suites, MUST AES and SHA256, MUST E-then-M (and by implication >> what isn't explicitly permitted is denied). > >HTTP-2 did this kind of thing, and IIRC are the first to do so. Some PKI standards have done it too, but mostly because the base standard was such a mess that you needed a profile just to sort out what needed to be implemented for anything to work (for some level of "work"). They're such a design counterexample that I didn't want to mention them in my original message :-). Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Tue, Sep 15, 2015 at 08:17:56PM +, Andrei Popov wrote: > Perhaps we can simplify the protocol by pulling client auth out of the > handshake as follows: Problem with pulling client auth out of the handshake is that it complicates applications that can't change identities involved with active connection. And applications that can't take dynamic identites may still be able to take static identities. As then the application needs to ensure that the authentication occurs between TLS handshake and actually starting up the protocol. > 2. The client can send Certificate and CertificateVerify at any > time application data is permitted, regardless of whether the > server had previously sent CertificateRequest. CertificateRequest contains the permitted signature algorithms for the PoP signature, which TLS library needs to verify before dumping the certificate chain on application (which can then figure out things like trust anchors). Without CertificateRequest, one has little idea what algorithms are acceptable there. > 3. The server can send CertificateRequest and NewSessionTicket at any > time application data is permitted. Alternatively, the server can > encapsulate CertificateRequest in an application protocol message. If done with protocols that can't support dynamic authentication properly, doing that tends not show up as things visibly breaking, it tends to show up as subtle security holes. Also, that doesn't properly bind NST with state is for (as already noted), possibly causing screwy behaviour if TLS resumption is attempted (client and server not agreeing on client identity, which actually breaks definition of secure key exchange outright). > Encapsulating CertificateRequest in an application protocol message > allows the client to determine which specific application request > resulted in the need for client auth. The application protocols that would indicate this seem to be pretty much the ones where dynamic authentication is unsafe. Basically, one must clear the pipeline before changing identities, and with protocols like HTTP/2, this is extremely expensive (seemingly even more expensive than establishing a new connecion). > We can decide exactly what CertificateVerify would be signing: > whether it's the handshake hash or some form of RFC5705 Exported > Keying Material (EKM). Also, it should sign the certificate, to avoid possible weirdness due to signatures not properly binding the key (some schemes do, most don't). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote: > I'm trying to explain that any requirement to send fatal alerts will be > difficult to implement. With the BSD sockets API, the only way to do > that reliable is *not* to close the socket immediately, which is > apparently not what you (or existing APIs) expect, and which is where > the difficulty lies. This is silly. The server sends the alert on a best-effort basis. We cannot impose a magical requirement that the alert gets there. The requirement is to send, not to guarantee successful transmission. Sending is easy, just write the alert down the socket (even that might fail and that's fine). In practice, if the the server is the first to detect an error, its alert gets to the client. There's no need to read too much into this. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
On 15 September 2015 at 20:12, Karthikeyan Bhargavan wrote: > I assume the client hello extension still has the certificate digest, yes? > This means that the analysis probably relied on agreement of the certificate > hash from the client hello. This was only in the 1.3 context, and the certificate digest was completely removed from the handshake... It was pointed out to me separately that this doesn't work for static RSA because you need to include the public key in the transcript there to avoid having an attacker impose a PMS (one of the components of triple-handshake). That means that we need a strong hash for that case. However, if this is only used for PFS modes, then the analysis suggests that we are OK to remove or truncate, assuming session-hash. > For example, is it possible for a website to use the same public key on two > certificates for two different purposes? Is it possible for an attacker to > obtain a certificate from a CA for a public key even though it does not know > the corresponding private key? Does any of the existing analyses of TLS permit these changes? If the same key is used for two different purposes, then the risk of reaching a state where the purposes are confused seems to be too easy. Similarly, if I can obtain a certificate for a key without demonstrating proof of possession, then we're in a bad state. I would hope that the ACME protocol does not permit that, certainly this is a fundamental part of the certificate signing request. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 16 September 2015 at 08:02, Peter Gutmann wrote: >>HTTP-2 did this kind of thing, and IIRC are the first to do so. > > Some PKI standards have done it too, but mostly because the base standard was > such a mess that you needed a profile just to sort out what needed to be > implemented for anything to work (for some level of "work"). They're such a > design counterexample that I didn't want to mention them in my original > message :-). Yes. I wouldn't recommend following this path to others; it's not easy and the return on that investment isn't all good. The mess we were attempting to clean up with HTTP/2 was the state of TLS deployment on the web, not so much the spec itself. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
> There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. I see no reason to keep it. Russ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
Martin's point makes sense to me: applications that need to do authentication upfront can still do that immediately after the handshake. Cheers, Andrei -Original Message- From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Wednesday, September 16, 2015 10:48 AM To: Ilari Liusvaara Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] Review of PR #209 On 16 September 2015 at 08:30, Ilari Liusvaara wrote: > Problem with pulling client auth out of the handshake is that it > complicates applications that can't change identities involved with > active connection. Why would that be unsupported here? The server can still send CertificateRequest immediately after its Finished. That looks exactly like it does today, only the order has changed. > As then the application needs to ensure that the authentication occurs > between TLS handshake and actually starting up the protocol. I'm not sure that is necessarily a problem. If the claim is that the authentication attests to everything prior to its appearance, then you have no problem. I think that claim is reasonable, but I'm happy to discuss it. >> 2. The client can send Certificate and CertificateVerify at any time >> application data is permitted, regardless of whether the server had >> previously sent CertificateRequest. > > CertificateRequest contains the permitted signature algorithms for the > PoP signature, which TLS library needs to verify before dumping the > certificate chain on application (which can then figure out things > like trust anchors). > > Without CertificateRequest, one has little idea what algorithms are > acceptable there. Arguably, signature_algorithms covers that adequately. Though I'll grant that certificate chain validation often happens in a separate component to the TLS stuff. > Basically, one must clear the pipeline before changing identities, and > with protocols like HTTP/2, this is extremely expensive (seemingly > even more expensive than establishing a new connecion). There's been some confusion about this with HTTP/2. I think that if you adopt the position that authentication applies to the entire session - even retroactively - then the only remaining concern is the correlation one. If you have three tabs to the site open where all of them are making requests and you see a certificate request, which one do you pop the dialog on? > Also, it should sign the certificate, to avoid possible weirdness due > to signatures not properly binding the key (some schemes do, most > don't). I agree with this. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
I think the potential issue here is needing a way for the server to tell the client "don't bother sending me data until you've authenticated" (though, as MT says, you could argue that the client's signature retroactively authenticates, which does seem like the simplest way to think about things). One might imagine dealing with that by a simple signal in a ServerHello extension that said "authentication will be required, sit tight..." -Ekr On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov wrote: > Martin's point makes sense to me: applications that need to do > authentication upfront can still do that immediately after the handshake. > > Cheers, > > Andrei > > -Original Message- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: Wednesday, September 16, 2015 10:48 AM > To: Ilari Liusvaara > Cc: Andrei Popov ; tls@ietf.org > Subject: Re: [TLS] Review of PR #209 > > On 16 September 2015 at 08:30, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly like > it does today, only the order has changed. > > > As then the application needs to ensure that the authentication occurs > > between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you have > no problem. I think that claim is reasonable, but I'm happy to discuss it. > > >> 2. The client can send Certificate and CertificateVerify at any time > >> application data is permitted, regardless of whether the server had > >> previously sent CertificateRequest. > > > > CertificateRequest contains the permitted signature algorithms for the > > PoP signature, which TLS library needs to verify before dumping the > > certificate chain on application (which can then figure out things > > like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms are > > acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll grant > that certificate chain validation often happens in a separate component to > the TLS stuff. > > > Basically, one must clear the pipeline before changing identities, and > > with protocols like HTTP/2, this is extremely expensive (seemingly > > even more expensive than establishing a new connecion). > > There's been some confusion about this with HTTP/2. I think that if you > adopt the position that authentication applies to the entire session - even > retroactively - then the only remaining concern is the correlation one. If > you have three tabs to the site open where all of them are making requests > and you see a certificate request, which one do you pop the dialog on? > > > Also, it should sign the certificate, to avoid possible weirdness due > > to signatures not properly binding the key (some schemes do, most > > don't). > > I agree with this. > ___ > 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] Review of PR #209
I should add: I do think this general line of consolidating all the client auth modes is a good idea, assuming we can work out the details. -Ekr On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla wrote: > I think the potential issue here is needing a way for the server to tell > the > client "don't bother sending me data until you've authenticated" (though, > as MT says, you could argue that the client's signature retroactively > authenticates, which does seem like the simplest way to think about > things). > > One might imagine dealing with that by a simple signal in a ServerHello > extension that said "authentication will be required, sit tight..." > > -Ekr > > > On Wed, Sep 16, 2015 at 11:11 AM, Andrei Popov > wrote: > >> Martin's point makes sense to me: applications that need to do >> authentication upfront can still do that immediately after the handshake. >> >> Cheers, >> >> Andrei >> >> -Original Message- >> From: Martin Thomson [mailto:martin.thom...@gmail.com] >> Sent: Wednesday, September 16, 2015 10:48 AM >> To: Ilari Liusvaara >> Cc: Andrei Popov ; tls@ietf.org >> Subject: Re: [TLS] Review of PR #209 >> >> On 16 September 2015 at 08:30, Ilari Liusvaara < >> ilari.liusva...@elisanet.fi> wrote: >> > Problem with pulling client auth out of the handshake is that it >> > complicates applications that can't change identities involved with >> > active connection. >> >> Why would that be unsupported here? The server can still send >> CertificateRequest immediately after its Finished. That looks exactly like >> it does today, only the order has changed. >> >> > As then the application needs to ensure that the authentication occurs >> > between TLS handshake and actually starting up the protocol. >> >> I'm not sure that is necessarily a problem. If the claim is that the >> authentication attests to everything prior to its appearance, then you have >> no problem. I think that claim is reasonable, but I'm happy to discuss it. >> >> >> 2. The client can send Certificate and CertificateVerify at any time >> >> application data is permitted, regardless of whether the server had >> >> previously sent CertificateRequest. >> > >> > CertificateRequest contains the permitted signature algorithms for the >> > PoP signature, which TLS library needs to verify before dumping the >> > certificate chain on application (which can then figure out things >> > like trust anchors). >> > >> > Without CertificateRequest, one has little idea what algorithms are >> > acceptable there. >> >> Arguably, signature_algorithms covers that adequately. Though I'll grant >> that certificate chain validation often happens in a separate component to >> the TLS stuff. >> >> > Basically, one must clear the pipeline before changing identities, and >> > with protocols like HTTP/2, this is extremely expensive (seemingly >> > even more expensive than establishing a new connecion). >> >> There's been some confusion about this with HTTP/2. I think that if you >> adopt the position that authentication applies to the entire session - even >> retroactively - then the only remaining concern is the correlation one. If >> you have three tabs to the site open where all of them are making requests >> and you see a certificate request, which one do you pop the dialog on? >> >> > Also, it should sign the certificate, to avoid possible weirdness due >> > to signatures not properly binding the key (some schemes do, most >> > don't). >> >> I agree with this. >> ___ >> 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 Provfiles (Was: Call for consensus to remove anonymous DH)
On Wed, Sep 16, 2015 at 02:10:36PM -0400, Dave Garrett wrote: > > Yes. I wouldn't recommend following this path to others; it's not > > easy and the return on that investment isn't all good. The mess we > > were attempting to clean up with HTTP/2 was the state of TLS > > deployment on the web, not so much the spec itself. > > The profiles idea feels like a way to justify having a crap profile in the > mix. I see no basis for that dismissive throw-away. > We should be focusing on restricting TLS to always actually be competent. All profiles are restrictions by definition, they don't add new features. Competence is context dependent. The advantage of profiles is that they standardize sensible combinations of features, and encourage toolkits to provide interfaces for applications to track a particular profile. This also makes it easier for toolkits to harden some profiles selectively without breaking other profiles. Explicit profiles make some sense. They need not be defined by the TLS WG per-se, it might be enough for the TLS specification to reference an IANA profile registry, with the TLS-WG defining a "base" profile. Then other WGs (including the[ TLS WG) can define additional profiles. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly > like it does today, only the order has changed. > > > As then the application needs to ensure that the authentication > > occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it. I think it is the attesting (even of present in-flight requests) that is the problem, not not attesting something. > > CertificateRequest contains the permitted signature algorithms > > for the PoP signature, which TLS library needs to verify before > > dumping the certificate chain on application (which can then > > figure out things like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms > > are acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll > grant that certificate chain validation often happens in a separate > component to the TLS stuff. The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
To clarify, the proposal includes removing ECDH_anon, right? If it does, I support it. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey Sent: Tuesday, September 15, 2015 6:01 PM To: tls@ietf.org Subject: [TLS] Call for consensus to remove anonymous DH There has been some discussion to remove anonymous DH as described in https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think ekr's message sums up the pros and cons well. I don't think we have consensus on this issue yet. Please respond on this message by Monday, September 21, if you have an opinion. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 11:35 AM, Andrei Popov wrote: > To clarify, the proposal includes removing ECDH_anon, right? > Yes. > If it does, I support it. > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Joseph Salowey > *Sent:* Tuesday, September 15, 2015 6:01 PM > *To:* tls@ietf.org > *Subject:* [TLS] Call for consensus to remove anonymous DH > > > > There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. > > > > Thanks, > > > > J&S > > ___ > 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] Should we require implementations to send alerts?
> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich > Sent: Wednesday, September 16, 2015 7:24 AM > To: Florian Weimer ; Henrik Grubbström > > Cc: tls@ietf.org > Subject: Re: [TLS] Should we require implementations to send alerts? > > > > With full-duplex connections, it does not make a difference. TCP will > > still detect a data loss event, send the RST segment, and discard the > > queued fatal alert. > > Yes, it might be hard(er) to do the right thing. We should not penalize everyone > because of that. There are cases where TLS is not traveling over TCP connections. In this case having the alert be transmitted is a better way of signaling either that a session has ended or the other channel needs to be closed. Jim > ___ > 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] Call for consensus to remove anonymous DH
Remove it. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 12:02:57PM +0200, Florian Weimer wrote: > On 09/15/2015 06:29 PM, Nico Williams wrote: > > But if you have a fatal error you'll be closing immediately anyways. > > I'm trying to explain that any requirement to send fatal alerts will be > difficult to implement. With the BSD sockets API, the only way to do > that reliable is *not* to close the socket immediately, which is > apparently not what you (or existing APIs) expect, and which is where > the difficulty lies. *Sending* the fatal alert is not hard at all. Giving the peer a fair chance to get them is the difficult thing. Strictly speaking then, requiring that fata alerts be sent is not difficult to implement. :^) Tongue-in-cheek aside, I think it's fair to say that fata alerts SHOULD be sent rather than MUST be sent. And it's a good idea to explain that sending a fatal alert, by itself, does not really mean that the peer is even more likely than not to see it, that more effort is required by the sender to give the peer a fair chance of seeing it. Fatal alerts are useful for diagnostics purposes at least, but there's no real need to tell a peer why you're slamming the door on them, is there. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
> The extension? IIRC, that is what _client_ can verify. This is about what > _server_ can verify. > Or the equivalent of current field that specifies that? That's inside > CertificateRequest, which would be optional. I don't necessarily buy Martin's argument that signature_algorithms covers this adequately. But I would argue that the application will only volunteer certs if it has out-of-band knowledge that client auth is required, and also knows exactly which cert is required. Otherwise, CertificateRequest should be used. Cheers, Andrei -Original Message- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Wednesday, September 16, 2015 11:25 AM To: Martin Thomson Cc: Andrei Popov ; tls@ietf.org Subject: Re: [TLS] Review of PR #209 On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly > like it does today, only the order has changed. > > > As then the application needs to ensure that the authentication > > occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it. I think it is the attesting (even of present in-flight requests) that is the problem, not not attesting something. > > CertificateRequest contains the permitted signature algorithms for > > the PoP signature, which TLS library needs to verify before dumping > > the certificate chain on application (which can then figure out > > things like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms are > > acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll > grant that certificate chain validation often happens in a separate > component to the TLS stuff. The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Wed, Sep 16, 2015 at 03:29:40PM -0400, Dave Garrett wrote: > I'd be fine with phrasing it as: implementations MUST send all alerts > when indicated, and SHOULD make a best-effort to ensure they get > delivered to the peer. +1. Perhaps some text explaining the difficulty in the latter and offering some implementation advice. Something like: Sending a fatal alert is easy, but ensuring that the peer gets it when running over TCP or similar can be difficult because a shutdown or close will result in the peer getting an RST if data is received from it before the alert is sent. Depending on the TCP stack, giving the alert a chance of being received may require delaying the closing of the connection by some amount of time. A "simple" way to do this is to "service" a pool of pending-close connections on a timer, or at the next new connection or insertion of a new delayed-close connection into the pool. A reasonably low implementation cost method is to have a fixed-sized pool of pending-close connections, closing the oldest connection whenever adding a new pending-close connection to a full pool. Note that any scheme that can leave pending-close connections alive possibly indefinitely will also consume the associated TCP PCB resources indefinitely. The second paragraph might be giving too much implementation advice. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
On Sat, Sep 12, 2015 at 1:49 PM, Eric Rescorla wrote: > Issue: https://github.com/tlswg/tls13-spec/issues/242 > > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues: > > "Nobody must ever be *required* to send an alert. Any requirement for > sending an alert should be SHOULD, at most." > Before I wade too deep into this thread, a question: Assume the client and the server implement the mandatory-to-implement parameters and that both the client and the server are otherwise conformant. In this scenerio, when would an alert other than the non-fatal close_notify be sent? It could happen if the data is being tampered with (i.e. the connection is under attack). But, is it really a good idea to send attacker-predictable and attacker-controllable plaintext (the alert record) when you suspect you are under attack? Wouldn't it be much safer to hole up in your turtle shell when you detect signs of an attack? It could happen that one peer does not trust the other peer's credentials (certificate). That is common when browsers are involved, but in other applications of TLS an untrusted certificate is a strong indicator of an attack. And, in those scenerios, turtling seems like the best solution; at the very least, it is a justifiable reason to not send an alert. Because the alerting mechanism is under the influence of attacks, it is no surprise that some attacks have already used the alerting mechanism. In particular, CBC padding attacks abuse the alerting mechanism, as has the Bleichenbacher attack. While it is nice that the specifics of those particular attacks have been made irrelevant for TLS 1.3, the general conclusion that the sending of alerts adds significant risk still holds. Thus, it is reasonable for a careful implementation of TLS to avoid sending alerts for this reason alone. Further, the alerting mechanism has encouraged the unsafe practice of "version fallback." It is clear from looking at the bug databases of Firefox and Chrome that their attempts to make security decisions based on what alerts they received was bad for security. If one peer is nonconformant, then it seems unfair, at best, to require the other peer to put itself at additional risk to inform the nonconformant peer of its non-conformance. It is each implementation's job to ensure its own conformance. Further, attempting to send fatal alerts adds non-trivial complexity to implementations which emperical evidence has shown to cause significant problems. I encourage the representatives of Mozilla and other projects to look through their bug databases for bugs--both publicly-accessible and hidden from the public--related to the sending of alerts. Also note that Mozilla's implementation, NSS, has *never* conformed with the specification's "MUST" requirements to send alerts, and it has bugs in this area reported half a decade ago that remain unfixed. Thus, the empirical evidence from Mozilla's widely-deployed implementation shows that (a) the requirement to send alerts is difficult to conform to, and (b) it is unimportant in practice to send alerts. Finally, in an implementation for constrained devices, where every byte of code size matters, even the small amounts of code necessary to conform with these requirements are simply not justified. This alone should be justification for avoiding requiring sending alerts. Cheers, Brian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 10:40:28AM -0700, Martin Thomson wrote: > On 15 September 2015 at 18:00, Joseph Salowey wrote: > > remove anonymous DH > > +1 > > It's not like we're making the use case impossible, just that the > solution will look different. And will be more costly. I'm neutral on this, as I don't think the extra cost will lead to, say, MTAs forgoing TLS for SMTP. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Tue, Sep 15, 2015 at 6:00 PM, Joseph Salowey wrote: > There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. > I think it is a good idea to remove DH_anon_* and similar ECDH_anon_* cipher suites. This isn't an endorsement of the raw public key modes. Cheers, Brian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] RFC 7627 on Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
A new Request for Comments is now available in online RFC libraries. RFC 7627 Title: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Author: K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray Status: Standards Track Stream: IETF Date: September 2015 Mailbox:karthikeyan.bharga...@inria.fr, antoine.delignat-lav...@inria.fr, alfredo.piro...@inria.fr, a...@google.com, ma...@microsoft.com Pages: 15 Characters: 34788 Updates:RFC 5246 I-D Tag:draft-ietf-tls-session-hash-06.txt URL:https://www.rfc-editor.org/info/rfc7627 DOI:http://dx.doi.org/10.17487/RFC7627 The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote: > I think it is a good idea to remove DH_anon_* and similar ECDH_anon_* > cipher suites. > > This isn't an endorsement of the raw public key modes. Sure, one can always use self-signed certs (at an even higher cost to do anonymity). If we're going to raise the cost of anonymity for the sake of simplicity in TLS 1.3, do let's try to keep that cost from escalating. Raw public keys are not a large additional complexity cost. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
In addition, they are already part of TLS, so the question would be if we have consensus to remove them -Ekr On Wed, Sep 16, 2015 at 2:01 PM, Nico Williams wrote: > On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote: > > I think it is a good idea to remove DH_anon_* and similar ECDH_anon_* > > cipher suites. > > > > This isn't an endorsement of the raw public key modes. > > Sure, one can always use self-signed certs (at an even higher cost to do > anonymity). If we're going to raise the cost of anonymity for the sake > of simplicity in TLS 1.3, do let's try to keep that cost from > escalating. Raw public keys are not a large additional complexity cost. > > ___ > 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] Call for consensus to remove anonymous DH
On Wednesday, September 16, 2015, Eric Rescorla wrote: > In addition, they are already part of TLS, so the question would be if we > have > consensus to remove them > I see a bunch of +1s and zero -1s. Just saying... -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote: > On Wednesday, September 16, 2015, Eric Rescorla wrote: > > > In addition, they are already part of TLS, so the question would be if we > > have > > consensus to remove them > > > > I see a bunch of +1s and zero -1s. Just saying... I think Eric meant raw public keys. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > In addition, they are already part of TLS, so the question would be if we > have > consensus to remove them > This thread is about the removal of DH_anon_*, not about raw public keys. Cheers, Brian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote: > The suggestion that started this thread was to have a "Standard TLS Profile" > that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels > like a suggestion to keep allowance of obsolete junk as the norm with > "defensive" as a separate option, because that's what it specifically > says. Object to such a profile, and rather than the idea of profiles. There is no need for the TLS WG to define any profiles that include SSL3 or EXPORT ciphers. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 2:25 PM, Brian Smith wrote: > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > >> In addition, they are already part of TLS, so the question would be if we >> have >> consensus to remove them >> > > This thread is about the removal of DH_anon_*, not about raw public keys. > Yes, I'm aware of that. The point I was making was that presently we have: - Certificates - Raw keys - Anon This proposal is to remove Anon, thus making things strictly simpler, since Raw keys can replace Anon but not the other way around. One might imagine a proposal to remove Raw keys, but that's not the question here and even if that failed (as I expect it would) things will still be simpler if we remove Anon. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 2:24 PM, Nico Williams wrote: > On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote: > > On Wednesday, September 16, 2015, Eric Rescorla wrote: > > > > > In addition, they are already part of TLS, so the question would be if > we > > > have > > > consensus to remove them > > > > > > > I see a bunch of +1s and zero -1s. Just saying... > > I think Eric meant raw public keys. > Yes. I'm in favor of removing Anon, which is why I proposed it a few weeks ago. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote: > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > > > In addition, they are already part of TLS, so the question would be if we > > have > > consensus to remove them > > > > This thread is about the removal of DH_anon_*, not about raw public keys. Yes, but you implied that you might not support keeping raw public keys. I'm not in favor of removing the anon cipher suites if we also remove raw public key support. This is important. I don't want the cost of doing anon with TLS to escalate piecemeal. All cards on the table please. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On Wed, Sep 16, 2015 at 06:37:21PM -0400, Dave Garrett wrote: > On Wednesday, September 16, 2015 05:38:27 pm Viktor Dukhovni wrote: > > On Wed, Sep 16, 2015 at 03:03:54PM -0400, Dave Garrett wrote: > > > The suggestion that started this thread was to have a "Standard TLS > > > Profile" > > > that actually allowed EXPORT ciphers & SSL3. So yeah, this proposal feels > > > like a suggestion to keep allowance of obsolete junk as the norm with > > > "defensive" as a separate option, because that's what it specifically > > > says. > > > > Object to such a profile, and rather than the idea of profiles. > > There is no need for the TLS WG to define any profiles that include > > SSL3 or EXPORT ciphers. > > That's a fair point, but I don't see the need for a profile once that > stuff is not allowed anywhere. I could accept the notion of a TLS > strict mode, where it's TLS 1.2 + PFS + AEAD + no > SHA1/DSA/SSL2HELLO/etc. only, but that's not really a "profile" so > much as one paragraph that could be added. Application profiles are > already a thing, so I don't see why we also need a new mechanism here. It's a profile. Call it what you will. The rest of us call this a profile. All the more so when profiles are named in an IANA registry. Applications can then very trivially select an appropriate TLS profile using standard profile naming. > Let me put it this way, I see no way for the WG to reasonably agree on > this without a proposed _set_ of profiles to go with it that we all > could also live with. Just the vague notion of more profiles in > abstract isn't sounding great on its own. We've certainly had a few proposed profiles over time. Your estimation of what the WG would or would not agree to is not as interesting as, you know, actually attempting to get consensus. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 4:07 PM, Dave Garrett wrote: > On Wednesday, September 16, 2015 06:55:02 pm Nico Williams wrote: > > On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote: > > > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote: > > > > In addition, they are already part of TLS, so the question would be > if we > > > > have consensus to remove them > > > > > > This thread is about the removal of DH_anon_*, not about raw public > keys. > > > > Yes, but you implied that you might not support keeping raw public keys. > > > > I'm not in favor of removing the anon cipher suites if we also remove > > raw public key support. This is important. I don't want the cost of > > doing anon with TLS to escalate piecemeal. All cards on the table > > please. > > This appears to just be a miscommunication. > > On Wednesday, September 16, 2015 05:38:05 pm Eric Rescorla wrote: > > This proposal is to remove Anon, thus making things strictly simpler, > since > > Raw keys can replace Anon but not the other way around. One might imagine > > a proposal to remove Raw keys, but that's not the question here and even > if > > that failed (as I expect it would) things will still be simpler if we > > remove Anon. > > The current poll is to remove anon ciphers in favor of raw public keys. > We're not considering removing raw public keys, as far as I know, and I > think most of us would be against that. Isn't this what I said? -Ekr > > > Dave > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote: > This appears to just be a miscommunication. It is not. > The current poll is to remove anon ciphers in favor of raw public > keys. We're not considering removing raw public keys, as far as I > know, and I think most of us would be against that. Once more, with feeling. I would oppose the current proposal if there was to be a follow-on proposal to remove raw public keys, which I wouldn't have even though plausible but for Brian's intimating that he'd be fine with removing raw public keys. Otherwise I would be neutral as to removing anon ciphersuites. I would also be neutral as to removing raw public keys if anon ciphersuites are to remain. Whichever one is removed, I shall oppose the removal of the other. I.e., these two features are interrelated. It is difficult to consider the removal of one without considering the possible removal of the other. I leave it at that. Nico -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wednesday, September 16, 2015 07:23:34 pm Nico Williams wrote: > On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote: > > This appears to just be a miscommunication. > > It is not. > > > The current poll is to remove anon ciphers in favor of raw public > > keys. We're not considering removing raw public keys, as far as I > > know, and I think most of us would be against that. > > Once more, with feeling. I would oppose the current proposal if there > was to be a follow-on proposal to remove raw public keys, which I > wouldn't have even though plausible but for Brian's intimating that he'd > be fine with removing raw public keys. Otherwise I would be neutral as > to removing anon ciphersuites. > > I would also be neutral as to removing raw public keys if anon > ciphersuites are to remain. > > Whichever one is removed, I shall oppose the removal of the other. > > I.e., these two features are interrelated. It is difficult to consider > the removal of one without considering the possible removal of the > other. > > I leave it at that. Yes, I agree with this, and I'm saying that I think that we're all on the same page here. Brian made a point to explicitly not endorse raw keys, but looking back through the messages today, I don't see anyone actually propose removing them. Thus, I said this is likely to be a miscommunication. That's all. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
>> It's a profile. Call it what you will. The rest of us call this a >> profile. All the more so when profiles are named in an IANA registry. >> Applications can then very trivially select an appropriate TLS profile >> using standard profile naming. > > Yeah, we don't need to argue semantics. My point is that I'd agree with a > more strict profile than what we have now as an addon, but not a more > permissive profile, as was the initial suggestion. I think it would be wise to acknowledge the "compatibility" use case, and capture it in a profile. It would be more permissive because it provides compatibility, like SSLv3. And because SSLv3 is represented in a down level profile for those who need it, then it could be removed from standard and more defensive profiles without much fuss. For me, its about acknowledging "one size does not fit all" and managing debates. One size fits all ultimately draws out the process and weakens things even though its not anyone's agenda. >> > Let me put it this way, I see no way for the WG to reasonably agree on >> > this without a proposed _set_ of profiles to go with it that we all >> > could also live with. Just the vague notion of more profiles in >> > abstract isn't sounding great on its own. >> >> We've certainly had a few proposed profiles over time. Your estimation >> of what the WG would or would not agree to is not as interesting as, you >> know, actually attempting to get consensus. > > Agreed, which is why I think this discussion would be more useful with actual > specific profiles to talk about. ;) Right, a concrete list would probably be helpful. The list should probably be based on use cases. * Compatibility - down level servers that can't be upgraded, and clients/UAs that must connect to them * Embedded - low(er) capability crypto, like CAC/PIV cards, smart cards and Hotelier Locks, and similar use cases * Opportunistic - capture email, FTP, etc here. Viktor makes the best arguments here; defer to him * Standard - where the working group would like to be in a typical security posture. * Defensive - where risk adverse folks would like to be in a defensive security posture. Defensive is an interesting profile. I imagine it would include TLS 1.2 and/or 1.3 only, no key transport, authenticated encryption mode ciphers, no HTTPS Pinning Overrides, etc. Then, auditors in industry like healthcare or PCI can call it out by name and everyone is on the same page. The auditors and organizations can worry less about patient or card holder data being leaked because a user was phished or visited another organization (that required a configuration change to use the wireless network). It might also be wise to use "Standard 2015" because in 3 or 5 years, its going to be revised. Then there's no confusion when things are updated an "Standard 2019" becomes available. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 02:38:05PM -0700, Eric Rescorla wrote: > The point I was making was that presently we have: > > - Certificates > - Raw keys > - Anon > > This proposal is to remove Anon, thus making things strictly simpler, since > Raw keys can replace Anon but not the other way around. One might imagine > a proposal to remove Raw keys, but that's not the question here and even if > that failed (as I expect it would) things will still be simpler if we > remove Anon. The difference between raw public keys (RFC7250 RPK) and anon is: - PRO: Dropping anon simplifies the implementation and reduces cipher count. - PRO: Raw keys may facilitate TOFU pinning. - CON: Raw keys are not yet implemented in any toolkits I've seen (a temporary setback perhaps). - CON: Raw keys send more traffic (public key in certificate message, plus signature of key agreement). Byte counts can matter in some environments. - CON: Raw keys consume more CPU (signing the key agreement). - CON: Servers lose a simple signal that the client is not bothering with authentication. The costs are likely noticeable for 4096-bit RSA keys. In the end though, if dropping anon_(EC)DH increases the chance that RPK gets widely implemented, I can live with the cons. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Tue 2015-09-15 21:00:39 -0400, Joseph Salowey wrote: > There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. I support removing anonymous DH for the server side[0] of TLS. TLS servers that want to effectively do "anonymous" DH can craft a raw public key or certificate and forge a signed_params to match. They can do this per-session if they do not want to present a persistent identity. For those worried about computational cost: the raw public key or certificate themselves do not have to be valid mathematical objects if the peer is not inclined to check them. The signed_params itself could also be all 0xff or anything you like as long as the peer isn't checking. For those concerned about bandwidth, these objects do not have to be large. This simplifies the expected messages and transitions in a TLS handshake. I think that's a good thing, given the errors we've seen already in state machine implementations. --dkg [0] I do not think that clients engaged in a DH key exchange should be uniformly required to claim an identity at the TLS layer :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On Wed, Sep 16, 2015 at 07:14:48PM -0400, Dave Garrett wrote: > Yeah, we don't need to argue semantics. My point is that I'd agree with > a more strict profile than what we have now as an addon, but not a more > permissive profile, as was the initial suggestion. I don't think that "permissive" vs. "strict" is the right axis to distinguish between profiles. Rather one axis is "Constrained" vs. "General", and another axis is "Opportunistic" vs. "Mandatory". What's different will be the MTI ciphers, and recommended preferred ciphers. Adding crap banned by the base protocol is not the point. In other words, a profile will have: * MUST support parameters (required interop) * SHOULD support parameters (additional preferred) * MAY support parameters * MUST NOT support parameters that can vary over time independently of other profiles. Then folks can go ahead and drop RC4 with prejudice from "Mandatory", while initially leaving it enabled in "Opportunistic". Which profiles are developed depends on how much interest there is in from particular "market segment" to define said profile. The main question is whether enough interested parties will be willing to work on such profiles. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 08:31:41PM -0400, Daniel Kahn Gillmor wrote: > For those worried about computational cost: the raw public key or > certificate themselves do not have to be valid mathematical objects if > the peer is not inclined to check them. That's not generally possible. Many servers support a mixture of clients, some of which authenticate, and others not. If a server agrees to a cipher that requires signatures, it needs to sign. > The signed_params itself could > also be all 0xff or anything you like as long as the peer isn't > checking. Without "anon_(EC)DH" ciphers in the client HELLO, there's no "I'm not checking" signal. > For those concerned about bandwidth, these objects do not > have to be large. Absent a client signal, this is generally not viable. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed 2015-09-16 20:21:11 -0400, Viktor Dukhovni wrote: > The difference between raw public keys (RFC7250 RPK) and anon is: > > - PRO: Dropping anon simplifies the implementation and reduces > cipher count. > > - PRO: Raw keys may facilitate TOFU pinning. > > - CON: Raw keys are not yet implemented in any toolkits I've seen > (a temporary setback perhaps). > > - CON: Raw keys send more traffic (public key in certificate > message, plus signature of key agreement). Byte counts can > matter in some environments. > > - CON: Raw keys consume more CPU (signing the key agreement). > > - CON: Servers lose a simple signal that the client is not > bothering with authentication. and: - PRO: passive attackers on the network lose a simple signal tha tthe client is not bothering with authentication. > The costs are likely noticeable for 4096-bit RSA keys. A server concerned about CPU or bandwidth costs who would have preferred anon_DH suites would be silly to select 4096-bit RSA, whether RPK or cert. They should choose some small ECC key. A client concerned about CPU who would have been fine with anon_DH will simply not verify the signature at all. So that leaves clients concerned about bandwidth, who pretty much have no choice but to eat the handshake message that the server sends them anyway :/ --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed, Sep 16, 2015 at 5:31 PM, Daniel Kahn Gillmor wrote: > --dkg > > [0] I do not think that clients engaged in a DH key exchange should be > uniformly required to claim an identity at the TLS layer :) I agree with this and that's not the intention. -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
[TLS] consensus: remove DSA from TLS 1.3
All, For the purposes of TLS1.3 specification, it’s clear that there is WG consensus to remove support for DSA the same way many curves from NamedGroup (s6.3.2.2) were removed, i.e., we’re going to remove references, code, etc. If there is interest documenting how to support DSA in TLS1.3, a separate draft will need to be produced and it’ll need to work it’s way through the WG process. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 7627 on Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
Thanks to all who helped to get this published. spt On Sep 16, 2015, at 13:44, rfc-edi...@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > >RFC 7627 > >Title: Transport Layer Security (TLS) Session >Hash and Extended Master Secret Extension >Author: K. Bhargavan, Ed., A. Delignat-Lavaud, >A. Pironti, A. Langley, M. Ray >Status: Standards Track >Stream: IETF >Date: September 2015 >Mailbox:karthikeyan.bharga...@inria.fr, >antoine.delignat-lav...@inria.fr, >alfredo.piro...@inria.fr, >a...@google.com, >ma...@microsoft.com >Pages: 15 >Characters: 34788 >Updates:RFC 5246 > >I-D Tag:draft-ietf-tls-session-hash-06.txt > >URL:https://www.rfc-editor.org/info/rfc7627 > >DOI:http://dx.doi.org/10.17487/RFC7627 > > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > server certificate. Consequently, it is possible for an active > attacker to set up two sessions, one with a client and another with a > server, such that the master secrets on the two sessions are the > same. Thereafter, any mechanism that relies on the master secret for > authentication, including session resumption, becomes vulnerable to a > man-in-the-middle attack, where the attacker can simply forward > messages back and forth between the client and server. This > specification defines a TLS extension that contextually binds the > master secret to a log of the full handshake that computes it, thus > preventing such attacks. > > This document is a product of the Transport Layer Security Working Group of > the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > ___ > 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] Call for consensus to remove anonymous DH
On 9/16/15 at 4:23 PM, n...@cryptonector.com (Nico Williams) wrote: Whichever one is removed, I shall oppose the removal of the other. On 9/17/15 at 5:21 PM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: The costs are likely noticeable for 4096-bit RSA keys. In the end though, if dropping anon_(EC)DH increases the chance that RPK gets widely implemented, I can live with the cons. I agree with both Nico and Viktor. For me the big win of RPK over anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public keys should ease many of Viktor's cons. I also like the idea of simpler implementations. For the question that started this thread, I am neutral. Cheers - Bill -- Bill Frantz| There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Profiles are out of scope for the currently-chartered WG and, as we've seen from previous times these discussions have come up, they tend to overwhelm everything. Please take it off-list. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
On 9/16/15, Jeffrey Walton wrote: > On Wed, Sep 16, 2015 at 4:45 AM, Stephen Farrell > wrote: >> >> >> On 16/09/15 09:19, Peter Gutmann wrote: >>> Jeffrey Walton writes: >>> Somewhat off-topic, why does TLS not produce a few profiles. One can be "Opportunistic TLS Profile" with a compatible security posture and include ADH. Another can be a "Standard TLS Profile" and include things like export grade crypto, weak and wounder ciphers SSLv3, etc. Finally, there can be a "TLS Defensive profile" where you get mostly the strong the protocols and ciphers, HTTPS Pinning Overrides are not allowed so the adversary cannot break the secure channel by tricking a user, etc. >>> >>> +1. At the moment you're stuck with everything-all-the-time (or >>> alternatively >>> one-size-misfits-all) where you have to support every single mechanism >>> and >>> quirk and add-on, when all you want most of the time is to set up a >>> basic >>> secure tunnel from A to B. Having profiles would be a great help, so all >>> the >>> other standards groups that build on TLS can refer to, say, the >>> emebedded- >>> device profile or the PFS-with-PSK profile rather than having to hack >>> around >>> the standard themselves. >> >> We have BCP195 [1] that aims for the "general" case (for >> up to TLS1.2) and a draft [2] (current in IESG evaluation) >> for the embedded case. Are those the kind of thing you're >> after? >> >> If so, and you wanted more, the UTA WG [3] (which produced >> BCP195) would maybe be the best place to see if there's >> enough interest in doing more. (The embedded one was done >> in the DICE WG [4] which was setup mostly for that as it's >> to some extent a different set of folks. And that could be >> done again if needed.) >> > This kinda begs the question, who should be responsible for high level > TLS configurations to ease management, maximize security and minimize > interoperability issues. Isn't that the goal of a reasonable protocol, generally? > For that, I'd argue it falls squarely within TLS WG purview. > > One of the things I've noticed (maybe incorrectly): the NSA and other > who want to exert influence do not have to influence a group like the > TLS WG.* None the less, they (NSA) work to do exactly that for various aspects of the IETF. > There's enough mass and dissension that weakening is organic. > A small selection of profiles could be a strategic move to cut-off > that avenue if it is being taken advantage of. Why not design a protocol that is secure regardless of how it is deployed absent issues with entropy? > Strategic planning is something that should to be led by leadership. Democratic participation is strategic - positions of leadership are subject to capture. Should we really follow the leadership when sometimes they are literally paid by the NSA? > Jeff > > * Maybe I should say, "not actively influence them", like the case of > RSA Data Securities and the Dual EC generator. Those were ECI BULLRUN (and friends) and thus very much active. The IETF is targeted by FVEY (and likely others) for human infiltration and considered fair game. Lots more about BULLRUN remain to be found, I'm sure of it. All the best, Jacob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)
Viktor Dukhovni writes: >Explicit profiles make some sense. They need not be defined by the TLS >WG per-se, it might be enough for the TLS specification to reference an >IANA profile registry, with the TLS-WG defining a "base" profile. Then >other WGs (including the[ TLS WG) can define additional profiles. That would be good, so the base spec could contain text like "This document describes every possible option that the protocol can support. It is not expected that TLS applications implement every one of these options, since many will be inappropriate or unnecessary in many situations. Profiles for specific situations like web browsing, secure tunnels, IoT, embedded devices, and SCADA use can be found at ...". Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
