Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-02.txt
Thanks for the good comments during the meeting. This new version should take care of them all: - Updated the PRF and ECC curves for the AES-256 cipher suites. - Included SHA_256 and SHA_384 in the cipher suite names. - Made it clear which security considerations that apply. For the PSK aspects, I made a short summary. I also made the following changes: - Fixed a wrong reference to the ECC TLS RFC. - Added missing reference to AEAD_AES_128_CCM_8 - Divided the references into Normative and Informal How do we proceed with this now? From my point of view the draft is more or less done, and I do not see much work needed from the tls wg. (As a note, this draft would not have been needed with an a la carte system). Cheers, John On 25/07/15 10:36, "internet-dra...@ietf.org" wrote: > >A new version of I-D, draft-mattsson-tls-ecdhe-psk-aead-02.txt >has been successfully submitted by John Mattsson and posted to the >IETF repository. > >Name: draft-mattsson-tls-ecdhe-psk-aead >Revision: 02 >Title: ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport >Layer Security (TLS) >Document date: 2015-07-24 >Group: Individual Submission >Pages: 6 >URL: >https://www.ietf.org/internet-drafts/draft-mattsson-tls-ecdhe-psk-aead-02. >txt >Status: >https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ >Htmlized: >https://tools.ietf.org/html/draft-mattsson-tls-ecdhe-psk-aead-02 >Diff: >https://www.ietf.org/rfcdiff?url2=draft-mattsson-tls-ecdhe-psk-aead-02 > >Abstract: > This memo defines several new cipher suites for the Transport Layer > Security (TLS) protocol. The cipher suites are all based on the > Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key > (ECDHE_PSK) key exchange together with the Authenticated Encryption > with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK > provides light and efficient authentication, ECDHE provides perfect > forward secrecy, and AES-GCM and AES-CCM provides encryption and > integrity protection. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
(no hats and al that) On 25/07/15 06:46, Viktor Dukhovni wrote: > I hope, that by ~2017, RC4 will no longer be required either, and > we'll be able to disable RC4 in Postfix at that time. Seems to me that should be a reasonable match for expecting to see TLS1.3 getting deployed in lots of parts of the mail infrastructure, so that date would argue to not support rc4 at all in TLS1.3 in my conclusion (not that I know much about mail deployment trends). And if we have any support for rc4 in TLS1.3 it'll end up a footgun that'll damage many toes, so count me amongst those arguing for no rc4 (or similar) at all in TLS1.3. Cheers, S. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
> On 25/07/15 06:46, Viktor Dukhovni wrote: >> I hope, that by ~2017, RC4 will no longer be required either, and >> we'll be able to disable RC4 in Postfix at that time. > > Seems to me that should be a reasonable match for expecting to see > TLS1.3 getting deployed in lots of parts of the mail infrastructure, > so that date would argue to not support rc4 at all in TLS1.3 in my > conclusion (not that I know much about mail deployment trends). > > And if we have any support for rc4 in TLS1.3 it'll end up a footgun > that'll damage many toes, so count me amongst those arguing for no > rc4 (or similar) at all in TLS1.3. +1, though, my understanding was that RC4 was already out of TLS 1.3.. In general I think we could all agree that we should never keep broken stuff in TLS even if it is used a lot… Best, B. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
To be clear: TLS 1.3 does not support RC4. The only question is whether it's legal to concurrently offer RC4 with TLS 1.3 for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC even though TLS 1.3 does not support it.) I am trying to work through this myself, as the interactions with browser fallback are very complex. -Ekr On Sat, Jul 25, 2015 at 3:41 PM, Benjamin Beurdouche < benjamin.beurdou...@inria.fr> wrote: > > > On 25/07/15 06:46, Viktor Dukhovni wrote: > >> I hope, that by ~2017, RC4 will no longer be required either, and > >> we'll be able to disable RC4 in Postfix at that time. > > > > Seems to me that should be a reasonable match for expecting to see > > TLS1.3 getting deployed in lots of parts of the mail infrastructure, > > so that date would argue to not support rc4 at all in TLS1.3 in my > > conclusion (not that I know much about mail deployment trends). > > > > And if we have any support for rc4 in TLS1.3 it'll end up a footgun > > that'll damage many toes, so count me amongst those arguing for no > > rc4 (or similar) at all in TLS1.3. > > +1, though, my understanding was that RC4 was already out of TLS 1.3.. > In general I think we could all agree that we should never keep broken > stuff in TLS even if it is used a lot… > > Best, > B. > > > ___ > 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] Review of PR #209
Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209 The first expands the ways in which a server can identify certificates. This is fine. I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately). The second is worrisome. I don't like that a handshake message now has two different potential locations that it might appear in. That seems like a hazard. I think that we need a new content type for a new message that can be used after the handshake completes. Then there are two options: a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses) b) use CertificateRequest within the handshake, and the new content type outside of it ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On 25 July 2015 at 16:13, Eric Rescorla wrote: > The only question is whether it's legal to concurrently offer RC4 with TLS > 1.3 > for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC > even though TLS 1.3 does not support it.) I am trying to work through this > myself, as the interactions with browser fallback are very complex. And the strategies vary. It might be that we don't need to worry about this, because we might have widely disabled RC4 by the time TLS 1.3 ships. https://ipv.sx/telemetry/rc4.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
> And the strategies vary. It might be that we don't need to worry about this, > because we might have widely disabled RC4 by the time TLS > 1.3 ships. "we" meaning browsers. "we" not being everyone who will use TLS 1.3 Ekr has pointed out a problem; if you connect with a protocol range and proffer RC4, can we do anything about it except point out multiple times that 1.3 servers MUST NOT accept it? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On 25 July 2015 at 17:48, Salz, Rich wrote: > "we" meaning browsers. "we" not being everyone who will use TLS 1.3 > > Ekr has pointed out a problem; if you connect with a protocol range and > proffer RC4, can we do anything about it except point out multiple times that > 1.3 servers MUST NOT accept it? Agreed. But I'll point out that other users of TLS will likely not be doing fallback either, so they have to deal with offering what they support straight up. Prohibiting RC4 probably won't do anything more than what our existing efforts are doing already. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Sat, Jul 25, 2015 at 06:54:36AM +, Salz, Rich wrote: > > What we've cannot yet turn off is RC4. > > Then do not use TLS 1.3 Actually, we can use TLS 1.3, just not with peers that only do RC4. Provided the 1.3 servers don't do anything actively hostile and terminate the handshake when they see RC4-SHA1 offered among other more acceptable ciphersuites. I was definitely not arguing for inclusion of RC4 in TLS 1.3. I am more than happy with AEAD-only in TLS 1.3, with no RC4. When an opportunistic TLS client that supports TLS 1.0--1.3, and includes RC4 in its list of ciphersuites, connects to a 1.3 server RC4 will not be the negotiated ciphersuite when the server decides to use 1.3. I was just noting for the record, that even with opportunistic TLS we've already made some progress in getting rid of "old crap", but not yet all. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Sat, Jul 25, 2015 at 07:01:42PM +0200, Martin Thomson wrote: > On 25 July 2015 at 17:48, Salz, Rich wrote: > > "we" meaning browsers. "we" not being everyone who will use TLS 1.3 > > > > Ekr has pointed out a problem; if you connect with a protocol range and > > proffer RC4, can we do anything about it except point out multiple times > > that 1.3 servers MUST NOT accept it? > > > Agreed. But I'll point out that other users of TLS will likely not be > doing fallback either, so they have to deal with offering what they > support straight up. > > Prohibiting RC4 probably won't do anything more than what our existing > efforts are doing already. I would go further, and say that "prohibiting RC4" in any sense that is more than prohibiting its use as the final outcome of a handshake would be a rather counter-productive strategy. Servers and clients are strongly encouraged to not choose it, but to reject connections from peers that offer it for interoperability with others would just create a mess that would be operationally challenging. RC4 is dying, just let it fade away into insignificance. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] 0-RTT & resumption
I'm pretty sure some/all of this was likely mentioned elsewhere, but I don't see any discussion on-list. (it was mentioned in part of the IETF 93 recording I watched as this whole topic needing to go to the list, as well) There's also related TODOs in the draft on this topic. Here's a start to this discussion. Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT connections using the known configuration extension & PSK-based session resumption. I don't think their roles are well defined yet. 1) There is no 0-RTT resumption. The point of resumption is to get back into the session quick, but it's arguably slower than not doing it, currently. 0-RTT can do first flight (repeatable) requests: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 but PSK-based resumption needs 1-RTT: https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 2) There's not yet specifics on what cipher suite to use for PSK-based resumption. I don't see a point in doing PSK-based resumption with anything other than plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work for DH, just go straight to normal 0-RTT to get more benefit/flexibility with a similar amount of work. The goal is really to get forward secrecy on the session, not necessarily every single connection within it. (not that it wouldn't be nice) As long as the resumption is within a reasonably short window (e.g. few minutes), not doing another DH is fine. After this window, normal 0-RTT should be the preferred route. 3) Just to state the obvious: If a client is going to do PSK resumption with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not really going to be negotiated for anything else, I don't really like the feel of this. I think it'd also be cleaner if the offered suites didn't have to change for resumption. One idea would be to rename the groups extension, again, to "supported_key_shares" and mark point 0 (or some other if we want to leave 0) as PSK-resumption, specifically. (_not_ general PSK) A resumption PSK offer could then be listed in the ClientKeyShare like any other, and negotiation of it could side-step the need to pick a new cipher. Mixing it in with regular PSK complicates things a bit and has an expectation of needing to offer a PSK suite with the PSK extension. In this case, it'd just be the previously used suite. 0-RTT becomes a little more straightforward: give both short-term resumption via PSK and mid-term semi-static secret 0-RTT clear expiration dates, then the first flight data is just encrypted using whatever is still valid. Worst case scenario is the server ditched the session early and it falls back to 1-RTT. (double-encrypting early data might work, but would be ugly) This sort of re-separates PSK & resumption a little bit, though the handling is still similar. 4) Related issue: maybe define a generic KeyShare struct (group+key_exchange), simplify the few spots to use these, then allow ServerConfiguration to offer a vector of KeyShares? Alternatively, just have one KeyShare in there and offer a vector of ServerConfiguration in the message so each has an expiration date. If we want the possibility of ServerConfiguration being obtainable through alternate means, then it might help for a server to be able to offer two keys with different curves to make support easier to offer. (e.g. P-256 & Curve25519, as we may be transitioning this way for a bit; could be ECC & PQ of some kind, in the future) This might make constructing a 0-RTT first-connect system a little easier. Not a solid proposal, really; just some discussion on the topic. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote: > I would go further, and say that "prohibiting RC4" in any sense > that is more than prohibiting its use as the final outcome of a > handshake would be a rather counter-productive strategy. > > Servers and clients are strongly encouraged to not choose it, but > to reject connections from peers that offer it for interoperability > with others would just create a mess that would be operationally > challenging. RC4 is dying, just let it fade away into insignificance. I agree. The current draft language of not offering or negotiating RC4 is fine, as-is. My proposal of stopping tolerance of garbage suite offers is just for <112-bit junk. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 0-RTT & resumption
On Sat, Jul 25, 2015 at 02:53:17PM -0400, Dave Garrett wrote: > 3) Just to state the obvious: If a client is going to do PSK resumption > with a non-PFS suite, it needs to offer a non-PFS suite. Forward-secrecy is not about doing or not doing DHE/ECDHE those are just means to an end. Forward-secrecy is about retaining confidentiality of past traffic even when long-term secrets (for TLS server private keys) are later disclosed. With that in mind, resumption without DHE/ECDHE has the same forward-secrecy as the original session. The session master secret is not a "long-term" secret. > Even if it's not > really going to be negotiated for anything else, I don't really like the > feel of this. I think it'd also be cleaner if the offered suites didn't > have to change for resumption. Perhaps I am missing something, but I see no reason for the offered ciphersuites to change. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 0-RTT & resumption
On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett wrote: > I'm pretty sure some/all of this was likely mentioned elsewhere, but I > don't see any discussion on-list. (it was mentioned in part of the IETF 93 > recording I watched as this whole topic needing to go to the list, as well) > There's also related TODOs in the draft on this topic. Here's a start to > this discussion. > > Basically, there's two modes with similar use-cases in TLS 1.3 now: 0-RTT > connections using the known configuration extension & PSK-based session > resumption. I don't think their roles are well defined yet. > > 1) There is no 0-RTT resumption. The point of resumption is to get back > into the session quick, but it's arguably slower than not doing it, > currently. > > 0-RTT can do first flight (repeatable) requests: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.3 > but PSK-based resumption needs 1-RTT: > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4 We agreed on how to do this in Prague. The sticking point was establishing the cipher suite. I have WIP text on my machine for both of these which I will be sending early next week, once I get enough sleep to be able to clean it up, so I'd ask people to sit tight till then. 2) There's not yet specifics on what cipher suite to use for PSK-based > resumption. The consensus in Prague was that you should have to use a matching symmetric cipher suite. I don't see a point in doing PSK-based resumption with anything other than > plain PSK, with no PFS (no (EC)DHE). If you're willing to do the extra work > for DH, just go straight to normal 0-RTT to get more benefit/flexibility > with a similar amount of work. The goal is really to get forward secrecy on > the session, not necessarily every single connection within it. (not that > it wouldn't be nice) As long as the resumption is within a reasonably short > window (e.g. few minutes), not doing another DH is fine. After this window, > normal 0-RTT should be the preferred route. > I don't think this is correct. The reason is that resumption also resumes the client's authentication state, and client authentication often involves user interaction, which is undesirable from the site's perspective. So, it's actually quite attractive to do resumption with (EC)DHE. It's also significantly faster if you have an RSA certificate. > 3) Just to state the obvious: If a client is going to do PSK resumption > with a non-PFS suite, it needs to offer a non-PFS suite. Even if it's not > really going to be negotiated for anything else, I don't really like the > feel of this. I think it'd also be cleaner if the offered suites didn't > have to change for resumption. One idea would be to rename the groups > extension, again, to "supported_key_shares" and mark point 0 (or some other > if we want to leave 0) as PSK-resumption, specifically. Yeah, we discussed this internally, but I think it's clumsy. I'd rather just offer two separate cipher suites. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Sat, Jul 25, 2015 at 03:00:54PM -0400, Dave Garrett wrote: > On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote: > > I would go further, and say that "prohibiting RC4" in any sense > > that is more than prohibiting its use as the final outcome of a > > handshake would be a rather counter-productive strategy. > > > > Servers and clients are strongly encouraged to not choose it, but > > to reject connections from peers that offer it for interoperability > > with others would just create a mess that would be operationally > > challenging. RC4 is dying, just let it fade away into insignificance. > > I agree. The current draft language of not offering or negotiating > RC4 is fine, as-is. My proposal of stopping tolerance of garbage > suite offers is just for <112-bit junk. If you mean the export suites plus the non-export single-DES suites (these are only suites that I know to meet the above criterion), and the idea is to refuse client connections when these are offered, that's still rather aggressive. Is that really necessary? The browsers will disable these through software updates, consumers don't configure browser cipher suites. For non-browser applications, a lot of administrators would face mostly unnecessary interoperability issues and would have to reconfigure client systems to disable cipher suites already disabled on the server end. Is the benefit worth the cost. They'll upgrade their systems to ones that don't implement these features in due course without duress. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
