Re: [TLS] A la carte handshake negotiation

David Benjamin <davidben@chromium.org> Sat, 13 June 2015 19:19 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 7440C1A8ADD for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 12:19:34 -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 Ax0IozwxTe61 for <tls@ietfa.amsl.com>; Sat, 13 Jun 2015 12:19:32 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 8267E1A8A80 for <tls@ietf.org>; Sat, 13 Jun 2015 12:19:32 -0700 (PDT)
Received: by iesa3 with SMTP id a3so41443921ies.2 for <tls@ietf.org>; Sat, 13 Jun 2015 12:19:31 -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=qWjY12uPmg8sj71WDfwv0MJhDqMnMX3m9VGl8Nxq1lQ=; b=gh9MZzTE2PjLmNQDhtzD1xC3LdHGQsqvwVDQBDyRK7yF9hckfjv/CIDRFbzgU0dAG7 wlk9xWyD8AFwCTCDPEkMsenSRrij9rGytufK2wRUpNET65I0TZuZs+NhJJqZaccWJsGZ 12jC2OiyxwJ3bB3kK643GbKeqfUSXSbnWWWxs=
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=qWjY12uPmg8sj71WDfwv0MJhDqMnMX3m9VGl8Nxq1lQ=; b=eIgczjMDlJrEWpIiEPS/dcdR26pTHzRAFUaSwpThw5eQtloHMKNmAnqQ9GDD7USLxF vFUnr2PXRZ6Glvsyhwm1+23hJGhhin9zCZN+9EgL5q2BYBL81nDztPAPh2Prqb6cAwUC WSZc5MqT77DwxNxPdN4ozkDjyrUd0oRSYC54bCME58fRdH3XxhnycCnpPmRXv6b7CqY3 Mi/GF2eCphocUSlya099cg5cePKrceD3MtRK4R4uU78+br4CwquVj8Z8EGPh1di/lQB5 Vo7Z9IKNUZRMxbS8A9POVxHdXgQQpXzr680aXa4qvs8+h+mNEr54/O5WVKxGkxODZjVc pUtw==
X-Gm-Message-State: ALoCoQkaK2vUnecpYwazHGAMnu6yYlX0yQwORoe6a35VnkP+3tA0xCSi2TCvTVMWXG4BqpbSmTeX
X-Received: by 10.50.79.169 with SMTP id k9mr11684317igx.44.1434223171780; Sat, 13 Jun 2015 12:19:31 -0700 (PDT)
MIME-Version: 1.0
References: <201506111558.21577.davemgarrett@gmail.com> <CAF8qwaCAvsrcb6UbcG67XdpFwsL2T-76ZwySbzS5O0Qd0ReLSQ@mail.gmail.com> <201506131459.31745.davemgarrett@gmail.com>
In-Reply-To: <201506131459.31745.davemgarrett@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 13 Jun 2015 19:19:20 +0000
Message-ID: <CAF8qwaBsZ9Xqjrt6aX1tRUtspeJ2P429C5K+PXkkLd1t8se0vg@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="089e013a01c8af2a1b05186b1aed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gyeTRHNeCF3WaMvbuyjL-bRNV5U>
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: <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 19:19:34 -0000

On Sat, Jun 13, 2015 at 2:59 PM Dave Garrett <davemgarrett@gmail.com> wrote:

> On Saturday, June 13, 2015 02:28:06 pm David Benjamin wrote:
> > On Thu, Jun 11, 2015 at 3:58 PM Dave Garrett <davemgarrett@gmail.com>
> wrote:
> > > * TLS 1.3 implementations negotiate ECDHE/DHE & RSA/DSS/ECDSA solely
> via
> > > the "supported_groups" & "signature_algorithms" extensions.
> > > [...]
> > > 4) All TLS 1.3 implementations are expected to be able to handle ECC,
> but
> > > are not required to offer or negotiate it. (at least, here)
> >
> > Are you sure this proposal completely achieves that? I believe, by using
> > ECDHE_ECDSA as the representative key exchange, this effectively requires
> > all clients to offer the ECDHE_ECDSA variant of every bulk cipher.
>
> Yes, for TLS 1.3 negotiation, offering the ECDHE_ECDSA would be required
> under this proposal.
>

Perhaps I'm misunderstanding your goals here then. My read of (4) above was
that this was intended to use the ECDHE_ECDSA representative of, say,
AES_128_GCM as the spelling of AES_128_GCM (so effectively repurposing the
cipher list as the list of AEADs[*]), and that this wouldn't actually
translate to offering ECDHE_ECDSA due to that really being negotiated by
the other two extensions.

But this doesn't seem to be completely the case because the ClientHello is
interpreted by both TLS 1.3 servers and existing servers. And so we need to
consider the effects on both to avoid interop. issues.

[*] As you say below, not quite because you still premultiply the really
exotic things like PSK and anon. But setting those aside for the sake of
discussion.

David


> [snip]
> > Personally, mandatory ECDHE seems just fine. Still, something to be aware
> > of. ECDSA might be more of a nuisance. At least as things stand
> currently,
> > Chrome does not offer ECDSA suites on Windows XP because the system
> > certificate verifier can't handle it.
>
> At some point, clients that want to continue supporting EOL OSes forever
> are going to have to roll their own implementations of modern crypto
> instead of attempting to rely on the OS. Either that, or drop support.
>
> [snip]
> > Wouldn't it be simpler to just add a supported_aeads extension and make
> the
> > cipher suite list meaningless for 1.3? With all the obsolete ciphers
> gone,
> > most clients would probably only offer 2-3 of them. The interop risks of
> a
> > bad compatibility cipher suite list seem simple enough. Ensure that:
> >
> >   {legacy cipher list} ∩ {all 1.3 combos} ⊆ {key ex.} × {sig alg.} ×
> {aeads}
> >
> > But I haven't thought about this very hard and haven't been following the
> > topic, so that may be opening a huge can of worms.
>
> That's essentially the nuke it all from orbit, just to be sure, solution.
> ;)
>
> I'm not against it. It would trade one form of complexity (reduced suites
> + existing extensions) for a new form of complexity (existing extensions +
> a new extension), but that could be worth it and simpler overall. If we
> want to make absolutely sure TLS 1.2 backwards compatibility and TLS 1.3
> support are separate, this is the way to do it.
>
> The largest benefit of this approach might actually just be dropping the
> need to define the missing ECDHE_* suites to fill in the gaps that got
> overlooked (e.g. expired drafts). The whole extension and its initial
> codepoint assignments could be defined in the TLS 1.3 spec.
>
> It wouldn't be quite as simple as you propose, though, because we'd
> definitely have to add a new way to declare anon or PSK support via
> extensions, but that's doable.
>
> That said, there was push back against full a la carte in previous
> discussion on this list. The reason for ending up at this proposal was the
> desire to use _existing_ systems (ciphers + existing extensions) in a
> consistent manner to negotiate things with fewer suites, rather than
> overhaul everything.
>
> I'm perfectly willing to throw out my draft proposal and switch to this
> strategy if we agree it is worth implementing. Obsoleting the entire cipher
> suite system would be opening a can of worms, but it might be a smaller can
> of worms than we currently have to deal with.
>
>
> Dave
>