Re: [TLS] A la carte handshake negotiation

David Benjamin <davidben@chromium.org> Fri, 26 June 2015 20:56 UTC

Return-Path: <davidben@google.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 9C94B1ACDCD for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 13:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9VywOsqU5z7K for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 13:56:25 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 B51E31ACDB6 for <tls@ietf.org>; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so21070031igb.0 for <tls@ietf.org>; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=hGqR1BYNWf81ePafKgChtMNR5mAeHR0x3Zvhe8zBvfN6eJJV4GqvqXmjlqOtpXp2rd C5mC8T1Pt3IP24klfPeoknN8GVYKclpn0NxDtUG1dJ8R4Ei5Euo33U3kGhNdqkBWTPY0 MwDJmua68lHpAeYrjkDOj8sLwMcZlwsIiMbW4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=UHx/sV7CXH54+2vXigD+hiazQXCtkiVGNzX4+BuSpp46NVR8H8691JoSN+WoQ+DQkk r82wvxbtYleQ96M+uRNoGZGvhO2b0efIxYE+QOFHLvk2UfYGhcC5H6qc2lzOLZ9IsuKb pPc/F64FuW9OI8dflSbpPMnt5XjPRdXjMJ+TkwOp1cTO4xJTuQGXIFnfJDuOjq7pYVv4 JCgXl39JzFelAOC2Rm1A0yGo0zFVNPXjvMfNPVAbRUS4q5HvkBWfmuJJTUsOcW5f13JY s3+Yr4Tl0GjXVO5GHrY5MwlsAh5hh6cVCjF52x+pnStCvmPNHkKJRwqXy/2WLX6BwnfM Z6oQ==
X-Gm-Message-State: ALoCoQn1GBIt/8QdaO4vY0SXbY6w3U4qHCW4sPjU1LVrBmEjj5t/OK7w/nOMwhLnXDe5/xHmnhqs
X-Received: by 10.42.131.202 with SMTP id a10mr5664069ict.49.1435352184210; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
MIME-Version: 1.0
References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506170131.17179.davemgarrett@gmail.com> <CAF8qwaCew287OLCdrgdKXbzbc+xWmT4eYWKfLJXLbTvEFVBJWA@mail.gmail.com>
In-Reply-To: <CAF8qwaCew287OLCdrgdKXbzbc+xWmT4eYWKfLJXLbTvEFVBJWA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 26 Jun 2015 20:56:14 +0000
Message-ID: <CAF8qwaBABFNXjXtdJ3p8uAHc3osQu1DtQ1qyHhNbzttes2fATQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>, Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="bcaec55237801169d3051971f90a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/5vADd4TVgQyLCtNl_vDlu-8sv8Q>
Cc: "<tls@ietf.org>" <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: <https://mailarchive.ietf.org/arch/browse/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, 26 Jun 2015 20:56:27 -0000

[Oops. I sent this from the wrong address the first time so it didn't get
through to the broader list. Apologies for messing up the threading.]

On Fri, Jun 26, 2015 at 3:02 PM David Benjamin <davidben@google.com> wrote:

> On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett <davemgarrett@gmail.com>
> wrote:
>
>> [snip]
>
>
>> Ok, I revised the drafts and forked the anon deprecation changeset.
>>
>> Main draft proposal:
>>
>> https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites-in-tls-13
>>
>> Version with deprecated anon suites:
>>
>> https://github.com/davegarrett/tls13-spec/blob/alacarte-noanonsuites/draft-ietf-tls-tls13.md#anonymous-key-exchange
>>
>> Note that both totally deprecate all DH(E) suites, as that's one of the
>> goals here. (due to weak DH params, old Java choking, & etc.) Thus, all
>> suites must be ECDHE prefixed for TLS 1.3 support under these proposals
>> (with the exception of plain PSK). All ECDHE suites would be capable of
>> negotiating either ECDHE or DHE using string groups via the extension.
>>
>> PSK & anon will need a litany of new ECDHE suites to be defined. There is
>> currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among the
>> reasons I pursued the idea of merging it into PSK).
>>
>> I'm fine with relegating the anon deprecation idea to the bin if we agree
>> to define all the new suites we need to maintain support. Getting
>> ECDHE_anon into the ChaChaPoly draft would be a start.
>>
>
> I have the same concerns with this version as before. I don’t believe it
> lowers the risk of accidental interop failure---if anything, it makes it
> worse.
>
> This scheme is still a problem for Chrome on Windows XP. This proposal
> effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard
> PKI-based handshake. Whether or not this is desirable, it certainly should
> be spelled out clearly in the spec.
>
> Imagine how implementations look. Most allow configuring the cipher suite
> list. This now interacts subtly with configuring 1.3 ciphers, and we have
> the same interop risks of a parallel extension. What if the consumer, for
> whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but included
> ECDHE_RSA? Now 1.2 servers work, 1.3 ones don’t. Alright, so what if we
> internally checked for consistency? That’s fine, but we could just as
> easily have checked for consistency between 1.2 cipher suites and a new 1.3
> mechanism.
>
> A separate extension avoids any mixing of semantics and gives a clean
> break from the old pre-multiplied scheme.
>
> As for what this extension contains, I don’t have strong opinions over
> whether we go a la carte---pruning down to the GCMs and CHACHA would also
> address the explosion---but if we bother, it seems a list of AEAD or
> AEAD+PRF is correct. The key exchange is already consistently separated
> from the bulk cipher in TLS. It's a waste to ignore the one clear boundary
> that we actually have.
>
> If the worry is state-machine bugs due to PKI and PSK key exchanges being
> different, we won’t guard against them by separating
> ECDHE_PSK_WITH_AES_128_GCM_SHA256 from ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
> No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from
> ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites
> will be funneled together anyway.
>
> David
>