Re: [TLS] A la carte handshake negotiation

David Benjamin <davidben@chromium.org> Fri, 26 June 2015 22:40 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 882731AD0BF for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 15:40: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 NOCtSGJvvfze for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 15:40:26 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 D9DDF1ACE80 for <tls@ietf.org>; Fri, 26 Jun 2015 15:40:25 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so22599177igb.0 for <tls@ietf.org>; Fri, 26 Jun 2015 15:40:25 -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=x0lRc8slmCrf28+UgruRB96IF98J9vuofhfCGiZ9YnQ=; b=Xom4mBdEgloNBROIvvEBF5R87Y8elXNeXM6cYshMFg4cgI30BS/a3pMZ8xvkch+POU wtpHq7p2WVPeUUttwlnFI3w8DI47YJmBigFzEKjHAu4gQWDDH/JbLoj/o0n50LWG5q8e V6aBBT/2hvi8VAVnOCiEqw8NQYeBLSZdhu6cU=
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=x0lRc8slmCrf28+UgruRB96IF98J9vuofhfCGiZ9YnQ=; b=Vtj4DKus8beCKmUbsA1RKOwbRk+RAZDtAEXsmTv2tBYSbU93jdaV5QeOiMnd2bs0uL rod3IMwbO4Hir8pS+HiAAI/ouNKGBJvHQMYWYwvgcH/lt2AyK3gKBdu1HvQgDykX3tlp lGttW/6MDBTtAx6BBY6g0k5KSaak8ElTusfoH5RXU0BrOkvsB6TNloAM0BnrU+UjjvcV VzDFrXu/kVV6DVrOwoILhlnjZapGX23wr/ozPqTtZ5jxM9Rj1ArFvoSRxfRojpTRLyn7 ZiUcZiYjc7H95kdpR8GovnKM0SfKklzTsOdhoKN/2lj09n9Th8nmmSYTy8hhtYLaf7z4 PX/g==
X-Gm-Message-State: ALoCoQnwoMk4Ppt3QmwdPpud1JI1nVb/Ei//12rBzQBH96e295cWeeiEzCqhD9kIwZEgS2WAtD2v
X-Received: by 10.50.61.130 with SMTP id p2mr554278igr.9.1435358424948; Fri, 26 Jun 2015 15:40: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> <20150626204731.GJ6117@localhost> <CAF8qwaAbgQMK7C4aJExUTz+kJBV=S5vuXy=Ba75NGqXqwABN9A@mail.gmail.com> <20150626221456.GK6117@localhost>
In-Reply-To: <20150626221456.GK6117@localhost>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 26 Jun 2015 22:40:15 +0000
Message-ID: <CAF8qwaAkBAXDkhd3zU=uO1t-dv7iu0bhb9bH28JHROrWp98SEA@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="047d7bdcaa0e0b9a170519736d57"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kZyETqFrQ9ZLJgPa1ggdfGViv_g>
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 22:40:27 -0000

On Fri, Jun 26, 2015 at 6:15 PM Nico Williams <nico@cryptonector.com> wrote:

> On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote:
> > On Fri, Jun 26, 2015 at 4:47 PM Nico Williams <nico@cryptonector.com>
> wrote:
> > > This can be fixed by having signalling cipher suite assignments for
> > > negotiating a cartesian product of them (in addition to any actual
> > > cipher suites offered).  [...]
> >
> > Hrm. I might not understanding you right, isn't that roughly the same as
> > defining new values:
> >
> >   [...]
> >
> > and saying that TLS 1.3 uses those rather than either ECDHE_RSA or
> > ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite
> list
> > for convenience and avoiding a new extension? That seems reasonable to me
> > actually. If we avoid weird pre-1.3 interactions, I don't have opinions
> on
> > new extension vs camping out in the old namespace.
>
> Yes, they'd share the same cipher suite number (and name) namespace.
>
> Pre-1.3 implementations would ignore these "new" cipher suites, which is
> why still sending some old ones is important for interop.
>
> Using an extension loses the ability to express old vs. new cipher suite
> relative priorities.  That might not be a problem (with 1.3<->1.3 using
> only the new thing), and if no one cares, then I wouldn't either.
>

I was assuming there would never be a reason to order 1.3 and 1.2's
mechanisms, yeah. If it's a new extension, only use that new extension and
we just ignore the 1.2 cipher suite list once 1.3 is set. If it's camping
out in the cipher suite list, anything not in 1.3 should be ignored once
1.3 is set.

(Amusingly, if we use the same namespace but use completely non-overlapping
values, it might be safer to put the 1.3 ciphers *after* the 1.2 ones. I've
gotten a bug report about a server that only pays attention to the second
byte of every cipher suite value. Or perhaps it thought cipher suites were
one byte. Anyway, I don't actually think this is worth bothering about,
just a funny/sad story. It's only been the one report and I declined to do
anything for it.)

David


> > Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the
> > common case can send a slightly shorter ClientHello? (For Chrome I think
> > it'd be four bytes because we only do two AEADs.)
>
> There's two different goals here:
>
> 1) "Compress" the ClientHello;
> 2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite
>    registry.
>
> (2) is easier if we go with an extension instead of camping on the
> cipher suite namespace.
>
> We've failed to register useful cipher suites before.  We can probably
> fix this anyways by writing tools for IANA to do the cartesian product
> so that it's never again a manual process for RFC authors nor for IANA.
>
> Elegance would also be a goal, except that it's too late for that.
>
> Nico
> --
>