IETF Logo Mail Archive

Re: [TLS] Keeping TLS extension points working

Sean Turner <sean@sn3rd.com> Wed, 27 July 2016 20:02 UTC

Return-Path: <sean@sn3rd.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 6DB2E12D91B for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 13:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 OL4YNHQZHkTH for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 29DB912D8F9 for <tls@ietf.org>; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id f6so59414800ith.0 for <tls@ietf.org>; Wed, 27 Jul 2016 13:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOBfn/MZrP2/p8+dpKTeDjFfWThGQiR4OZzRD7mzTes=; b=jxxpUompRwY7sOAn8SsrzB64djaglqGS9cQZFPXU4ctmsAD86UWqqyhMRC5rUlJ+RR /thXEQAeFhRzPdqmUJTXzbQAH6lSxmG277T4SAdr6lzf3c/YyLjU4/hploGItRGoLUpV RF32TRSMy606Sx11Tqp6rvUIx1QoI105Rx9Bk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fOBfn/MZrP2/p8+dpKTeDjFfWThGQiR4OZzRD7mzTes=; b=msJzuehXzMLyeLbfPeV8Il8T8CFkp8lhZZZjbnzRX8/u4o0+BLvUNDMU2bDAXPjsWs DF1UTVFgWgVH0Mk2JHMkNWPoDmFRlnl60FBQJsDtWvVJioEOa7MvB4XLj+yCPQtxZwE6 4Ks13dDannwF9un9ka1l04wHvenSj87vZxe6/kdcyIvOUmXr+juBXSzryKdEYspo+9x9 gukCPOrHq/aesZNc6+DqenMWovo2j1WWh6ICnzX7Fq0e3sxCEjJlwQ3KtUGWkuOMuOmF 9Hzzfzg5Jj/LHtOjEc1h5mWbCKiD/A60a1QBaXleJWKCrotsU5q09j+1SvtlW6RwFphz SrwA==
X-Gm-Message-State: AEkoouulSynUvWi38L/rEYEOyB0VmSbgL1XQ/5/i2OBy+sJ3OLJn8tESQUJZustJWEvuFg==
X-Received: by 10.36.33.208 with SMTP id e199mr36385343ita.41.1469649725558; Wed, 27 Jul 2016 13:02:05 -0700 (PDT)
Received: from [5.5.33.74] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id l195sm3461876itl.17.2016.07.27.13.02.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jul 2016 13:02:05 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <CAF8qwaARvrFKhBUi10rEEUWpito3n4OWXuK5JH0ZO4gU6rzK5w@mail.gmail.com>
Date: Wed, 27 Jul 2016 16:02:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <67E72566-5389-4AD2-8965-4FF85F9F42FD@sn3rd.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <0B0C11B8-CC4A-46C4-A134-881A41005502@sn3rd.com> <CAF8qwaARvrFKhBUi10rEEUWpito3n4OWXuK5JH0ZO4gU6rzK5w@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XtHg95q05RrIHX12xpXNASSUlUg>
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: Wed, 27 Jul 2016 20:02:07 -0000

> On Jul 26, 2016, at 11:11, David Benjamin <davidben@chromium.org> wrote:
> 
> 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.

I’d probably lean towards removing it.

spt

v2.23.0 | Report a Bug | By Email