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

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

Return-Path: <mike-list@pobox.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227E711E8279 for <tls@ietfa.amsl.com>; Wed, 30 Oct 2013 08:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVCIWzl+OT2W for <tls@ietfa.amsl.com>; Wed, 30 Oct 2013 08:49:32 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1811E8173 for <tls@ietf.org>; Wed, 30 Oct 2013 08:49:20 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 67F7AE01C; Wed, 30 Oct 2013 11:49:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=LEw49q00jxSR uyZXGuwFlwHWpYI=; b=bEAhQLo6xsWzir6pUd3EFQs7aSAUOsUrmHd7Xo++UQAS 7SzH/IEd6f+ZzfYR1PLiGNNF+k3a6TH6Lk73w3rJZ+N32iwuPcIwnC74hmhV9nYH My/E5SVC5XbA34Uo0/Zl11IOdbgtWSLU12mVzbadYmPzjy0i2cR3YZ2Kuh8s/1A=
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=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 40F3DE018; Wed, 30 Oct 2013 11:49:15 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4651CE014; Wed, 30 Oct 2013 11:49:01 -0400 (EDT)
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
X-Pobox-Relay-ID: CBFFF0CA-417A-11E3-AF3B-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List <tls@ietf.org>
Subject: [TLS] TLS 1.3 (Re: TLS at IETF 88)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 15:49:37 -0000

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