Re: [TLS] ban more old crap
> What we've cannot yet turn off is RC4. Then do not use TLS 1.3 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote: > > and how a server can tell that the client is TLS1.3 only and not > > TLS1.0-up-to- > > TLS1.3? > > TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 > only. A TLS 1.0-1.2 client, or at least one offering that, is what it > would not complain about. We can probably put the "export" ciphersuite issue out of its misery, already in email, these are no longer seen on the public Internet. The latest official versions of all supported Postfix releases now turn off "export" ciphers (and also single-DES) by default. We've also by default turned off SSLv2 and SSLv3 (neither are needed for SMTP interoperability). What we've cannot yet turn off is RC4. That's still sufficiently widely used that disabling RC4 would result in excessive cleartext fallback and even in some cases failure to deliver email. So for opportunistic TLS (in SMTP) we've raised the bar to exclude deprecated TLS features that we can (finally) easily do without. 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. If I recall correctly, the upcoming OpenSSL 1.1.0 release will by default also compile with no "export" ciphers, SSLv2 or SSLv3 support. We're starting to leave some of the older cruft behind. Let's get Chacha20 widely deployed (for systems without hardware AES), and the passage of time lead to more RC4-only systems being replaced, and in the not too distant future, even opportunistic TLS clients should be able to forgo RC4, but we're not quite there yet today. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Thu, Jul 23, 2015 at 07:10:30PM +0200, Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
>
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draft that adds a
> > column to the registry where we can mark old crap as
> > deprecated?
> >
> > Not sure if it'd work though.
> >
>
> I'm starting to lean towards this. I don't generally think of TLS 1.3 as a
> vehicle
> for telling people how to configure use of TLS 1.2, and I think it might be
> better
> to move all that stuff out.
The MUST/SHOULD list is presumably:
{ECDHE_RSA,ECDHE_ECDSA,PSK}*{AES-128-GCM,AES-256-GCM,Chacha20-Poly1305}?
(9 ciphersuites)? Or are there some others there as well (of course, if
new signatures appear and get their own ciphersuites, then three of those
too)?
Then what to mark as deprecated? Everything that doesn't work with TLS
1.3 is pretty obvious candidate. Which would mean deprecating TLS 1.0 and
1.1, as all ciphersuites for those get deprecated.
Then I made this table of ciphersuites that work with TLS 1.3:
+---+---+---+---+---+
| |AESGCM |VANITY |AESCCM |CHACHA |
+---+---+---+---+---+
|DHE_RSA|Y |Y |Y |P |
|DHE_DSS|Y |Y |Y |- |
|DHE_PSK|Y |Y |- |- |
|DHE_anon |Y |Y |Y |- |
|ECDHE_RSA |Y |Y |- |P |
|ECDHE_ECDSA|Y |Y |Y |P |
|ECDHE_PSK |P |- |P |P |
|ECDHE_anon |- |- |- |- |
|ECDHE_ECIDSA |- |- |- |- |
|PSK|Y |Y |Y |P |
+---+---+---+---+---+
Legend: - => No active proposal,
P => active I-D proposes these,
Y => In registry
AES-GCM => AES-GCM ciphers
VANITY => ARIA and CAMELLIA (GCM). SEED doesn't have AEAD.
AES-CCM => AES-CCM ciphers
CHACHA => Chacha20-Poly1305.
Comments on some methods:
- DHE_RSA: Uses FFDHE, problematic especially on 1.2 and older.
- DHE_DSS: Virtually nobody uses this or will use this (already removed
from two major browsers.
- DHE_PSK: IoT type, but I don't think IoT appriciates FFDHE.
- DHE_anon: Anonymous.
- ECDHE_RSA: ECC certs are still much harder to get than RSA.
- ECDHE_anon: Should add if not deprecating anonymous.
- ECDHE_ECIDSA: New signature scheme. Or try merging this with
ECDHE_ECDSA (requires bit of bending of 1.2 rules).
- PSK: Needed for resumption in TLS 1.3.
-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
* Andrei Popov [25/07/2015 01:26:41] wrote: > Yes, this sounds good to me too. > +1. Aaron signature.asc Description: Digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
Yes, this sounds good to me too. Cheers, Andrei -Original Message- From: Dave Garrett [mailto:davemgarr...@gmail.com] Sent: Friday, July 24, 2015 6:16 PM To: Andrei Popov Cc: Eric Rescorla; tls@ietf.org Subject: Re: [TLS] new error alerts? On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote: > > I'm proposing renaming "insufficient_security" to > > "unsupported_cipher_suites", which is explicitly what it's been for since > > TLS 1.0. > > Not quite. Insufficient_security alert is defined as follows: > " Returned instead of handshake_failure when a negotiation has >failed specifically because the server requires ciphers more >secure than those supported by the client. This message is always >fatal." > > This is a very narrow and specific definition. The server says "I know all > the cipher suites the client advertises, and consider them too weak". By > contrast, unsupported_cipher_suites means something like "I don't have a > cipher suite in common with the client". The latter can happen when the > client's cipher suites are more secure than the server's. Then if we wish to keep this as narrow as written, we can just have a separate one for unsupported with no judgment on strength: insufficient_security(71), // unchanged unsupported_cipher_suites(72), // new unsupported_groups(73), // new client_authentication_failure(74), // new e.g. RC4 gets insufficient_security & Camellia gets unsupported_cipher_suites Sounds good to me, if we prefer this. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
> On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote: >> On Friday 24 July 2015 12:57:42 Dave Garrett wrote: >>> To be clear, the wording I have in the PR is not this broad. It only >>> requires aborting if export ciphers were offered by a TLS 1.3+ client, not >>> just any client. >> >> and how a server can tell that the client is TLS1.3 only and not >> TLS1.0-up-to- >> TLS1.3? > > TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only. > A TLS 1.0-1.2 client, or at least one offering that, is what it would not > complain about. > > For the rare case of "legitimate" use of export ciphers, namely spiders, > it'll need a fallback attempt with a full set of suites. Export ciphers are > not something we should be accounting for allowance of in any protocol we > want to claim to be secure. > > We do have to remember that even _offering_ them is dangerous, even if > they're not negotiated. It's dangerous to even _support_ them, even if not > offering. Having this in any way presents an unacceptable attack surface for > a MitM to try and find a way to confuse implementations into using them. If > all implementations were perfect, yeah, this wouldn't be a problem. History > has shown this is not the case. :( Personally, I don't think this is worth the effort. You'd need a full list of EXPORT cipher hardcoded, and there are also EXPORT1024 ciphers not in the cipher suite registry but less dangerous. It is rare for current TLS 1.2 clients to offer export ciphers either, and most practical attacks are prevented by disabling them on the server side. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote: > On Friday 24 July 2015 12:57:42 Dave Garrett wrote: > > To be clear, the wording I have in the PR is not this broad. It only > > requires aborting if export ciphers were offered by a TLS 1.3+ client, not > > just any client. > > and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to- > TLS1.3? TLS 1.0-1.3 shouldn't be offering export ciphers any more than TLS 1.3 only. A TLS 1.0-1.2 client, or at least one offering that, is what it would not complain about. For the rare case of "legitimate" use of export ciphers, namely spiders, it'll need a fallback attempt with a full set of suites. Export ciphers are not something we should be accounting for allowance of in any protocol we want to claim to be secure. We do have to remember that even _offering_ them is dangerous, even if they're not negotiated. It's dangerous to even _support_ them, even if not offering. Having this in any way presents an unacceptable attack surface for a MitM to try and find a way to confuse implementations into using them. If all implementations were perfect, yeah, this wouldn't be a problem. History has shown this is not the case. :( Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Friday 24 July 2015 12:57:42 Dave Garrett wrote: > On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote: > > And I completely agree. FREAK and Logjam wouldn't happen at all if we > > didn't drag with us stuff that was considered legacy 10 years ago. > > > > But stuff like "server MUST abort handshake if it sees export grade > > ciphers in Client Hello" (or anything similar) will just get ignored. For > > a user a bad connection is better than no connection. One works and the > > other doesn't, the details are voodoo witchcraft. > > To be clear, the wording I have in the PR is not this broad. It only > requires aborting if export ciphers were offered by a TLS 1.3+ client, not > just any client. and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to- TLS1.3? > The point is to ensure that all TLS 1.3 implementations > cut this out and don't regress due to error or exploit. Applying it to > everything would, unfortunately, be a mess. In particular, search engine > spiders actually have a legitimate reason to have export ciphers actually > still enabled. and not only them, opportunistic encryption in SMTP is another example technically it's already in the draft, isn't it? - TLSv1.3 supports only AEAD, all export ciphers were either CBC or stream mode - if you intend to accept only TLS1.3 reply from server there's no point in including them, moreover negotiating them is a clear bug and protocol violation anyway but if you want a "clients SHOULD NOT advertise support for ciphersuites incompatible with TLS1.3 if it will not accept a TLS1.2 or lower protocol reply from server" as a reminder/idea for implementers then it certainly won't hurt -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote: > And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't > drag with us stuff that was considered legacy 10 years ago. > > But stuff like "server MUST abort handshake if it sees export grade ciphers > in > Client Hello" (or anything similar) will just get ignored. For a user a bad > connection is better than no connection. One works and the other doesn't, the > details are voodoo witchcraft. To be clear, the wording I have in the PR is not this broad. It only requires aborting if export ciphers were offered by a TLS 1.3+ client, not just any client. The point is to ensure that all TLS 1.3 implementations cut this out and don't regress due to error or exploit. Applying it to everything would, unfortunately, be a mess. In particular, search engine spiders actually have a legitimate reason to have export ciphers actually still enabled. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] new error alerts?
On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote: > > I'm proposing renaming "insufficient_security" to > > "unsupported_cipher_suites", which is explicitly what it's been for since > > TLS 1.0. > > Not quite. Insufficient_security alert is defined as follows: > " Returned instead of handshake_failure when a negotiation has >failed specifically because the server requires ciphers more >secure than those supported by the client. This message is always >fatal." > > This is a very narrow and specific definition. The server says "I know all > the cipher suites the client advertises, and consider them too weak". By > contrast, unsupported_cipher_suites means something like "I don't have a > cipher suite in common with the client". The latter can happen when the > client's cipher suites are more secure than the server's. Then if we wish to keep this as narrow as written, we can just have a separate one for unsupported with no judgment on strength: insufficient_security(71), // unchanged unsupported_cipher_suites(72), // new unsupported_groups(73), // new client_authentication_failure(74), // new e.g. RC4 gets insufficient_security & Camellia gets unsupported_cipher_suites Sounds good to me, if we prefer this. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)
On Thursday 16 July 2015 18:09:38 Ilari Liusvaara wrote: > > > > 6.3.1.2. (Server Hello) > > > > > > Well, at least it wouldn't be backward compatiblity hazard to remove > > > session_id_len, since it comes after server version. > > > > I'm sold. > > However, that would change ServerHello parsing. > > Thinking about it, if one decides to be careful with message parsing, one > needs to assign all new/modified TLS 1.3 handshake messages new IDs. > > Currently there is only one offending message type w.r.t. that: 14, which > is server_configuration in 1.3 and server_hello_done in 1.2. > > Some other messages share IDs, but I think those are compatible (even > CertificateVerify, as it is just one digital signature in both). Server Key Exchange for DHE, ADH, SRP, etc. not to mention TLS1.1 vs TLS1.2 it's not uncommon to have different parsers for "same" message type > > > Also, the record protection used for early handshake messages should be > > > indicated. > > > > Can you expand on that? > > How does the client know what record protection algorithms are valid > for 0RTT transmission for that server? And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client. > > > Also, with regards to complications of DSA, just dump it? :-) > > > > I'm fine with that if the chairs declare consensus on it. > > As datapoint, either the scan that was used as basis of that curve > pruning doesn't support DSA, or there are no servers that even have > DSA certs. > > I think I heard some time back that there are only 4 (or some other very > small number) valid DSA SSL certs in the entiere public Internet. that scan uses Mozilla trust roots and reports only trusted servers (to weed out unmaintained ones out), Microsoft list is a bit bigger -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ban more old crap
On Thursday 23 July 2015 14:21:15 Dave Garrett wrote: > On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote: > > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell > > > > > wrote: > > > A suggestion - could we remove mention of anything that > > > is not a MUST or SHOULD ciphersuite from the TLS1.3 document > > > and then have someone write a separate draft that adds a > > > column to the registry where we can mark old crap as > > > deprecated? > > > > I'm starting to lean towards this. I don't generally think of TLS 1.3 as a > > vehicle for telling people how to configure use of TLS 1.2, and I think > > it might be better to move all that stuff out. > > If we've learned one thing from the past year of high-profile > vulnerabilities with names and logos, it's that TLS is not really secure if > you don't take into account its weakest/oldest feature that's still > possible. I don't think any responsible TLS 1.3 spec can afford to not > acknowledge this. And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't drag with us stuff that was considered legacy 10 years ago. But stuff like "server MUST abort handshake if it sees export grade ciphers in Client Hello" (or anything similar) will just get ignored. For a user a bad connection is better than no connection. One works and the other doesn't, the details are voodoo witchcraft. The way to remove all this legacy junk is to work towards sensible defaults in libraries (RFC7568, RFC7465 style), not by putting antifeatures in protocol specifications. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
