[TLS] TLS 1.3 (Re: TLS at IETF 88)

Michael D'Errico <mike-list@pobox.com> Wed, 30 October 2013 15:49 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SGd23q bvBeWVGQTXJJb/N09tzzScMqxERypJ7NIQuZY48ERDy/fMqGMTNzOe2xsDSaVbvB TQphswlLjfCGXp2+Zj6axnyGCCOrTbAEtH6IDTp9+gyD1QD13LJPCILqirbJCj81 KU/1+KbIH8D3b6LopOAYBgelpO4WMdzfMwcmw=
Message-ID: <52712A6C.4050306@pobox.com>
Date: Wed, 30 Oct 2013 08:49:00 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <A95B4818FD85874D8F16607F1AC7C628F81FFA@xmb-rcd-x09.cisco.com> <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org>
In-Reply-To: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List <tls@ietf.org>
Subject: [TLS] TLS 1.3 (Re: TLS at IETF 88)
Precedence: list

Paul Hoffman wrote:
> On Oct 29, 2013, at 11:16 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
> 
>> 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/
> 
> 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

[TLS] TLS at IETF 88 Joseph Salowey (jsalowey)
Re: [TLS] TLS at IETF 88 Paul Hoffman
Re: [TLS] TLS at IETF 88 Martin Rex
[TLS] TLS 1.3 (Re: TLS at IETF 88) Michael D'Errico
Re: [TLS] TLS 1.3 (Re: TLS at IETF 88) Dmitry Belyavsky