Re: [TLS] A la carte handshake negotiation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sat, 13 June 2015 10:24 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A181B2FC3 for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 03:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_3CKt4FKO2w for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 03:24:39 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975DB1A8731 for <tls@ietf.org>; Sat, 13 Jun 2015 03:24:37 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 3E9FC81877; Sat, 13 Jun 2015 13:24:35 +0300 (EEST)
Date: Sat, 13 Jun 2015 13:24:34 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150613102434.GA16258@LK-Perkele-VII>
References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> <201506121236.18304.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <201506121236.18304.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XKdGjC3u7r9T_1u_A0gnh1mhN5I>
Cc: tls@ietf.org
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 13 Jun 2015 10:24:41 -0000

On Fri, Jun 12, 2015 at 12:36:17PM -0400, Dave Garrett wrote:
> On Friday, June 12, 2015 12:22:37 pm Viktor Dukhovni wrote:
> > On Fri, Jun 12, 2015 at 12:13:02PM -0400, Dave Garrett wrote:
> > > It might even be warranted to use only DH_anon suites instead
> > > of ECDH_anon due to its more widespread use. This would allow usage of
> > > ECC without having to specify any new ECDH_anon suites for those lacking
> > > them but already having DH_anon suites.
> > 
> > I'm afraid I don't understand the above.  Also AECDH (ECDH_anon)
> > is not particularly rare:
> > 
> >     Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
> 
> Your quote is usage of:
> TLS_ECDH_anon_WITH_AES_256_CBC_SHA
> 
> AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only.
> 
> TLS_DH_anon_WITH_AES_256_GCM_SHA384 is in:
> https://tools.ietf.org/html/rfc5288
> 
> TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft:
> https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01
> 
> The current proposal requires all suites for TLS 1.3+ to be the ECC variants, which is not currently doable for anon AES-GCM. What I'm saying is that we could use "DH_anon" suites instead of "ECDH_anon" suites in this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable, however.
> 

Assembling the list of ciphersuites (with some renaming):

C02B	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02C	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
C0AC	TLS_ECDHE_ECDSA_WITH_AES_128_CCM_SHA256
C0AD	TLS_ECDHE_ECDSA_WITH_AES_256_CCM_SHA256
C0AE	TLS_ECDHE_ECDSA_WITH_AES_128_CCM8_SHA256
C0AF	TLS_ECDHE_ECDSA_WITH_AES_256_CCM8_SHA256
C05C	TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
C05D	TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
C086	TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
C087	TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
CCA2?	TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
????	TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384
????	TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA256
????	TLS_ECDHE_PSK_WITH_AES_128_CCM8_SHA256
????	TLS_ECDHE_PSK_WITH_AES_256_CCM8_SHA256
????	TLS_ECDHE_PSK_WITH_ARIA_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_ARIA_256_GCM_SHA384
????	TLS_ECDHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
????	TLS_ECDHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
CCA6?	TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
????	TLS_ECDHE_anon_WITH_AES_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_AES_128_CCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_CCM_SHA256
????	TLS_ECDHE_anon_WITH_AES_128_CCM8_SHA256
????	TLS_ECDHE_anon_WITH_AES_256_CCM8_SHA256
????	TLS_ECDHE_anon_WITH_ARIA_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_ARIA_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_CAMELLIA_128_GCM_SHA256
????	TLS_ECDHE_anon_WITH_CAMELLIA_256_GCM_SHA384
????	TLS_ECDHE_anon_WITH_CHACHA20_POLY1305_SHA256
00A8	TLS_PSK_WITH_AES_128_GCM_SHA256
00A9	TLS_PSK_WITH_AES_256_GCM_SHA384
C0A4	TLS_PSK_WITH_AES_128_CCM_SHA256
C0A5	TLS_PSK_WITH_AES_256_CCM_SHA256
C0A8	TLS_PSK_WITH_AES_128_CCM8_SHA256
C0A9	TLS_PSK_WITH_AES_256_CCM8_SHA256
C06A	TLS_PSK_WITH_ARIA_128_GCM_SHA256
C06B	TLS_PSK_WITH_ARIA_256_GCM_SHA384
C08E	TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
C08F	TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
CCA5?	TLS_PSK_WITH_CHACHA20_POLY1305_SHA256
	
yyyy => Assigned ciphersuite ID	(20)
yyyy? => Proposed ciphersuite ID in I-D (3)
???? => No current I-D (21)


Looking at how this would look with orthogoal negotiation:

17 codepoints:
TLS13_KEX_GDHE_CERT
TLS13_KEX_GDHE_PSK
TLS13_KEX_GDHE_anon
TLS13_KEX_PSK
TLS13_PROT_AES_128_GCM
TLS13_PROT_AES_256_GCM
TLS13_PROT_AES_128_CCM
TLS13_PROT_AES_256_CCM
TLS13_PROT_AES_128_CCM8
TLS13_PROT_AES_256_CCM8
TLS13_PROT_ARIA_128_GCM
TLS13_PROT_ARIA_256_GCM
TLS13_PROT_CAMELLIA_128_GCM
TLS13_PROT_CAMELLIA_256_GCM
TLS13_PROT_CHACHA20_POLY1305
TLS13_PRF_SHA256
TLS13_PRF_SHA384

(select one KEX, one PROT and one PRF)

- Would be much easier if SHA-2 ever gets broken[1]...
- All TLS stacks should already separate key exchange, record protection
  and PRF[2].
- GDHE is the unfication of DHE and ECDHE (some other things might unify
  with it as well[3]).
- I didn't separate GDHE from cert/psk/anon, because I can't get clean
  split there[4], and unclean splits are asking for trouble.
- Certificate part (other than existence thereof) in TLS 1.2 is already
  ignored in ServerHello (and only sets overrideable defaults in
  ClientHello[5]).


[1] Nominally, security rests on PRF-hash being CR (but exploiting
collision doesn't look to be easy). So if SHA-256 ever gets broken CR,
one needs to replace it (which would be 32 new ciphersuites, instead
of just one PRF, and if whole SHA-2 goes, need 44 new ones, instead
of just 2).

[2] There are tables of ciphersuite properties (what key exchange, what
record protection, what PRF (unless PRF is hardcoded to SHA256)).

[3] Including one or two potential PQ key exchanges.

[4] The problem is that PSK itself is quite different from GDHE_PSK,
which is quite different from GDHE_CERT.

[5] If signature_algorithms is sent, then similar ignore also applies
to ClientHello cipher list.


-Ilari