Re: [TLS] Keeping TLS extension points working

David Benjamin <davidben@chromium.org> Tue, 26 July 2016 15:43 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251012D8DA for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 08:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 rdF-7mQQetX1 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2016 08:43:39 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 C1B9712D88A for <tls@ietf.org>; Tue, 26 Jul 2016 08:11:51 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id f93so7412229lfi.2 for <tls@ietf.org>; Tue, 26 Jul 2016 08:11:51 -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; bh=OmAX46XCT6Ajfhi2Vs2pY4An7BpOI3aEnms32NKpCp4=; b=XmMKRPdJcCg6XOWz5tChKCWxp0Az9mW0vX/a3Qnu/MbP20vZcpao+i6w55CF4vuy9d lMDEsH//URnpAaMRNkPyAaJN5ArumbMgIAGy6tnvm1jbe5z7OFIC8yfBZt42twSlnETh B6tFmD+jFWP+vXXPS0Vfx0YwHyZUiF/9f+g8U=
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; bh=OmAX46XCT6Ajfhi2Vs2pY4An7BpOI3aEnms32NKpCp4=; b=TJPr3pv1jycuxE1Wk5wymxAQM8euYGx5eQdrVLO1xnn+U/rVrUQ7SXIUu5KbHShATI VjGLa8XNJHzas1w0uGUJ9DCww5CHbIPrRae0DsKR5AjzOKkd/ZnaY7RTRfAuxxV/iiPE kEqnnxZF60NegcZOW3gcJUmZX4ZL0eIEsmg+hjZLAo6VgPqV74eeWKdkXftI9ZSNVh5+ phNadfKUVNrSEEskESW3zqP37WLbZNsiP62c7SaAmIztZxnB68vQcs2llZzR6tTEB0FO z+tB8g0+SiaKqxQgjaLJ922VWgwVIaGvPQlfaeIU3YvXoDb3P7hmjgESHdKoDOtZVmhd jyYA==
X-Gm-Message-State: AEkoousJ43w+/wTihwiIn/H7sGU/uCbtMFpsNXmCOd3JlpW8+q1wIZjLIeujdci1RlXk0YeZh69uQiFtzZC4fppT
X-Received: by 10.25.216.26 with SMTP id p26mr10100357lfg.122.1469545909716; Tue, 26 Jul 2016 08:11:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>
In-Reply-To: <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 26 Jul 2016 15:11:40 +0000
Message-ID: <CAF8qwaARvrFKhBUi10rEEUWpito3n4OWXuK5JH0ZO4gU6rzK5w@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Content-Type: multipart/alternative; boundary=001a114024a4ee7ac505388b5194
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/SQoReZnpacy2TNuU8RHjHrAeMSA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Keeping TLS extension points working
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 26 Jul 2016 15:43:42 -0000

On Tue, Jul 26, 2016 at 10:52 AM Sean Turner <sean@sn3rd.com> wrote:

> David,
>
> Technically, IANA makes the assignments we (the IETF/TLS WG) ask them to
> make via the IANA considerations section.  They enforce the registry policy
> established when we (the IETF/TLS WG) originally established the registry;
> the available policies are found in RFC 5226 (and there’s some more rules
> in RFC 7120).  So, I’m hoping that you could tweak your draft somewhat to
> be instructional and then suggest some values (this purely procedural dance
> has worked in the past and it’s what we’re doing for
> draft-ietf-tls-ecdhe-psk-aead):
>

Got it. Will switch things to TBD. Thanks!


> 0) In s2, replace the two lists with something like:
>
> The draft reservers the following X cipher suite values: Values TBD
>
> The following X values are reserved as both GREASE extension values and
> GREASE named group values: Values TBD
>
> 1) In 5, add a {TBD} sub-column to the 1st column for each value in the
> tables (apologies for the formatting):
>
> +-------------------------+-------------+---------+-----------------+
> |    Value                   | Description | DTLS-OK |    Reference    |
> +-------------------------+-------------+---------+-----------------+
> | {TBD} {0x0A,0x0A} |   Reserved  |    Y    | (this document) |
>
> And then add something like this to the end of the section:
>
>   The cipher suite numbers listed in the second column in the
>   values column are numbers used for cipher suite interoperability
>   testing and it's suggested that IANA use these values for assignment.
>
>
> I’m sure somebody will eventually comment on the following header fields:
>
> 0) “Status: Informational” because some of the registries right now
> require standards track RFCs to do the assignments.  But, everybody should
> momentarily suspend reality because we’re going to change the registry
> rules for the registries you are adding values you to be something that
> would allow an draft intended for “informational” to do the updates, i.e.,
> just leave it alone for now.
>

Oh, this wasn't a conscious decision. I actually didn't even notice that
was a field to set. I just ended up with whatever defaults the template I
was using picked. Like I said, I'm new to this game. :-)

Pending registry rule change aside, is "Informational" correct for this
sort of thing or should I switch it?


> 1) “Updates: 5246 (if approved)” because typically extension documents
> don’t “update” the base specification.  If you are suggesting that all
> implementations must support these values then an updates header makes
> sense.  Note I’m sure somewhere along the way an extension that isn’t
> expected to be supported by all implementation has an updates header but
> what I described is how we’re doing it now.
>

I wasn't sure and mimicked RFC 7507 and RFC 7685 which both did this.

I expect that all servers will "support" this specification in so far as it
says nothing useful for servers. TLS servers are supposed to ignore unknown
values. I would certainly like for as many clients to do it as possible so
the ecosystem effects work out, but I certainly don't intend for it to be
any kind of requirement. (I suppose the text says MAY so existing clients
also "support" it by default.)

Is it better to remove that line in this case? Happy to do whatever works.


> Cheers,
>
> spt
>
> PS: As chair, I try to deal with/deflect as many of these procedural
> issues as possible, but if you want to know more please let me know
> off-list.  This actually goes for anybody on the list.
>
>

> > On Jul 25, 2016, at 18:32, David Benjamin <davidben@chromium.org> wrote:
> >
> > Hi folks,
> >
> > I'm not sure how this process usually works, but I would like to reserve
> a bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
> > https://tools.ietf.org/html/draft-davidben-tls-grease-00
> >
> > (The name GREASE is in honor of AGL's rusted vs. well-oiled joints
> analogy from https://www.imperialviolet.org/2016/05/16/agility.html )
> >
> > One problem we repeatedly run into is servers failing to implement TLS's
> various extension points correctly. The most obvious being version
> intolerance. When we deployed X25519 in Chrome, we discovered an intolerant
> implementation. (Thankfully it was rare enough to not warrant a fallback or
> revert!) It appears that signature algorithms maybe also be gathering rust.
> Ciphers and extensions seem to have held up, but I would like to ensure
> they stay that way.
> >
> > The root problem here is these broken servers interoperate fine with
> clients at the time they are deployed. It is only after new values get
> defined do we notice, by which time it is too late.
> >
> > I would like to fix this by reserving a few values in our registries so
> that clients may advertise random ones and regularly exercise these
> codepaths in servers. If enough of the client base does this, we can turn a
> large class of tomorrow's interop failures into today's interop failures.
> This is important because an bug will not thrive in the ecosystem if it
> does not work against the current deployment.
> >
> > If you were in Berlin, you may recognize this idea from the version
> negotiation debate. Alas that all happened in the wrong order as I hadn't
> written this up yet. This idea can't be applied to versioning without
> giving up on ClientHello.version, but we can start with the rest of the
> protocol.
> >
> > David
> >
> > PS: This is actually my first I-D, so apologies if I've messed it up
> somewhere!
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>