Subject: [TLS] DSA should die

From: Hanno Böck <[email-masked]>
Date: Wed, 1 Apr 2015 20:12:21 +0200

Hi,

Mozilla just removed DSA support from Firefox. It seems the use of
(non-ecc) DSA in TLS is pretty much nonexistent. Still the TLS 1.3 draft
contains DSA.

Proposal: DSA should go away and not be part of TLS 1.3.

Reasons to remove DSA:
* DSA with 1024 bit is considered weak and DSA with more than 1024 bit
  is widely unsupported.
* DSA has comparable security to RSA (it using same keysize) which is
  the de-facto-default. Given that everybody uses RSA and nobody uses
  DSA having the latter only adds unneccessary complexity.
* DSA can fail badly with bad random number generators.

Some numbers:
In the 2013 https ecosystem scan there were 17 DSA keys on public IPs,
none of them CA-trusted:
http://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf

I think it's safe to say nobody will care if DSA is removed.

cu,
-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 01 Apr 2015 21:47:25 +0200

Hi Hanno, TLS-WG,

> Proposal: DSA should go away and not be part of TLS 1.3.

I concur, let's get rid of DSA as soon as possible. I don't see a reason
why it should be in the 1.3 spec either.

Aaron

---

From: David Benjamin <[email-masked]>
Date: Wed, 01 Apr 2015 19:53:18 +0000

DSA has also been removed from Chrome, so that's two major browsers.
(Chrome/Android saw it gone in October and Chrome/Windows last month.)
There's been a couple reports of servers using self-signed DSA certs for
some reason, but otherwise nothing. Before that, usage was in the noise.
Seems a safe thing to prune.

David

On Wed, Apr 1, 2015 at 2:12 PM Hanno Böck <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 1 Apr 2015 16:30:57 -0400

> Proposal: DSA should go away and not be part of TLS 1.3.

+1

-- 
Stephen Checkoway

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 1 Apr 2015 13:49:56 -0700

> Proposal: DSA should go away and not be part of TLS 1.3.

I'm strongly opposed, because I'm a user of YoloCA, which uses a 512-bit
DSA certificate as its root:

https://twitter.com/yolocrypto/status/378620239144955904

Just kidding, April Fools ;)

(and yes die DSA die)

-- 
Tony Arcieri

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 00:48:15 +0300

+1

> On Apr 1, 2015, at 9:12 PM, Hanno Böck <[email-masked]> wrote:
> 
> Hi,
>

---

From: Bill Frantz <[email-masked]>
Date: Wed, 1 Apr 2015 14:55:23 -0700

+1

I have always worried about the issues with bad random values 
and DSA. We keep seeing bad random number problems in the wild, 
so replacing DSA with algorithms that don't have its problems 
seems like a good idea. Currently, it appears that the effect on 
the real world will be minor, so now seems like a good time.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

---

From: Tom Ritter <[email-masked]>
Date: Wed, 1 Apr 2015 18:04:19 -0500

+1

My pet oddity was inherited DSA parameters from a certificate chain. (Don't
even know if that's supported in many implementations.)

-tom

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 00:26:46 +0000

> Proposal: DSA should go away and not be part of TLS 1.3.

I'm in.  This also helps to shrink the ClientHello cipherlist zoo.

OpenSSL has (SRP, EXPORT and single-DES excluded):

    DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)   Mac=AEAD
    DHE-DSS-AES256-SHA256     TLSv1.2 Kx=DH Au=DSS Enc=AES(256)      Mac=SHA256
    DHE-DSS-AES256-SHA        SSLv3 Kx=DH   Au=DSS Enc=AES(256)      Mac=SHA1
    DHE-DSS-CAMELLIA256-SHA   SSLv3 Kx=DH   Au=DSS Enc=Camellia(256) Mac=SHA1
    DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)   Mac=AEAD
    DHE-DSS-AES128-SHA256     TLSv1.2 Kx=DH Au=DSS Enc=AES(128)      Mac=SHA256
    DHE-DSS-AES128-SHA        SSLv3 Kx=DH   Au=DSS Enc=AES(128)      Mac=SHA1
    DHE-DSS-CAMELLIA128-SHA   SSLv3 Kx=DH   Au=DSS Enc=Camellia(128) Mac=SHA1
    EDH-DSS-DES-CBC3-SHA      SSLv3 Kx=DH   Au=DSS Enc=3DES(168)     Mac=SHA1
    DHE-DSS-SEED-SHA          SSLv3 Kx=DH   Au=DSS Enc=SEED(128)     Mac=SHA1

Which can all go.  Speaking of house-cleaning, on my deprecation wish list
are also (pardon the OpenSSL nomenclature):

    DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
    DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
    DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
    DH-DSS-SEED-SHA         SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
    ADH-SEED-SHA            SSLv3 Kx=DH       Au=None Enc=SEED(128) Mac=SHA1
    SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
    IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
    RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
    EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
    EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
    DH-RSA-DES-CBC-SHA      SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1
    DH-DSS-DES-CBC-SHA      SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
    ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
    DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1

and exotic key agreement schemes with static DH certificates (some of which
appear above):

    DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(256) Mac=AEAD
    DH-RSA-AES256-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA256
    DH-RSA-AES256-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA1
    DH-RSA-CAMELLIA256-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(256) Mac=SHA1
    DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(128) Mac=AEAD
    DH-RSA-AES128-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA256
    DH-RSA-AES128-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA1
    DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
    DH-RSA-CAMELLIA128-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(128) Mac=SHA1
    DH-RSA-DES-CBC3-SHA     SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
    DH-RSA-DES-CBC-SHA      SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1

    ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
    ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
    ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
    ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
    ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
    ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
    ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
    ECDH-RSA-NULL-SHA       SSLv3 Kx=ECDH/RSA Au=ECDH Enc=None      Mac=SHA1

    ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
    ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
    ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
    ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
    ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
    ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
    ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
    ECDH-ECDSA-NULL-SHA     SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=None      Mac=SHA1

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 01:40:40 +0100

<no-hats-except-the-330+-ciphersuites-is-crap-hat>

Here's a suggestion: why pick 'em off one by one? How about
creating a new registry that only includes stuff we think is
really good for TLS1.3?

Personally, I'd go further and argue that the new registry
only specify the TLS 1.3 MTIs, but that's a different question:-)

I'd even argue that that new registry be defined so it only
has space for two of anything - in other words maybe structure
the new registry like the nice list in the MTI mail thread, [1]
and then say how to map that to the old registry that has all
330+ ciphersuites including the good, the bad and the downright
ugly.

</no-hats-except-the-330+-ciphersuites-is-crap-hat>

S.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg15774.html

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 19:48:36 -0500

> 330+ ciphersuites including the good, the bad and the downright

It would be easier to specify the inputs to the cartesian product.

It would be better to also negotiate (cipher+mode), (hash), (KDF), and
(key agreement+server authentication) separately.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 01:51:00 +0100

> (key agreement+server authentication) separately.

Right. That's what Joe did in the mail to which I pointed.

I'm not saying anything about how that's represented on the wire,
but only about IANA registry structure (and size:-)

S

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 01:01:52 +0000

> only specify the TLS 1.3 MTIs, but that's a different question:-)

The problem is that leaves SRP and the like out in the cold.  So
there would need to be few such lists, but that's fine, a client
doing SRP/PSS/... would only advertise SRP/PSS-capable cipher-suites,
and client with no SRP/PSS/... shared secrets would not advertise
any of them.

So that means a short list per authentication trust-model.

    * A list for PKI TLS.

    * A list for anon TLS (that includes the PKI list, for
      interop, and the client will ignore the server's cert).

    * A list for SRP.

    * A list for PSS.

Each list is short, and any client uses just one list.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 1 Apr 2015 21:15:08 -0400

> creating a new registry that only includes stuff we think is

I don't think a whole new registry is a good idea. The ClientHello has to stay the same for backwards compatibility, and cipher suites will need to be listed for TLS 1.2 compatibility at least. Creating a whole new system is only good if you can completely ignore the old one.

There's plenty of space in the current registry if you want to start over. Just say 0xD000 and up is for TLS2 suites, and all below are TLS1. (at this point it's definitely time for 2.0) Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 would be invalid to negotiate for TLS2 but in there for TLS1. This would cost a few more bytes to list AES-GCM in both TLS1 & TLS2 format in the same list, but resorting to a whole new system would add more bytes anyway, along with another registry to keep track of.

> (key agreement+server authentication) separately.

I'm definitely in favor of reducing the combinatorial explosion in suites and moving hash, KEA, & etc. into a separate negotiation. Instead of an extension, you could just do the same thing again, really. Reserve a sizable block of the 16-bit suite space for hashes and another for KEA and list them all in the same cipher_suites array. TLS1 would ignore them, and TLS2 would just see points between [a,b] are hash, [b+1,c] are KEA, etc. So, new registries in the existing space, just dumped all into the same pile.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Apr 2015 18:18:12 -0700

> <no-hats-except-the-330+-ciphersuites-is-crap-hat>

Here's the exhaustive list that we've already removed.

http://http2.github.io/http2-spec/#BadCipherSuites

Some of those are still in wide use today, but none of these work in 1.3.

Removing DSS helps a little, but it is worth doing.

---

From: Nico Williams <[email-masked]>
Date: Wed, 1 Apr 2015 20:38:49 -0500

> I'm definitely in favor of reducing the combinatorial explosion in suites and moving hash, KEA, & etc. into a separate negotiation. Instead of an extension, you could just do the same thing again,…

Yes, we could patch in a-la-carte ciphersuite negotiation by having
non-functional ciphersuites that wild-card all but the one kind of
thing.  You offer those.  A matching functional ciphersuite gets
selected.  Done.

TLS_*_*_WITH_AES_GCM_*
TLS_*_*_WITH_*_*_SHA384
TLS_ECDHE_*_WITH_*_*_*
...

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Apr 2015 04:17:23 +0200 (CEST)

Dave Garrett wrote:
> I don't think a whole new registry is a good idea. The ClientHello
> has to stay the same for backwards compatibility, and cipher suites
> will need to be listed for TLS 1.2 compatibility at least.
> Creating a whole new system is only good if you can completely
> ignore the old one.
> 
> There's plenty of space in the current registry if you want to
> start over. Just say 0xD000 and up is for TLS2 suites, and all
> below are TLS1. (at this point it's definitely time for 2.0)
> Define TLS2 codepoints for valid combinations for TLS2 and the TLS1
> would be invalid to negotiate for TLS2 but in there for TLS1.

I agree that ClientHello needs to remain backwards-compatible.

But how about using the Cipher Suites registry in a more creative fashion.

For TLSv1.3, we could do the negotiation through he cipher suites list
more like this:

   0x10,0xXX    specifies a key exchange algorithm (XX) 256 codepoints
   0x12,0xYY    specifies an authentication algorithm (YY) 256 codepoints
   0x14,0xZZ    specifies a symmetric encryption scheme (ZZ) 256 codepoints
   0x16,0xQQ    specifies a mac algorithm (QQ) 256 codepoints
   0x18,0xPP    specifies a PRF algorithm (PP) 256 codepoints

(with a little room in between if we ever exceed the 256 codepoints)

-Martin

---

From: Dave Garrett <[email-masked]>
Date: Thu, 2 Apr 2015 01:03:31 -0400

On Wednesday, April 01, 2015 09:15:08 pm Dave Garrett wrote:
> There's plenty of space in the current registry if you want to start
> over. Just say 0xD000 and up is for TLS2 suites, and all below are TLS1.
> (at this point it's definitely time for 2.0) Define TLS2 codepoints for
> valid combinations for TLS2 and the TLS1 would be invalid to negotiate
> for TLS2 but in there for TLS1. This would cost a few more bytes to list
> AES-GCM in both TLS1 & TLS2 format in the same list, but resorting to a
> whole new system would add more bytes anyway, along with another registry
> to keep track of.
[...]
> I'm definitely in favor of reducing the combinatorial explosion in suites
> and moving hash, KEA, & etc. into a separate negotiation. Instead of an
> extension, you could just do the same thing again, really. Reserve a
> sizable block of the 16-bit suite space for hashes and another for KEA
> and list them all in the same cipher_suites array. TLS1 would ignore
> them, and TLS2 would just see points between [a,b] are hash, [b+1,c] are
> KEA, etc. So, new registries in the existing space, just dumped all into
> the same pile.

> (with a little room in between if we ever exceed the 256 codepoints)

Yes, that's basically what I'm proposing. Myself, Nico, and you are all just describing the same sort of scheme differently. Yours is the clearest thus far, as it covers everything we might want here.

The only difference I suggest is picking points all above a threshold that separates new from old so filtering out the old system trivial. That looks to be around 0xD000, or 0xC100 if you want to get closer to the current highest assigned value.

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

Dave

---

From: Watson Ladd <[email-masked]>
Date: Wed, 1 Apr 2015 22:32:52 -0700

> (with a little room in between if we ever exceed the 256 codepoints)

I don't understand why we want a different mechanism for TLS 1.3 and
TLS 1.2 ciphersuite negotiation. Even worse, I don't see how something
like SRP fits cleanly into the scheme above. Yes, SRP is little-used,
but people seem to think it's important.

What's wrong with the existing mechanism, if we remove things we don't want?

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 00:49:14 -0500

On Thursday, April 2, 2015, Watson Ladd <[email-masked]> wrote:

> On Wed, Apr 1, 2015 at 7:17 PM, Martin Rex <[email-masked] <javascript:;>>
> wrote:
> > Dave Garrett wrote:

For one: some combinations that are useful get lost in the shuffle because
there are so many ciphersuites.  It has happened before and it will happen
again.  A la carte combination is a useful compression function for: us,
operators, and the network.  It's a compression function that leaves us
with the essential information that we really need.

There are two separate proposals here: a la carte registration, and a la
carte negotiation on the wire.  The latter is only an on-the-wire
compression function -- perhaps it's too disruptive, though now is the only
time it could happen.  There is no excuse for not doing the former.

Nico
--

---

From: CodesInChaos <[email-masked]>
Date: Thu, 2 Apr 2015 09:39:32 +0200

> thing.  You offer those.  A matching functional ciphersuite gets

I think full a-la-carte is too complex. But I'm for negotiating the
handshake and symmetric crypto separately. They're already very
loosely coupled and most proposals that introduce/obsolete
ciphersuites are only interested in one of the two sides, with the
other being only an afterthought.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Apr 2015 09:05:46 -0700

> Some of those are still in wide use today, but none of these work in 1.3.

It was pointed out to me that this list includes some PSK suites.  I
believe that the intent is to support those in 1.3.

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 11:45:35 -0500

> other being only an afterthought.

That would be a huge improvement over what we have now.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Thu, 2 Apr 2015 12:57:09 -0400

> That would be a huge improvement over what we have now.

That could be a good middle ground. Just split cipher suites into essentially asymmetric & symmetric cipher suites, and put them both in the same array. Server just picks one of each for handshake & connection.

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 2 Apr 2015 20:48:26 +0300

> That would be a huge improvement over what we have now.

I say if one splits symmetric/asymmetric, then the hash should go
to the asymmetric part, since it is used there.

And furthermore, since there are group and cert type negotiation
mechanism already can do unified DH/w certs.

So (with some added in):

TLS13_A_DH_CERT_SHA256
TLS13_A_DH_CERT_SHA384
TLS13_S_AES_128_GCM
TLS13_S_AES_256_GCM
TLS13_S_ARIA_128_GCM
TLS13_S_ARIA_256_GCM
TLS13_S_CAMELLIA_128_GCM
TLS13_S_CAMELLIA_256_GCM
TLS13_S_AES_128_CCM
TLS13_S_AES_256_CCM
TLS13_S_AES_128_CCM8
TLS13_S_AES_256_CCM8
TLS13_S_CHACHA20_POLY1305

(I included a cipher if it had an existing codepoint or
was in wide use and was TLS 1.3 compatible).

I'm on fence about splitting hash out:

TLS13_A_DH_CERT
TLS13_H_SHA256
TLS13_H_SHA384
TLS13_S_*

As it seems to me that symmetric algorithm, key exchange and
hash to use are relatively independent concerns (I know gnutls
has internal mapping table that breaks ciphersuites to internal
component parts).

Regarding ServerHello parts of this, the ServerHello could be
redesigned, except for the version field, which is convinently
the first.

So one could put two or three ciphersuite fields, one for
each type there.

If one wanted to add anonDH and PSK:

TLS13_A_DH_ANON
TLS13_A_DH_PSK
TLS13_A_PSK

Giving 17 ciphers that span cartesian space of 88 cipher-
suites.

-Ilari

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 2 Apr 2015 14:31:38 -0700

I think I would prefer to break things up between what is needed for the
record protection and what is needed for authentication (of the peer).
The argument has been made on other threads on the list that these are two
separate concerns and I think it would be best to treat each one as a
unit.  I think TLS 1.3 will make this separation a bit more formal
especially with the removal of RSA key transport.

The record layer protection aspect would include things directly involved
in generating and using the encryption keys:

      AEAD Cipher (e.g. AES-GCM) +  Key agreement (e.g. DH)  + KDF/PRF
(HKDF-SHA256)

I'm tempted to throw the groups used in the DH agreement (25519, p-256,etc)
because that way you can make sure you are consistent matching your
algorithm strength between key agreement and encryption.   I could also see
negotiating the group separately to contain the combinatorial possibilities
of allocations, although we may want to warn against some combinations
 It might make sense to tie the KDF into Key agreement and perhaps these
are fixed to the TLS version.

Authentication would include what the handshake uses use for authenticating
the peers.   It seems there are a number of parameters here: signature
algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), certification parameters (cert
types and params), handshake hash (maybe this is set by the KDF above).
The parameterization of authentication mechanisms may be a bit more
complex, but I think we have much of the machinery there already, it just
may need to be tweaked a bit.

Joe

On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett <[email-masked]> wrote:

> That could be a good middle ground. Just split cipher suites into
> essentially asymmetric & symmetric cipher suites, and put them both in the
> same array. Server just picks one of each for handshake & connection.
>
>
> Dave
>

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 3 Apr 2015 00:35:59 +0200

> (key agreement+server authentication) separately.

I've been wondering about getting rid of the ciphers as we know it
now and that maybe each of the components should instead have it's
own extension.

Kurt

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Apr 2015 19:33:32 -0400

> Proposal: DSA should go away and not be part of TLS 1.3.
To translate the above, its basically asking that DHE_DSS and DH_DSS be 
removed as key exchange mechanisms.

I've watched the discussion and mostly this is a don't care for me except:

This is a cipher suite issue and nothing else.   E.g. its an 
implementation decision rather than a protocol decision and vendors 
should be free to offer this if they think they have a market.  The rest 
of us should gleefully remove this from the set of cipher suites we 
offer or accept.

I would deprecate the older suites (e.g. anything less than <112 bits of 
strength) on general principles, but I would leave the choice whether or 
not to implement these to those who will charge what they need to charge 
when these are specified in RFPs as necessary.

So for the base question - no.   The section on DHE_DSS and DH_DSS in 
the TLS1.3 document should be unchanged from the TLS1.2 document AFAICT 
so there shouldn't be any additional work leaving it.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Apr 2015 21:12:52 -0400

On 4/2/2015 5:31 PM, Joseph Salowey wrote:
> I think I would prefer to break things up between what is needed for 
> the record protection and what is needed for authentication (of the 
> peer).   The argument has been made on other threads on the list that 
> these are two separate concerns and I think it would be best to treat 
> each one as a unit.  I think TLS 1.3 will make this separation a bit 
> more formal especially with the removal of RSA key transport.
>
> The record layer protection aspect would include things directly 
> involved in generating and using the encryption keys:
>
> I'm tempted to throw the groups used in the DH agreement (25519, 
> p-256,etc) because that way you can make sure you are consistent 
> matching your algorithm strength between key agreement and encryption. 
>   I could also see negotiating the group separately to contain the 
> combinatorial possibilities of allocations, although we may want to 
> warn against some combinations    It might make sense to tie the KDF 
> into Key agreement and perhaps these are fixed to the TLS version.
>
> Authentication would include what the handshake uses use for 
> authenticating the peers.   It seems there are a number of parameters 
> here: signature algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), 
> certification parameters (cert types and params), handshake hash 
> (maybe this is set by the KDF above).   The parameterization of 
> authentication mechanisms may be a bit more complex, but I think we 
> have much of the machinery there already, it just may need to be 
> tweaked a bit.
>
> Joe
>
>
>

The parameter negotiation phase needs to negotiate the hash function 
used for the handshake summary.

The key agreement phase needs to negotiate the KDF function, the 
pre-master secret, the master secret, and the session keys.  Right now 
the KDF function is a fixed construct which uses the hash function from 
the parameter negotiation as its underlying function - but that could be 
changed.  [Lost track of this, but in TLS1.3 I believe the handshake 
summary is now a mixin to the derivation of either the master secret or 
the session keys?]

Then you have the record level cipher suite and the authentication 
mechanisms.

So maybe its more like 6-8 boxes you need to split cipher suites up into:

{ [cipher strengths], [handshake summary families], [kdf modes], [key 
agreement mechs], [auth mechs], [record mechs]}

e.g.

{ [128], [SHA2 | SHA3], [HKDF | SP800-108], [ECDHE | ECDH | GOSTXX], 
[CERT-ECDSA | CERT-RSA-ECDSA | CERT-RSA], [AES-CCM |AES-CCM]}

Pick a security level in bits, map each of the individual mode choices 
to a specific security level etc.

The above isn't quite right (first attempt) - you might need to add 
families for the key agreement mechanisms (specifically ECDH) to add 
curve selection and you might split off the encryption type from the 
encryption mode  ([AES] [CCM | GCM])

Mike

>
>
>
> On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     essentially asymmetric & symmetric cipher suites, and put them
>     both in the same array. Server just picks one of each for
>     handshake & connection.
>
>
>     Dave
>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Smith <[email-masked]>
Date: Fri, 3 Apr 2015 14:05:03 -1000

Please don't change the syntax for negotiating cipher suites. Although
it seems like a good idea to try to make things simpler conceptually
by negotiating the different components of the cipher suite
differently, it would take a lot of effort to standardize a new way of
doing things. I don't think the current mechanism is problematic
enough (at all, really) to justify that effort. Also, any new
mechanism is going to make any implementation more complicated--and
thus more more-prone--if it also has to support older versions of TLS.
Again, I don't think that extra complication is warranted.

Finally, there are a lot of reasons to avoid wasting bytes in the
ClientHello message, for improved compatibility. Having two cipher
suite negotiation mechanisms in the ClientHello, one for TLS 1.3+ and
one for earlier versions, would likely be counter to that goal.

Cheers,
Brian

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 3 Apr 2015 17:18:34 -0700

On Fri, Apr 3, 2015 at 5:05 PM, Brian Smith <[email-masked]> wrote:

> it seems like a good idea

Personally I think it's a great idea, and a pretty simple one and also an
incredibly needed one. In fact, this post and its ensuing discussion
actually made me excited about TLS 1.3:

https://mailarchive.ietf.org/arch/msg/tls/JZoIXZMRg80-tDC23kt5BL0nQaQ

If you read through the suggestions, I think a new syntax could actually be
backwards compatible in terms of computing the possibility matrix /
combinatorial explosion of all authentication and (symmetric) encryption
ciphers/ciphersuites.

I think this sort of approach sorts out a lot of collusion and confusion
(not in the Claude Shannon sense) which has been lingering in TLS for years.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 17:40:02 -0700

On 3 April 2015 at 17:05, Brian Smith <[email-masked]> wrote:
> I don't think the current mechanism is problematic
> enough (at all, really) to justify that effort.

I think that I've the same view.

Then you have to consider interaction problems where some
implementations have hardware for certain things, and software for
others.  Not only does that produce strong preferences for some things
over others, it also can lead to holes in support tables, making a la
carte selection tricky.

That was always the clincher for me.

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Apr 2015 21:21:07 -0400

> That was always the clincher for me.

After the initial discussion, the middle point between the current system and my initial "just dump it all in a pile" idea (which Nico more elegantly named a la carte), is just to split cipher suites into symmetric and asymmetric suites. The one for the handshake and one for the connection would be negotiated separately. This could work rather well without too much change.

That said, how much combinatorial explosion are we even dealing with anymore? We ditched all non-ephemeral handshakes. There's fewer variations now, at least at the moment.

A non-hypothetical example:
https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-02#section-3

OCB wants to define in its current draft:

     CipherSuite TLS_DHE_RSA_WITH_AES_128_OCB = {TBD1, TBD1}
     CipherSuite TLS_DHE_RSA_WITH_AES_256_OCB = {TBD2, TBD2}
     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_OCB = {TBD3, TBD3}
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_OCB = {TBD4, TBD4}
     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_OCB = {TBD5, TBD5}
     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_OCB = {TBD6, TBD6}
     CipherSuite TLS_PSK_WITH_AES_128_OCB = {TBD7, TBD7}
     CipherSuite TLS_PSK_WITH_AES_256_OCB = {TBD8, TBD8}
     CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
     CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
     CipherSuite TLS_ECDHE_PSK_WITH_AES_128_OCB = {TBD11, TBD11}
     CipherSuite TLS_ECDHE_PSK_WITH_AES_256_OCB = {TBD12, TBD12}

If we just split handshake from connection, it would just be:

defined in TLS 1.3/2.0 spec:

     CipherSuite TLS2_DHE_RSA = TBD
     CipherSuite TLS2_ECDHE_RSA = TBD
     CipherSuite TLS2_ECDHE_ECDSA = TBD
     CipherSuite TLS2_PSK = TBD
     CipherSuite TLS2_DHE_PSK = TBD
     CipherSuite TLS2_ECDHE_PSK = TBD

(by the way, do we really want plain PSK?)

and OCB would only need to define:

     CipherSuite TLS2_AES_128_OCB = TBD
     CipherSuite TLS2_AES_256_OCB = TBD

That's already fewer suites. All new ciphers would only need to define one or two suites, as the 6 handshakes would be common to all. It'd be a hell of a lot easier to configure and negotiate into the future. We already add weird SCSV fake suites, so adding a few newly handled ones shouldn't break the world.

Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route.

There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is.

Dave

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 04 Apr 2015 06:52:50 +0200

Hi,

> (by the way, do we really want plain PSK?)

Added the PSK ciphersuites after lengthy discussion with nikos and peter
gutmann, they assure me it's of importance to the embedded world.

> There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshak…

I actually really like the idea. But there're a couple of open questions
to that; What happens to existing ciphersuites? And given we switch to a
model of asymmetric and symmetric ciphersuites: (how) do we document all
the implicit ciphersuites that are defined once a new symmetric or
asymmetric algorithm is defined?

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Sat, 4 Apr 2015 11:41:38 -0400

> gutmann, they assure me it's of importance to the embedded world.

I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-ephemeral cipher suites were not permitted any longer. I thought usage of plain PSK would be against TLS 1.3 & HTTP/2 consensus. If it really is needed, I think they should be prohibited in general TLS and only allowed via the IoT application profile.

> to that; What happens to existing ciphersuites?

There's hardly any left that are still permitted. Each cipher that would be usable in TLS 1.3+ would need to define its own set of new cipher suites. The TLS 1.3 spec could have a short section to just assign the IDs for the existing ones. Clients would propose both the old suites and the new suites in the same array. Old servers would ignore the new, and new servers would ignore the old. (again, set all new above some point so checking is just a greater/lesser than comparison) It would be an extra few bytes, but again, any system to improve this via an extension would also add an extra few bytes.

> And given we switch to a

The two are separate enough that all combinations should be valid and all implementations should be capable of handling all combinations.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 4 Apr 2015 15:52:18 +0000

> What happens to existing ciphersuites?

Those that are strong enough to survive into TLS 1.3 are subsumed
by the new ala-carte choices.

> asymmetric algorithm is defined?

There's no need to document the "cross-product", just document the
inputs.  Making it a cross-product fills in gaps, for example,
there are at present no AECDH (key agreement) plus AEAD (symmetric
bulk crypto) ciphersuites.

Note that digests play a role in both the handshake and in the bulk
crypto MAC.  

For the handshake, there's the digest used in certificates (which
seems odd to negotiate as it is I think rare for either end to have
multiple variands of a given certificate chain with different
digests).  There's also the digest used for key derivation.

If the leading proposal is to go with 2 axes for the cross-product,
then I would fix the key-agreement PRF in each handshake type, and
use the supported digests extension as a "hint" to the peer to aid
in certificate selection.  I say "hint", because the peer will do
its best to send a suitable chain, when it has more than one, but
typically such "hints" are not particularly effective, and the peer
may as well use whatever it has.

For example, with DANE-EE(3) the signature of the peer certificate
is never checked and is irrelevant.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 4 Apr 2015 23:55:07 +0000

> Please don't change the syntax for negotiating cipher suites.

+1, for the reasons Brian said.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 6 Apr 2015 20:25:02 -0700

> +1, for the reasons Brian said.

Looks like the opinion of TLS implementers is this far unanimously against
this proposal. I would like to give the counterpoint from a TLS user
perspective.

I am more or less in charge of the ciphersuite selection for a large web
site with a lot of users. I find the present means of describing
ciphersuites to TLS stacks to be difficult at best. As myself and many
others have described, we're essentially being asked to compute the
combinatorial explosion of different ciphersuite configurations by hand.
Guess what happens when you do that? People make mistakes. I think the TLS
libraries should have an easier-to-use configuration format that computes
things for me so I don't have to. I understand why TLS implementers are
reluctant to provide that. It's more work for them. But so far none of them
have said why this is qualitatively bad.

The proposed approach of splitting up what is more or less key exchange vs
symmetric cipher configuration (please excuse that rough description, I
know how deep the rabbit hole under this bikeshed goes) and require you
specify both parts in order of preference sounds like it should fit within
all of the existing TLS configuration frameworks and notations. People
would only use the new syntax with TLS 1.3+ compatible libraries, and it
should be fully backwards compatible with the old one.

I also think that requiring this sort of configuration could help designers
TLS tease out these concepts internally so they aren't colluded into an
amorphous mush of algorithms, every possible combination of which a TLS
deployer is expected to whitelist.

Seems like a huge win to me. So what's the problem from an implementer
perspective besides "it'd be hard"?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Apr 2015 08:51:22 +0300

> On Apr 7, 2015, at 6:25 AM, Tony Arcieri <[email-masked]> wrote:
> 
> On Sat, Apr 4, 2015 at 4:55 PM, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
> Looks like the opinion of TLS implementers is this far unanimously against this proposal. I would like to give the counterpoint from a TLS user perspective.

I’m a TLS implementer and I kind of like a-la-carte, but wouldn’t mind either way. Might have something to do with me having been an IKE implementer before I was a TLS implementer.

> I am more or less in charge of the ciphersuite selection for a large web site with a lot of users. I find the present means of describing ciphersuites to TLS stacks to be difficult at best. As myself and many others have described, we're essentially being asked to compute the combinatorial explosion of different ciphersuite configurations by hand. Guess what happens when you do that? People make mistakes. I think the TLS libraries should have an easier-to-use configuration format that computes things for me so I don't have to. I understand why TLS implementers are reluctant to provide that. It's more work for them. But so far none of them have said why this is qualitatively bad.

This is about UI, not about wire format. I totally agree that the OpenSSL string format for specifying ciphersuites is a horrid mess, but nothing is stopping an implementer from creating an a-la-carte UI and translating the user preferences to a combinatorial explosion on the wire.

> The proposed approach of splitting up what is more or less key exchange vs symmetric cipher configuration (please excuse that rough description, I know how deep the rabbit hole under this bikeshed goes) and require you specify both parts in order of preference sounds like it should fit within all of the existing TLS configuration frameworks and notations. People would only use the new syntax with TLS 1.3+ compatible libraries, and it should be fully backwards compatible with the old one.

So sure, UIs range in sophistication from a set of radio buttons labeled “secure”, “not so secure”, and “not secure” to a list of ciphersuites, each with a check box next to it, and those kind of UI choices can be expressed in string configuration as well. 

> I also think that requiring this sort of configuration could help designers TLS tease out these concepts internally so they aren't colluded into an amorphous mush of algorithms, every possible combination of which a TLS deployer is expected to whitelist.

I think implementers understand what goes on behind the long list of ciphersuites.

> Seems like a huge win to me. So what's the problem from an implementer perspective besides "it'd be hard”?

There’s always that fear that some combination of algorithms will turn out to be not secure, while other combinations of each of those algorithms will be fine.

Yoav

---

From: Brian Smith <[email-masked]>
Date: Mon, 6 Apr 2015 20:09:07 -1000

> combinatorial explosion of different ciphersuite configurations by hand.

As far as I understand, that problem doesn't have much to do with the
syntax of cipher suites in the ClientHello, because that problem is
about describing to your web server software which cipher suites to
enable on the server.
> have said why this is qualitatively bad.

That can be done already today, without any protocol changes, and
without any TLS library changes (at least as far as OpenSSL is
concerned). Somebody just needs to write the code to do it.

> perspective besides "it'd be hard"?

The client doesn't always (ever?) want to enable the entire set of
(key exchange algorithm * authentication algorithm * encryption
algorithm * integrity algorithm) combinations, so a syntax that only
allows the client to describe cipher suites by the individual
components is too limiting.

More generally, an "a la cart" syntax automates the enabling of lots
of cipher suites. But, how is enabling lots of cipher suites a good
thing? it seems like a bad idea, in general, to me.

If we had a need to have clients enable a whole lot more cipher
suites, such that the size of the ClientHello would become really
large with the current syntax, then that would be a reason to consider
a new syntax. But, it seems that when we consider that the old syntax
has to be supported for backward compatibility with TLS 1.2 and below,
it seems like the set of new cipher suites to enable would have to be
quite large before we would enjoy any positive space savings from
doing that. Thus, the idea seems counterproductive even considering
the area where it would be most likely to help.

Finally, there is a lot of value to getting TLS 1.3 done in a
reasonable time frame. Cutting unnecessary or counterproductive
changes accelerates the schedule while giving us more time to solve
more important problems.

Cheers,
Brian

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 6 Apr 2015 23:18:12 -0700

On Mon, Apr 6, 2015 at 10:51 PM, Yoav Nir <[email-masked]> wrote:

> This is about UI, not about wire format.
>

> about describing to your web server software which cipher suites to

I think some are trying to argue that the problem is deeper than just the
user interface, but you're both correct in saying that's where the problem
starts.

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 7 Apr 2015 09:31:33 +0300

> user interface, but you're both correct in saying that's where the problem

Also, the certificate format negotiation is supposedly both via
ciphersuites and an extension. And when you have the same thing in
two places, the relevant question is "which is definitive?".

Also, consider if new signature algorithm needs to be added (e.g.
CFRG picks something EdDSA-like for new signature algorithm).

Also, it is not like existing TLS stacks don't have tables mapping
ciphersuites into their component algorithms, since otherwise
there would be plenty of code duplication.

As for "components are fine but combination is insecure", that would
likely require very odd algorithms, and would likely point to TLS
key derivation being bad anyway.

-Ilari

---

From: Brian Sniffen <[email-masked]>
Date: Tue, 07 Apr 2015 19:25:34 -0400

> As myself and many others have described, we're essentially being
> asked to compute the combinatorial explosion of different ciphersuite
> configurations by hand.  Guess what happens when you do that? People
> make mistakes.

Lots of them, and terrible mistakes.  For example, the OpenSSL
configuration language encourages selections like:

HIGH
TLSv1:SSLv3:-EDH:-ADH:-NULL:@STRENGTH
TLSv1:SSLv3:HIGH:-SSLv2:-MEDIUM:-LOW

all of which admit terrible choices.  I think this is because those look
like short, easily comprehensible commands---but aren't.

> perspective besides "it'd be hard"?

But that's not the wire format.  That's the best attempt of implementors
to provide a better configuration format than just listing everything
you want.  After a lot of trying for better, I am persuaded that the
right answer is to explicitly list exactly what you want, or to
reference first-order named sets of what you want---that set algebra on
cipher selections is more dangerous.  The best advice we can give now
could be expressed to OpenSSL as 'EECDH+AESGCM', but it's not much more
work to say
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256,
and at least that looks like something you should read carefully and
make sure you didn't swap a : and a -.

-Brian

-- 
Brian Sniffen

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Apr 2015 02:54:39 +0000

> this proposal. I would like to give the counterpoint from a TLS user

I see no unanimity.  I think that long-term the cross product
simplifies maintenance (simpler internal tables with less duplication),
and makes it easier to sensibly sort the cipher-suites by independent
preferences for each feature.

Yes, there'll need to be new APIs for specifying separate preferences
for the key agreement suites vs. bulk crypto suites.  Some may find
this an opportunity to drop legacy interfaces.

In OpenSSL many of the building blocks are already there, thus
we can build up a cipher-suite from its parts:

    $ openssl ciphers -v kECDHE+aECDSA+AES128+AESGCM
    ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD

All that's missing is separate ordered cipherstring settings for
the components.  These would be UI improvements I think.  Yes, not
easy retrofits into existing applications, but ultimately worth it
IMHO.  Assuming of course TLS is still the swiss-army knife of
security protocols and needs to support a range of choices for each
element of the cipher-suite.

Were any radical simplification to just 1 or 2 (composite) ciphersuites
actually realistic, then breaking those down would be silly.  As
it stands I don't see a likely choice of just 2 ciphersuites that
serve all TLS users, and thus ala carte makes sense to me.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Apr 2015 03:00:54 +0000

> TLSv1:SSLv3:HIGH:-SSLv2:-MEDIUM:-LOW

The problem is that this attempts to mix choices along multiple
axes into a single list.  Very few people understand this oranges
and apples interface.

If each setting just expressed preferences along a single axis,
the interface would be much simpler.

This is why the wire format should avoid combining independent
choices, that way the user's preferences for any given apples to
apples comparison can be expressed without change on the wire.

Otherwise one has to make trade-offs that try to decide whether
ECDHE with AES128 is better than DHE with AES256?  And similar
imponderables.

So I would go further and urge a full decomposition, not just
handshake vs. bulk crypto.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Apr 2015 02:01:52 -0400

> two places, the relevant question is "which is definitive?".

Here's a different idea for fixing the combinatorial mess: For TLS 1.3+, only use cipher suites to negotiate symmetric ciphers. Rely entirely on the extensions for the handshake.

For the handshake, mandate usage of the "supported_groups" extension (née "elliptic_curves") and the “signature_algorithms” extension for all connection attempts. (reject connection if not present and valid) If TLS 1.3+ is negotiated, then the DHE/ECDHE will be selected based on the highest preferred supported NamedGroup and RSA/ECDSA/etc will be selected based on the highest preferred SignatureAndHashAlgorithm. Assign points to NamedGroup and SignatureAlgorithm to negotiate PSK usage via the extensions. (e.g. NamedGroup=0 for plain PSK) The server would then ignore everything in proposed cipher suites other than the symmetric cipher suite components. (e.g. all of the following would be considered equivalent for TLS 1.3+: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) New ciphers that are supported via TLS 1.3+ would only need to define something in the form of TLS_EXT_WITH_x_y_z with variations of symmetric parameters (for OCB, there'd be only 2 suites). New ciphers that wish to support TLS 1.2 but without adding the litany of combinations of suites could simply allow negotiation of any of the new suites to assume DHE_RSA unless the necessary extensions are used to say otherwise. (though, just requiring the extensions to use them is not unreasonable)

This route does not change cipher suites in a major way and uses already in-draft extensions to do the negotiation, without any modifications beyond mandating their use and absolute priority over the parameters specified in the cipher suite. Not only does this make the cipher suite selection simpler and avoids endpoints not negotiating a viable combination that's just not offered in the list, but it removes any existing ambiguity over which support listing is definitive. Cipher suites negotiate symmetric and these two extension negotiate asymmetric.

Dave

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 03:14:45 -0400

On Mon 2015-04-13 02:01:52 -0400, Dave Garrett wrote:
> Here's a different idea for fixing the combinatorial mess: For TLS
> 1.3+, only use cipher suites to negotiate symmetric ciphers. Rely
> entirely on the extensions for the handshake.

This is the cleanest and most backward-compatible suggestion i've heard
yet for a la carte algorithm selection in TLS.  If we decide to do a la
carte algorithm selection, this seems like a variant i could be
comfortable with.

> For the handshake, mandate usage of the "supported_groups" extension
> (née "elliptic_curves") and the “signature_algorithms” extension for
> all connection attempts. (reject connection if not present and valid)
> If TLS 1.3+ is negotiated, then the DHE/ECDHE will be selected based
> on the highest preferred supported NamedGroup and RSA/ECDSA/etc will
> be selected based on the highest preferred
> SignatureAndHashAlgorithm. Assign points to NamedGroup and
> SignatureAlgorithm to negotiate PSK usage via the
> extensions. (e.g. NamedGroup=0 for plain PSK)

I'm not convinced that we want to use 0 for PSK (this may be purely
aesthetic: it makes PSK sound like the "default", and if we later find
other non-DH key exchange we want to stuff in this registry, it'd be
nice to group them together, and there are no available neighbors close
to 0).  I think i'd be ok using some other currently-unallocated
codepoint, though.

> The server would then ignore everything in proposed cipher suites
> other than the symmetric cipher suite components. (e.g. all of the
> following would be considered equivalent for TLS 1.3+:
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) New ciphers that are
> supported via TLS 1.3+ would only need to define something in the form
> of TLS_EXT_WITH_x_y_z with variations of symmetric parameters (for
> OCB, there'd be only 2 suites). New ciphers that wish to support TLS
> 1.2 but without adding the litany of combinations of suites could
> simply allow negotiation of any of the new suites to assume DHE_RSA
> unless the necessary extensions are used to say otherwise. (though,
> just requiring the extensions to use them is not unreasonable)

We could also say that TLS 1.2 implementations that know about a new
symmetric cipher must be able to negotiate key exchange choice
independently via the supported_group ("supported_key_exchange"?)
mechanism when that cipher is selected.

        --dkg

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 13 Apr 2015 14:58:58 +0200

Hi Dave et al.,

Sorry for the late reply.

> I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-ephemeral cipher suites were not permitted any longer. I thought usage of plain PSK would be against TLS 1.3 & HTTP/2 consensus.…

As the draft currently is written it also applies to TLS 1.2. I have no
problem with removing non-ephemeral ciphersuites from the document,
given that there's agreement among embedded implementers.

So far no further comments on the ensuing discussion, your ideas are all
very interesting and -- I think -- are well worth exploring.

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Apr 2015 12:00:00 -0400

On Monday, April 13, 2015 03:14:45 am Daniel Kahn Gillmor wrote:
> > Assign points to NamedGroup and

The thought process was 0 for N/A in the case of PSK without (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which would make this a non-issue.

Dave

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 12:49:45 -0400

On Mon 2015-04-13 12:00:00 -0400, Dave Garrett wrote:
> The thought process was 0 for N/A in the case of PSK without
> (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which
> would make this a non-issue.

Hm, let's look at the representations of ((EC)DHE_)PSK in the scheme you
propose.  You've split the suite using these terms and mechanisms:

 "symmetric" (indicated by ciphersuite list)

 "handshake" (indicated by known_groups extension)

 "signature" (indicated by signature_algorithms extension)

I'd recommend using slightly different terminology, since at least
"handshake" is already overloaded to mean something broader in TLS.

  "symmetric" (ciphersuite list)

  "key agreement" (known_groups extension)

  "authentication" (signature_algorithms extension)

In this model, ECDHE_PSK would have:

   key agreement: ECDHE
  authentication: PSK

while non-(EC)DHE PSK would have:

   key agreement: PSK
  authentication: PSK

right?

we'd only need a key agreement codepoint for PSK in the case we have
non-(EC)DHE, but i have heard some constrained-devices people arguing
for that in the WG, so that seems like a likely outcome.

So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer
were to try to negotiate:

  key agreement: PSK
 authentication: RSA-PSS

Do we just say "don't do that"?  clients using existing RSA_PSK
ciphersuites [0] use the server's RSA key to encrypt the, uh,
pre-premaster secret, which is then mixed with the PSK to complete the
key exchange.  This is *not* an RSA signature, and we're getting rid of
the encrypted premaster secret approach in TLS 1.3 entirely.  So the
above seems like a novel (and possibly useless) combination.

As for placing the known_groups codepoint at 0: it's conceivable that in
the future someone wants to resurrect SRP or add some other PAKE or any
other non-DH key agreement scheme (with or without forward secrecy and
with or without authentication), in which case it would be aesthetically
nice to have a block of "neighbors" with similar properties -- using 0
doesn't let us do that grouping.

      --dkg

[0] https://tools.ietf.org/html/rfc4279#section-4

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Apr 2015 13:25:20 -0400

>   "authentication" (signature_algorithms extension)

Yes, this could avoid some miscommunication. The "handshake" includes both key agreement and authentication, so it would be better to be explicit.

In fact, if we're already renaming the extension, elliptic_curves/supported_groups could be better named as key_agreement_algorithms to better align with the signature_algorithms naming and explain its purpose better.

> while non-(EC)DHE PSK would have:

Yes.

> for that in the WG, so that seems like a likely outcome.

Yes.

Not sure if allowing non-FS is a given, though. If they're really constrained, I think a much better alternative would be to define some (EC)DHE optimized for performance but only providing a minimum reasonable level of forward secrecy, even if not ideal.

> Do we just say "don't do that"?

SGTM

> doesn't let us do that grouping.

The codepoint is of course rather arbitrary, so picking some other value for future-proofing is fine. It's a 16-bit space so there's plenty of room.

Dave

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 13:31:12 -0400

>> Do we just say "don't do that"?

This, i think, is one of the serious concerns about splitting the
ciphersuite into orthogonal vectors.

Once the full cartesian explosion is available by multidimensional
enumeration, we have to mark out which corners of the space are actually
bad ideas, and we have to make sure our implementations don't stumble
into those corners by accident.

This isn't impossible to do, but it seems ripe for subtle implementation
bugs.

     --dkg

---

From: Andrei Popov <[email-masked]>
Date: Mon, 13 Apr 2015 17:32:31 +0000

The idea of fixing the combinatorial mess is appealing to me, for a variety of reasons. However, negotiating the key exchange algorithm using "elliptic_curves" (or even "supported_groups") seems awkward. E.g. if someone wants to add a key exchange that is different than DHE/ECDHE, then using "supported_groups" to negotiate it will make little sense. This is already problematic today for PSK.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Sunday, April 12, 2015 11:02 PM
To: [email-masked]
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

Dave

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 13 Apr 2015 17:35:42 +0000

On 4/13/15, 13:31 , "Daniel Kahn Gillmor" <[email-masked]> wrote:

>……...

Cryptographically sound algorithms and protocols should be immune to this
concern. And we should accept only cryptographically sound algorithms &
protocols. :-)

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Apr 2015 17:41:37 +0000

> into those corners by accident.

Is this actually a problem?  Is it worse than the current multitude
of suites (with some gaps yet to be filled)?

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 13 Apr 2015 13:45:51 -0400

> into those corners by accident.

Non-FS PSK adds some of those corners, which is one of the reasons why I think it should be prohibited.

> This isn't impossible to do, but it seems ripe for subtle implementation

The current situation is already ripe for subtle implementation bugs. These extensions already exist and can conflict with the cipher suite if not configured/used properly. I think this route reduces the risk here, and prohibiting/restricting the more problematic methods/algorithms would help more.

Dave

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 14:29:49 -0400

> concern. And we should accept only cryptographically sound algorithms &

What do you think an implementation should do when a peer tries to
negotiate the combination above?  Require an RSA-PSS signature from the
server over some material derived in part from the PSK key agreement
mechanism?

          --dkg

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Apr 2015 21:55:05 +0300

> server over some material derived in part from the PSK key agreement

To me it seems like that combo is quite insecure, unless one handles it as
a special case (in which case it is just equivalent to PSK in security,
just wastes time with a certificate).

As list, the key exchange methods TLS v1.2 actually supports (after merging
some non-significant distinctions) are:
- RSA [going away]
- RSA_EXPORT [you have deimplemented this already, right?]
- DH_CERT [going away]
- DHE_CERT [supported]
- DHE_ANON [???]
- KRB5 [going away]
- PSK [???]
- DHE_PSK [???]
- RSA_PSK [going away]
- SRP [???]
- SRP_CERT [???]

-Ilari

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 13 Apr 2015 21:57:04 +0300

Hello Ilari,

You missed GOST key exchange.

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 16:45:25 -0400

> just wastes time with a certificate).

Can you explain why it's "quite insecure"?

It doesn't seem any worse than normal (non-DHE) PSK other than the cost
of signing and verifying.  I suppose that it also proves that an
attacker has access to both the PSK and the secret key material
belonging to the cert.

So, for example, you could give a dozen clients the same PSK (maybe to
provide them with indistinguishability from each other to a network
observer?), but clients that want to be sure they're talking to the
server (instead of each other) can rely on the server's cert.

> - RSA_EXPORT [you have deimplemented this already, right?]

I think this list mixes up key exchange with authentication, which was
what Dave was trying to tease apart.  For key exchange, there is no
difference between DHE_CERT and DHE_ANON and DHE_PSK -- they're all DHE.
the ANON/CERT/PSK parts would be negotiated separately in the
authentication side of things (via the signature_algorithms extension).

(And if we're using supported_groups, the distinctions between different
 flavors of DHE (FFDHE2048, ECDHEP256, ECDHEX25519, etc) are hardly
 non-significant, but i guess that's a slightly different discussion.)

        --dkg

---

From: Geoffrey Keating <[email-masked]>
Date: 13 Apr 2015 14:09:05 -0700

> That was always the clincher for me.

I agree.  In particular I don't think we've simplified anything if
implementations have to have a list of invalid combinations, or have
to know that certain ciphers are to be used only with matching key
exchange algorithms (for example, use the GOST key exchange with the
GOST symmetric cipher).

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Apr 2015 00:57:36 +0300

> On Apr 14, 2015, at 12:09 AM, Geoffrey Keating <[email-masked]> wrote:
> 

Why?  There’s nothing invalid about using Curve25519 key exchange with an RSA certificate and GOST symmetric ciphers, so TLS should not provide this. Requiring all three things to be GOST is a policy decision that can and should be part of server (and perhaps client) configuration.

If some standard in Russia demands that GOST algorithms be used for all three, that should be configurable on the server. If OTOH the Russian authorities decide that they are fine with ECDHE for key exchange, but demand the GOST symmetric ciphers and authentication, that is also easy to get working with a la carte, but now it’s impossible until someone specifies such ciphersuites in a new document.

Unless some combination creates an insecurity when each of its components is secure when combined with other components, I don’t think we have an issue. 

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Apr 2015 22:18:54 +0000

On Tue, Apr 14, 2015 at 12:57:36AM +0300, Yoav Nir wrote:

> Unless some combination creates an insecurity when each of its
> components is secure when combined with other components, I don't
> think we have an issue.

Yep, that's my view also.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 13 Apr 2015 22:22:14 +0000

Yes. My expectation here is that "good" constructs are composable. "Composable with caveats" are not good, and shouldn't be included in a-la carte selection. 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Yoav Nir [mailto:[email-masked]]
Sent: Monday, April 13, 2015 05:57 PM
To: Geoffrey Keating <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Yoav

---

From: Geoffrey Keating <[email-masked]>
Date: 13 Apr 2015 16:15:39 -0700

> > In particular I don't think we've simplified anything if
> Why?  There’s nothing invalid about using Curve25519 key exchange
> with an RSA certificate and GOST symmetric ciphers, so TLS should
> not provide this. Requiring all three things to be GOST is a policy
> decision that can and should be part of server (and perhaps client)
> configuration.

It seems like that would be an interoperability issue if the server
and client disagree on the policy to apply.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Apr 2015 00:36:58 +0000

On Mon, Apr 13, 2015 at 04:15:39PM -0700, Geoffrey Keating wrote:

> > Why?  There?s nothing invalid about using Curve25519 key exchange

If a client or server is willing to do non-GOST algorithms along
some axis of the cipher-suite parameter space, it should be willing
to accept mixed results.  It is no less GOST-compliant when using
a mixed suite than when using a suite that has no GOST features.

But your point is valid, and can be taken to imply that policies
which disallow valid combinations of parameters are to be avoided,
if a server selects a combination from the choices offered by the
client, the client SHOULD or MUST accept that combination, or else
why were the choices in question offered by the client?

So a key question is whether policies that rule out various corners
of the product space are legitimately required???

-- 
	Viktor.

---

From: Brian Smith <[email-masked]>
Date: Mon, 13 Apr 2015 14:46:06 -1000

> of the product space are legitimately required???

One example: Firefox intentionally enabled
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 without enable the the TLS_RSA_*
or TLS_DHE_* variants, partly to encourage people to move away from
TLS_DHE and especially TLS_RSA key exchange, and partly because of
security concerns regarding TLS_DHE and TLS_RSA key exchange. It
wasn't able to disable all TLS_DHE_* and TLS_RSA_* cipher suites for
compatibility reasons.

TLS_RSA_* cipher suites won't be allowed in TLS 1.3 and later, but I
think the need to be able to support only a subset of the cross
product of all options will remain going forward as attacks against
current (TLS 1.3 approved) algorithms improve and as replacements for
current algorithms are developed.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Mon, 13 Apr 2015 14:50:02 -1000

Brian Smith <[email-masked]> wrote:
> security concerns regarding TLS_DHE and TLS_RSA key exchange.

Also, some servers received an update that enabled only the TLS_DHE_*
and TLS_RSA_* variants of those AES-GCM cipher suites, but that update
was broken so that handshakes that used those cipher suites would
fail. So, being able to have TLS_DHE_* and TLS_RSA_* variants of the
AES-GCM cipher suites disabled while the TLS_ECDHE_* cipher suites
stayed enabled has had interoperability benefits. (There is a patch
available that fixes the bug in those servers, but even months later
not all the servers have applied the patch.)

Cheers,
Brian

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 13 Apr 2015 23:02:13 -0400

> of the product space are legitimately required???

Here's one (granted, contrived) policy:

 * i'm willing to talk to US Government peers (they all want Suite B)
   and Russian Government peers (they all want GOST).  so my policy is
   that I want either an all-GOST collection or an all-suite-B
   collection.  a la carte would suggest that i'd be OK with GOST key
   agreement combined with suite B symmetric crypto, though i would not
   consider that OK.

     --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Apr 2015 03:06:23 +0000

> Here's one (granted, contrived) policy:

Or, say, you're hosting those kinds of organizations.

Not contrived at all.

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Apr 2015 04:01:06 +0000

> Or, say, you're hosting those kinds of organizations.

It suffices for clients to not offer building blocks they don't
implement.  If servers choose to "bundle" certain algorithms, that's
fine, so long as clients don't object to what they get.

Picky clients can offer a smaller cross-product.  Suite-B restrictions
IIRC are triggered in part by certificate content, which in turn
is selected via SNI.

I am sure we can find corner cases where legacy TLS implementations
warts and all needed various exclusions.  If TLS 1.3 clients can
only express cross-product suites, servers may be able to pick up
the slack as appropriate.

We need to be sure that the objections are really future requirements
for 1.3, rather than work-arounds for legacy 1.2 and older stacks
whose defects are not expected to be carried forward into 1.3.

That said, finally we're finding plausible cases in which ala carte
is less flexible.  Are these sufficiently compelling?

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 14 Apr 2015 00:17:57 -0400

>    agreement combined with suite B symmetric crypto, though i would not

This scenario would be better served by a new extension that requests enforcement of specific sets of capabilities. The new proposals would make more unusual combinations negotiable, yes, but we are already in a situation where stuff from one can get negotiated in another. (e.g. authentication)

So long as things are properly configured and prioritized, this shouldn't be an issue. (e.g. prioritize all of set A before all of set B at both endpoints, and ensure both sets are complete)

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Apr 2015 08:49:03 +0300

> attacker has access to both the PSK and the secret key material

If it is really PSK with RSA-PSS, then it is semi-OK (but see below).

The problem here is:
- If PSK is considered authentication algorithm, then pure PSK has NULL
  key agreement. Which is quite dangerous with any authentication that
  can't provode key material (like any signature algorithm).
- If PSK is considered key agreement algorithm, then what is DHE-PSK
  (since DHE is key agreement).

> server (instead of each other) can rely on the server's cert.

Due to how key derivation works with pure PSK, the clients can MITM
each other. And if it is supposed to be DHE-PSK+RSA-PSS, wouldn't
something like using HMAC for client auth work?

> authentication side of things (via the signature_algorithms extension).

TLS v1.2 also has PSK identity hint, in which server first gives a hint
before client selects the final identity (which obviously is 2RTT process).

To me it seems (DHE-)PSK is quite special.

>  non-significant, but i guess that's a slightly different discussion.)

What would the difference from TLS standpoint be (apart from some keysize
parameters)?

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Apr 2015 09:03:27 +0300

> On Apr 14, 2015, at 6:02 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

IKE has a complex structure of multiple “proposals”, each a collection of several “transforms”, where a “transform” is one algorithm and you can have more than one algorithm of the same type in a single proposal, so you could have for example:

 - proposal #1: GOST signature, GOST DH group, GOST encryption, GOST MAC
 - proposal #2: AES-128-CGC, AES-GCM-128, HMAC-SHA-1, HMAC-SHA-256, 2048-bit DH group, P-256, RSA certificates.

I haven’t found this construct to be particularly useful, and my implementation only ever emits one proposal (but can be configured with multiple algorithms).

Back to TLS: Your contrived policy can be implemented in the server. Your server (or Rich’s hosting) can be programmed to select only certain combinations depending on SNI, and that does not require any special support in the protocol.

For a client it is more difficult. Do we have a use case where a client connects to some site, and is fine with either GOST certificates and GOST encryption, or with AES-GCM and ECDSA, but not a mix?  If we accept that such policies should be enforced by servers, I think the problem goes away.

Yoav