Re: [TLS] Keeping TLS extension points working

David Benjamin <> Fri, 02 September 2016 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA9B512D0FD for <>; Fri, 2 Sep 2016 11:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Status: No, score=-3.247 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=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id llqFJGyd5eR2 for <>; Fri, 2 Sep 2016 11:53:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3AF712B00C for <>; Fri, 2 Sep 2016 11:53:57 -0700 (PDT)
Received: by with SMTP id c198so55150984ith.1 for <>; Fri, 02 Sep 2016 11:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3nyEyh7+tdH/dBqqVrCzv8Lg9o31YursbePujYsfPc=; b=d5qiyPaUl5vYXh1LN2MVet4JWS32yU8tgJiEkAlgm/SLx8qC9sP/g/HSWGGH8sGcYE 0EO2k8NVAVWEjpQI/l2G4mr6JEE+0Sd4X1//+4NJUFNdWELd5Wq2h7xXRIF+KUh7bJMr RRyILhq6JLDRMs+DsZTQHXUQhJnjiOEQBYlHs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3nyEyh7+tdH/dBqqVrCzv8Lg9o31YursbePujYsfPc=; b=LZuP2au4yDvehr85lxh7sI5oW3Tl6T712fhtqSe4ScTmphnzBdqeiGgyjgUtn2WpRA zrbiua/14c3X5TynuEpTC/wMIrATbcIF3TgZVMBUwzOX0wYkCjUCAjMuUBWeABWPm6sS 39EggG77yK4TR5HR45/OOSI/rq64mHbJbe7WGquN8rCKP32Oi4ftusQ4t9qfAAc9SXgd 8m/5SyPpDq51hMRZr6YFbnUgMwiqY5sDT8rgwiH/WNna0byXe76YcBtMFqlY2J/g6Vwk bD6ULs30KBs9AtodLFO7l3GqCll2l+YGWke4lvGgULJAFKK9sKAZoIC/lKSFbzWJE/Hf 1AEQ==
X-Gm-Message-State: AE9vXwOmFi15l8o0bFR8CC6qJtm8MNstaV23L+sM2JZq40rm2m6PFSclKjrgNIcDZU8mIiUn+S/doZXFz8ygqlKy
X-Received: by with SMTP id n11mr7161895itd.18.1472842436843; Fri, 02 Sep 2016 11:53:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 02 Sep 2016 18:53:45 +0000
Message-ID: <>
To: Sean Turner <>
Content-Type: multipart/alternative; boundary=94eb2c05a22a426e63053b8ada5d
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Keeping TLS extension points working
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Sep 2016 18:54:00 -0000

I've finally gotten to uploading which hopefully
resolves the procedural issues (thanks again!). I've also revised the text
slightly after some off-list feedback about the risks of non-deterministic

I didn't add text about what middleboxes are allowed to do since I wasn't
sure what text would be useful. Looking at all the changes we've done in
TLS 1.3, they can do is syntax-check the ClientHello. Anything beyond that
we've been considering fair game to change. TLS 1.3's ServerHello is not
compatible with TLS 1.2's ServerHello. The first message may even not be
ServerHello and instead HelloRetryRequest.


On Wed, Jul 27, 2016 at 4:02 PM Sean Turner <> wrote:

> > On Jul 26, 2016, at 11:11, David Benjamin <> 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