Subject: [TLS] TLS at IETF 88

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 29 Oct 2013 18:16:39 +0000

The TLS working group will meet at IETF 88
Tuesday,November 5, 2013 from 1610 to 1840 PST

The latest Agenda can be found here: https://datatracker.ietf.org/meeting/88/agenda/tls/

Thanks,

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Oct 2013 11:36:44 -0700

> The latest Agenda can be found here: https://datatracker.ietf.org/meeting/88/agenda/tls/

So we can come prepared: What will the topics for the hour of "TLS 1.3" be?

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Tue, 29 Oct 2013 21:40:22 +0100 (CET)

Paul Hoffman wrote:
> Joseph Salowey (jsalowey) <[email-masked]> wrote:
>>
>> The latest Agenda can be found here:
>> https://datatracker.ietf.org/meeting/88/agenda/tls/
> 

Maybe fixing the TLSv1.2 wreckage (e.g. the botched signature algorithm
extension) and how to get rid of TLS protocol version on the wire
to improve interoperability in the installed base and get rid of
the fallback reconnects in TLS clients.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 30 Oct 2013 08:49:00 -0700

> So we can come prepared: What will the topics for the hour of "TLS 1.3" be?

I won't be at the meeting, but the one change I'd like to see in TLS 1.3
is a separation of cipher suites into two parts - authentication mechanism
and encryption/mac algorithms.  There are currently only 21 authentication
mechanisms defined:

     DH_anon
     DH_DSS
     DH_RSA
     DHE_DSS
     DHE_PSK
     DHE_RSA
     ECDH_anon
     ECDH_ECDSA
     ECDH_RSA
     ECDHE_ECDSA
     ECDHE_PSK
     ECDHE_RSA
     KRB5
     PSK
     PSK_DHE
     RSA
     RSA_PSK
     SRP_SHA
     SRP_SHA_DSS
     SRP_SHA_RSA

and 31 combinations of encryption algorithm and MAC:

     3DES_EDE_CBC_MD5
     3DES_EDE_CBC_SHA
     AES_128_CBC_SHA
     AES_128_CBC_SHA256
     AES_128_CCM
     AES_128_CCM_8
     AES_128_GCM_SHA256
     AES_256_CBC_SHA
     AES_256_CBC_SHA256
     AES_256_CBC_SHA384
     AES_256_CCM
     AES_256_CCM_8
     AES_256_GCM_SHA384
     ARIA_128_CBC_SHA256
     ARIA_128_GCM_SHA256
     ARIA_256_CBC_SHA384
     ARIA_256_GCM_SHA384
     CAMELLIA_128_CBC_SHA
     CAMELLIA_128_CBC_SHA256
     CAMELLIA_128_GCM_SHA256
     CAMELLIA_256_CBC_SHA
     CAMELLIA_256_CBC_SHA256
     CAMELLIA_256_CBC_SHA384
     CAMELLIA_256_GCM_SHA384
     NULL_MD5
     NULL_SHA
     NULL_SHA256
     NULL_SHA384
     RC4_128_MD5
     RC4_128_SHA
     SEED_CBC_SHA

Thus there could be 31 x 20 = 620 usable cipher suites, but we have only
defined 286 of the possible combinations.

Less-supported authentication mechanisms tend to have fewer options
available to them.  For example SRP is usable only with 3DES and AES_CBC
at present since those are the only defined suites.  Separating cipher
suites into two values would allow any encryption/mac combo to be used
with any authentication mechanism.

I've noticed that there is current interest in adding more encryption
algorithms (e.g. Salsa, Chacha) and MACs (UMAC, VMAC, Poly1305) to TLS.
It seems to me that there'd be great value in only having to define a
single code point for each encryption/mac combination and having them
become immediately available for use with any authentication mechanism.

Mike

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 31 Oct 2013 02:32:17 +0400

Hello!

In Russia we have some more authentication mechanisms and at least two
cipher/MAC combinations.

On Wed, Oct 30, 2013 at 7:49 PM, Michael D'Errico <[email-masked]>wrote:

>>> The latest Agenda can be found here: https://datatracker.ietf.org/**
>>> meeting/88/agenda/tls/<https://datatracker.ietf.org/meeting/88/agenda/tls/>
>>>
>>
> ______________________________**_________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>

-- 
SY, Dmitry Belyavsky