Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Michael StJohns <msj@nthpermutation.com> Fri, 03 April 2015 01:12 UTC

Return-Path: <msj@nthpermutation.com>
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 3268F1A8AB2 for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 18:12:58 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 2KCSJn3SVTYe for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 18:12:49 -0700 (PDT)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21341A7030 for <tls@ietf.org>; Thu, 2 Apr 2015 18:12:49 -0700 (PDT)
Received: by qcbii10 with SMTP id ii10so58220980qcb.2 for <tls@ietf.org>; Thu, 02 Apr 2015 18:12:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=FALYNgpbHPdiPtKZ5gApvI2w9LJd2Cn+w5P/aIaIxHk=; b=kbXpPdHBjLIPQYmkuOU2GrCqx1A0t0SmQn1PjFQA6Pc0zv7bKEID+ES8kzt7XZkxZe 9gFU9R60H14QHmAEDqlQ9XqvSymQ5LK228wFif5sQwYllD9YSjh50tVn31E8w/qXOCI1 Ejskjp7JzoZfBaXOOXGDo5rWNdZc/wAhGxzUqbXwkNmL0yWnDOC58O0QOTaFuc7C08tu EebeG/Vfl6B5FwQQE3eVuNx06qsOSJZ88IpmCBfoHtpHmYiKfiLDwlwRO+cAQkLnuEep ep45cYw1Hcez5D4xQQIkjLKGmTO3ITSMZJ+V+/Wht+ce8dnB/0FHHxKyfI5jj42eflDJ jYoQ==
X-Gm-Message-State: ALoCoQlKk8rADtiKjlh2ORJtxJ7zAUtc975+VkFlHK5N35NjYegniVArXL5GYe/PrJh2CXpuNhTg
X-Received: by 10.55.49.138 with SMTP id x132mr124554qkx.19.1428023568885; Thu, 02 Apr 2015 18:12:48 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:f827:63cf:7b05:550e? ([2601:a:2a00:84:f827:63cf:7b05:550e]) by mx.google.com with ESMTPSA id 13sm4682123qku.20.2015.04.02.18.12.48 for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 18:12:48 -0700 (PDT)
Message-ID: <551DE914.4010804@nthpermutation.com>
Date: Thu, 02 Apr 2015 21:12:52 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20150401201221.163745c2@pc1.fritz.box> <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <CAK3OfOgPbADQ1CvOs=8T7ee6f_T+bi3F6GCdBtxufQpznzYbQA@mail.gmail.com> <201504021257.09955.davemgarrett@gmail.com> <CAOgPGoDJTcLn4j90wNu=mhCZJnb2WUuAvM5TN6KOO7RdC==qHQ@mail.gmail.com>
In-Reply-To: <CAOgPGoDJTcLn4j90wNu=mhCZJnb2WUuAvM5TN6KOO7RdC==qHQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000800020400020206090700"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dzVq5N-w1vGoEHn608FyJcB20Vw>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
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: Fri, 03 Apr 2015 01:12:58 -0000

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:
>
>       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
>
>
>

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 <davemgarrett@gmail.com 
> <mailto:davemgarrett@gmail.com>> wrote:
>
>     On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote:
>     > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos
>     <codesinchaos@gmail.com <mailto:codesinchaos@gmail.com>> wrote:
>     > > 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.
>     >
>     > 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
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls