Subject: [TLS] A la carte concerns from IETF 93

From: Dave Garrett <[email-masked]>
Date: Wed, 22 Jul 2015 16:10:27 -0400

Consensus was my current WIP proposal is not viable, for some of the following main reasons:

1) cost/benefit analysis doesn't seem to be worth it
2) backwards compatibility handling
3) some argue harder to implement; others argue easier

To start, I'll note that I have not submitted a PR yet.

This is all currently just on a WIP branch on GitHub to be easier to discuss specifics on-list. It's based on PR #201, but that's just to make keeping track of things easier. This is less of an issue now that my other PRs were merged (namely the updated cipher suite section).

I'll switch to a standalone proposal for the next draft instead of editing the section inline, as it was indicated that would be easier to follow. Not everyone was a party to every discussion on-list about these topics, so a better summary is needed.

On to the concerns:

1) The cost/benefit analysis is a very important concern. If you're only analyzing this from a perspective of combinatorial explosion reduction, then I actually agree it's not worth the cost. Here's how I perceive it, currently:

benefit:
+ reduction in combinatorial mess (primarily achieved as we move forward, as back compat still needs to offer some old)
+ single point of negotiation for (EC)DHE
+ single point of negotiation for certificates (seemed to be wide agreement to do this regardless of full a la carte)
+ deprecation of existing DHE suites which risk wanting weak groups depending on server and are an interop hazard due to Java being crap
+ ECC is always an option, regardless of suite offer/selection
+ FFDHE doesn't need new suites to be offered by clients not offering DHE AEAD at the moment
+ missing combinations are no longer an interop failure

cost:
- change has risks of mistake at various points (implementation, deployment, admin, client config, etc.)
- support for TLS 1.2 + 1.3 results in a mix; old suites still need to be offered
- risk of confusion due to change in behavior (point #2 above)

depends:
+/- point #4, depending on implementation

(the number of points in this list is not indicative of weight; the first cost could outweigh all benefits, depending on perspective)

Additionally mentioned cost:
- cannot specify exact combinations; some might not be desirable

However, I set this one aside because it's a problem with a full a la carte proposal, but not my current one. All possible combinations of DHE/ECDHE+RSA/DSS/ECDSA/PSK/anon+cipher_hash are already considered valid, and generally have their own suite assignments. I'm not suggesting breaking up cipher_hash. Cert/PSK/anon still have to have separate suites in this system, which prohibits wrong stuff like none_anon (lack of DH from plain PSK + anon). If we ditch suites entirely, as was suggested by others, then this is a risk that comes up.

The main difference in my calculus vs. others is that:
a) I'm swayed by Tony Arcieri's argument that DHE, as it currently exists, needs to be scrapped. Old Java chokes on it and there is a risk of servers negotiating weak groups when offering it. Deprecating all DHE suites is an interop and security win. FFDHE is still around, but now with only strong groups, whereas without this proposal we go ECC or bust (until something post-quantum is a viable option here).
b) ECC isn't separate anymore; it's always expected to be available. We don't have to worry about endpoints actually offering suites that claim support, as it's just a given now.
c) Interop failure due to missing suites, regardless of algorithm support, is no longer a risk. It's currently possible to negotiate CBC because the GCM suites offered by the server are combinations not supported by the client, even though GCM is supported. (this does happen in the real world and is too often overlooked in this discussion)

2) Backwards compatibility is pretty straightforward.

Here's what Firefox currently offers, minus RC4 & 3DES:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

The current TLS 1.3 draft would only accept the top two as viable (only AEAD). Both my current proposal and the general consensus minimum would pick just the top one and pick certs based on the extension.

Note that DHE/FFDHE is available, but only for AES CBC with RSA. The second change here is that my proposal allows DHE with no changes to this list. Yeah, we'd like to move to an ECC only world, but I'm paranoid and want a backup. This gives it effortlessly. This would also permit FFDHE+ECDSA combinations without new suites. All DHE suites could be dropped in the future, in favor of ECDHE only on old TLS but the possibility of FFDHE on new. If you want to keep around FFDHE without this proposal, you need to add those suites for GCM.

Just to make sure it's emphasized, the current path without this proposal would require Firefox add the following in order to use the new FFDHE groups:
TLS_DHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Mozilla probably doesn't want to do that. Negotiating the new FFDHE groups might be acceptable, but whatever weaker junk you get without them is not. I guess a higher minimum could be put in place for AEAD suites or TLS 1.3+, but now we're already adding complexity.

Once we get out of the AES monoculture, it's also the difference between adding:
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_DHE_RSA_WITH_CHACHA20_POLY1305
TLS_DHE_ECDSA_WITH_CHACHA20_POLY1305
or just:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

I'll also add that DHE_ECDSA suites just aren't defined. Yes, using the cert extension could let us get this combo via DHE_RSA, but that means offering RSA suites for everything old and new.

As to the need to list all this stuff to work:
If you want everything to be clean, abandon TLS and go for something QUIC based. Backwards compatibility is messy; that's one of the reasons why you shouldn't want it forever.

3) I argue that framing the negotiation in a manner more similar to what is actually being negotiated reduces the risk of problems. _Not_ doing so has the following issues:

a) Offering an ECDHE suite will offer FFDHE groups via the upgraded extension, but no ability for a server to pick it if the right combo for DHE isn't there. The server can't select the 4k FF group if it'd rather have that than P-256 because no better curve is available.
b) ECHDE/DHE has to be chosen based on cipher suite priority, rather than actually looking at the groups' priority and picking the one that should be preferred. Contrary to suite definitions, ECDHE and DHE are not monolithic things.
c) The server should be able to offer any certs the client can use, regardless of connection encryption. (again, this part seems to have wide agreement)

---

That covers the main issues. There's also the issue of making sure that any new system is understandable and doesn't introduce points of confusion down the road.

I don't claim that this addresses everything that has been or can be said, but I also don't want to post a larger wall of text than this. ;)

Also, others may likely not care about FFDHE as much as I do. It is, however, in the current draft on essentially equal footing with ECC. As such, I'm considering it that way in discussion and proposals. This proposal is shaped by the negotiated FF-DH draft and its integration into the current TLS 1.3 draft.

Dave

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Jul 2015 13:09:49 +0200

> admin, client config, etc.)

and server/client config is a huge cost

vast swaths of web servers are misconfigured; introducing a more complex 
mechanism to server configuration when the existing situation is 
incomprehensible to many administrators won't help (and even many people that 
write the various blog posts about "how to configure SSL [sic] in httpd" 
clearly haven't read openssl ciphers(1) man page)

any changes like this will require new APIs for configuration, that in turn 
means that not only libraries will need to be modified to add support for 
TLS1.3 configuration but applications too - that will slow adoption
-- 
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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Jul 2015 14:54:46 +0300

> 3) some argue harder to implement; others argue easier

IMO, the present situation is mainly problem for:

1) Users: Not having combinations they want (whitness the recent
   proposal for ECDHE_PSK ciphersuites). Sometimes leads to
   suboptimal ciphersuite choices.
2) TLS WG: Processing all the complaints about previous.
3) Admins: Configuring the mess.

What isn't in the list: TLS library authors: Most TLS libraries
have decoding tables (or equivalent) that break down ciphersuite
down to its component parts.

Using strict interpretation of TLS 1.2 rules, adding all the
relevant combinations would be about 100 ciphersuites (haven't
checked how many already exist).

Granted, not all of those are equally important. But that
brings question of what are important and what are not.

Also, if SHA-2 ever fails, defining the replacement ciphersuites
is going to be "fun".

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Thu, 23 Jul 2015 11:43:45 -0400

> clearly haven't read openssl ciphers(1) man page)

We should just get more serious about banning old crap entirely to make dangerous misconfiguration impossible for TLS 1.3+ implementations.

Right now, the restrictions section prohibits:
RC4, SSL2/3, & EXPORT/NULL entirely (via min bits)
and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available

How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal error. (the wrench in this is plain PSK, which should be restricted to resumption within a short window; IoT people who want to use intentionally weak security can write their own known weak spec)

By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be badly configured to only allow it with DSS, because missing combos from the cipher suite nonsense happen. If we actually have to care about IE on XP, we could state an exception that the only non-PFS cipher suite to be permitted on servers for backwards compatibility is TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Also add a requirement that all config provided by the admin must be validated to meet the TLS 1.3 requirements and auto-corrected if not, with a warning if there's an issue.

This doesn't have to be a mess for admins to sort out.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jul 2015 16:00:34 +0000

> and has "SHOULD" use TLS 1.3+ compatible with TLS 1.2, if available

So much for using NULL ciphers for client-server authentication on
loopback interfaces. :-(

Surely, in at least some cases, making it harder to make mistakes
needs to be addressed in toolkit and application interfaces, not
the protocol.  Removing weak algorithms that serve the same use-cases
poorly is fine, but removing non-traditional use-cases is perhaps
too drastic.

> Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> or abort with a fatal error.

Who's going to police the Internet to remove all the legacy services?

> By the way, even IE6 on XP supports DHE.

But not Exchange server 2003, and various Windows-based email gateway
appliances.

> If we actually have to care about IE on
> XP, we could state an exception that the only non-PFS cipher suite to be
> permitted on servers for backwards compatibility is
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Exchange 2003 has a broken 3DES implementation.  The only working
ciphersuites are RC4-SHA/RC4-MD5.

And there are surely plenty of legacy system that are neither HTTPS
or email.  It sure sounds like the radical surgery is largely for
HTTPS, and should be implemented in web servers and clients, not
the TLS protocol.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 23 Jul 2015 12:43:40 -0400

> Who's going to police the Internet to remove all the legacy services?

I'm not proposing a non-PFS diediedie RFC; just that no TLS 1.3+ server should ever be willing to negotiate non-PFS. (again, with very limited possible exceptions)

I was probably unclear, but I'm primarily talking about server-side here, as it was a reply to a server-side issue. Clients SHOULD only be negotiating PFS, but I think servers MUST only negotiate PFS.

> ciphersuites are RC4-SHA/RC4-MD5.

RC4 already got a diediedie RFC. If their 3DES stays broken, and nothing better is available, it's already considered illegitimate to continue using. Also, I don't care. It is not the role of the TLS 2015 WG to work around bugs in abandoned software from 12 years ago.

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jul 2015 18:06:04 +0100

On 23/07/15 16:43, Dave Garrett wrote:
> We should just get more serious about banning old crap entirely to
> make dangerous misconfiguration impossible for TLS 1.3+
> implementations.
> 
> Right now, the restrictions section prohibits: RC4, SSL2/3, &
> EXPORT/NULL entirely (via min bits) and has "SHOULD" use TLS 1.3+
> compatible with TLS 1.2, if available

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.

S.

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 23 Jul 2015 10:11:08 -0700

It is Windows Server 2003 SMTP service that has this problem.
There is a hotfix for it.
I had been asking for these fixes to be pushed out and the KB article corrected before Windows Server 2003 ended support.

> Date: Thu, 23 Jul 2015 16:00:34 +0000
> From: [email-masked]
> To: [email-masked]
> Subject: Re: [TLS] ban more old crap (was: A la carte concerns from IETF 93)
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Jul 2015 19:10:30 +0200

> 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.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Jul 2015 19:14:40 +0200

> Not sure if it'd work though.

https://tools.ietf.org/html/rfc7525 lists 4 RECOMMENDED ciphers, 6 if you 
include ECDSA versions

---

From: Hubert Kario <[email-masked]>
Date: Thu, 23 Jul 2015 19:11:38 +0200

On Thursday 23 July 2015 11:43:45 Dave Garrett wrote:
> > incomprehensible to many administrators won't help (and even many people
> > that write the various blog posts about "how to configure SSL [sic] in
> > httpd" clearly haven't read openssl ciphers(1) man page)
> 
> We should just get more serious about banning old crap entirely to make
> dangerous misconfiguration impossible for TLS 1.3+ implementations.

there are valid use cases for both aNULL and eNULL
at the same time 3.5% of Alexa top 1 million will negotiate AECDH, somehow I 
doubt this many use it knowingly when ADH has just 0.2% market share

TLS is a universal protocol, that means that something that is a dangerous 
misconfiguration in one threat model is entirely valid and good configuration 
in other

IoT and cloud computing will create a market for an implementation that is 
compatible with many threat models

> How about we stop being fuzzy? I'd like to make it "MUST" use AEAD with all
> TLS 1.2+ connections, or abort with a fatal error. Plus, "MUST" use DHE or
> ECDHE for ALL connections, even back to TLS 1.0, or abort with a fatal
> error. (the wrench in this is plain PSK, which should be restricted to
> resumption within a short window; IoT people who want to use intentionally
> weak security can write their own known weak spec)

yes, it would make situation better, thing is, nobody would implement this and 
nobody would deploy it (certainly not Red Hat).
People care more for availability of data than for confidentiality or 
integrity.

> By the way, even IE6 on XP supports DHE. Windows XP, however, appears to be
> badly configured to only allow it with DSS, because missing combos from the
> cipher suite nonsense happen. If we actually have to care about IE on XP,
> we could state an exception that the only non-PFS cipher suite to be

and that would prevent the server from never selecting DHE+RSA or client 
aborting the connection when server selects DHE+RSA how exactly?

> Also add a requirement that all config provided by the admin must be
> validated to meet the TLS 1.3 requirements and auto-corrected if not, with
> a warning if there's an issue.
> 

but it is, and for histerical reasons it will remain like this

so given choice I prefer my mess to be at least consistent between versions
-- 
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

---

From: Dave Garrett <[email-masked]>
Date: Thu, 23 Jul 2015 14:21:15 -0400

On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> 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

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.

That said, if all you want to move out are things that aren't MUSTs or SHOULDs, I don't see a problem with that. (with possibly the exception of a "NOT RECOMMENDED" or two, though that's really just a synonym for "SHOULD NOT") What would that actually entail? Or, did you just mean to cut out all non-MUST/SHOULD cipher suites? I also don't see a problem with that. I just updated the list with everything. The full list can go in a separate document if we want to just focus on MUST/SHOULD support ciphers in the spec, proper.

Also on the topic of cutting out hunks of text, someone should write up a DSS/DSA removal PR. There's quite a bit of text scattered throughout the spec to handle it that we don't need anymore.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Jul 2015 09:41:19 +0300

> column to the registry where we can mark old crap as

Checked the ciphersuite registry. Of 316 negotiable ciphers,
marking everything that doesn't work in TLS 1.3 or is DSS
ciphersuite (nobody uses that) would leave 52 ciphersuites
undeprecated.

Unfortunately, completing the various sets could add up to
31 new ciphersuites... :-/

Flags:
A => Anonymous (6+8)
D => Dubious use (6+1). I guess IoT devices don't appreciate FFDHE.
F => FFDHE (26+3)
I => IoT foucus (18+12)
N => New signature type (0+11), merging would take bending TLS 1.2 rules.
R => RSA signature type with ECDHE (6+1)
V => Vanity (24+8)

The 52 are:
--F-- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
--F-- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
A-F-- TLS_DH_anon_WITH_AES_128_GCM_SHA256
A-F-- TLS_DH_anon_WITH_AES_256_GCM_SHA384
----- TLS_PSK_WITH_AES_128_GCM_SHA256
----- TLS_PSK_WITH_AES_256_GCM_SHA384
-DFI- TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
-DFI- TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
----- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
----- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
----R TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
----R TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
--FV- TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256
--FV- TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384
A-FV- TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
A-FV- TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
---V- TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
---V- TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
---VR TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
---VR TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
---V- TLS_PSK_WITH_ARIA_128_GCM_SHA256
---V- TLS_PSK_WITH_ARIA_256_GCM_SHA384
-DFV- TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256
-DFV- TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384
--FV- TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
--FV- TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
A-FV- TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
A-FV- TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
---V- TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
---VR TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
---VR TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
---V- TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
---V- TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
-DFV- TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
-DFV- TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
-DFI- TLS_DHE_RSA_WITH_AES_128_CCM
-DFI- TLS_DHE_RSA_WITH_AES_256_CCM
-DFI- TLS_DHE_RSA_WITH_AES_128_CCM_8
-DFI- TLS_DHE_RSA_WITH_AES_256_CCM_8
---I- TLS_PSK_WITH_AES_128_CCM
---I- TLS_PSK_WITH_AES_256_CCM
-DFI- TLS_DHE_PSK_WITH_AES_128_CCM
-DFI- TLS_DHE_PSK_WITH_AES_256_CCM
---I- TLS_PSK_WITH_AES_128_CCM_8
---I- TLS_PSK_WITH_AES_256_CCM_8
-DFI- TLS_PSK_DHE_WITH_AES_128_CCM_8
-DFI- TLS_PSK_DHE_WITH_AES_256_CCM_8
---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
---I- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
---I- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8

And the new 31 would be:
----R TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
----- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
--F-- TLS_DHE_RSA_WITH_CHACHA20_POLY1305
----- TLS_PSK_WITH_CHACHA20_POLY1305
---I- TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305
-DFI- TLS_DHE_PSK_WITH_CHACHA20_POLY1305
---I- TLS_ECDHE_PSK_WITH_AES_128_GCM
---I- TLS_ECDHE_PSK_WITH_AES_256_GCM
---I- TLS_ECDHE_PSK_WITH_AES_128_CCM_8
---I- TLS_ECDHE_PSK_WITH_AES_256_CCM_8
---I- TLS_ECDHE_PSK_WITH_AES_128_CCM
---I- TLS_ECDHE_PSK_WITH_AES_256_CCM
A---- TLS_ECDH_anon_WITH_AES_128_GCM_SHA256
A---- TLS_ECDH_anon_WITH_AES_256_GCM_SHA384
A--V- TLS_ECDH_anon_WITH_ARIA_128_GCM_SHA256
A--V- TLS_ECDH_anon_WITH_ARIA_256_GCM_SHA384
A--V- TLS_ECDH_anon_WITH_CAMELLIA_128_GCM_SHA256
A--V- TLS_ECDH_anon_WITH_CAMELLIA_256_GCM_SHA384
A---- TLS_ECDH_anon_WITH_CHACHA20_POLY1305
A-F-- TLS_DH_anon_WITH_CHACHA20_POLY1305
----N TLS_ECDHE_ECIDSA_WITH_AES_128_GCM_SHA256
----N TLS_ECDHE_ECIDSA_WITH_AES_256_GCM_SHA384
---VN TLS_ECDHE_ECIDSA_WITH_ARIA_128_GCM_SHA256
---VN TLS_ECDHE_ECIDSA_WITH_ARIA_256_GCM_SHA384
---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_128_GCM_SHA256
---VN TLS_ECDHE_ECIDSA_WITH_CAMELLIA_256_GCM_SHA384
---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM
---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM
---IN TLS_ECDHE_ECIDSA_WITH_AES_128_CCM_8
---IN TLS_ECDHE_ECIDSA_WITH_AES_256_CCM_8
----N TLS_ECDHE_ECIDSA_WITH_CHACHA20_POLY1305

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Fri, 24 Jul 2015 12:43:17 +0200

On Thursday 23 July 2015 14:21:15 Dave Garrett wrote:
> > On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> > <[email-masked]>> 
> > wrote:
> > 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.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 24 Jul 2015 12:57:42 -0400

> 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

---

From: Hubert Kario <[email-masked]>
Date: Fri, 24 Jul 2015 19:18:41 +0200

On Friday 24 July 2015 12:57:42 Dave Garrett 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

---

From: Dave Garrett <[email-masked]>
Date: Fri, 24 Jul 2015 14:03:13 -0400

> and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to-

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

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 24 Jul 2015 11:13:41 -0700

> 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 unacce…

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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Jul 2015 08:35:49 +0300

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 Jul 2015 05:46:22 +0000

On Fri, Jul 24, 2015 at 02:03:13PM -0400, Dave Garrett wrote:

> 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.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 25 Jul 2015 06:54:36 +0000

> What we've cannot yet turn off is RC4.

Then do not use TLS 1.3

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Jul 2015 14:08:23 +0100

(no hats and al that)

> 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.

---

From: Benjamin Beurdouche <[email-masked]>
Date: Sat, 25 Jul 2015 15:41:24 +0200

> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Jul 2015 16:13:39 +0200

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

---

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Jul 2015 17:02:19 +0200

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 25 Jul 2015 15:48:37 +0000

> 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?

---

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Jul 2015 19:01:42 +0200

> 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 Jul 2015 17:13:28 +0000

> > What we've cannot yet turn off is RC4.

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 Jul 2015 17:18:49 +0000

> 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.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 25 Jul 2015 15:00:54 -0400

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 Jul 2015 19:18:45 +0000

> 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.