IETF Logo Mail Archive

Re: [TLS] draft-ietf-tls-tls13-16

Eric Rescorla <ekr@rtfm.com> Wed, 28 September 2016 17:15 UTC

Return-Path: <ekr@rtfm.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 CA86412B267 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 10:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 e1dxaQDJKNVa for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 10:15:36 -0700 (PDT)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 4F5C012B23D for <tls@ietf.org>; Wed, 28 Sep 2016 10:15:36 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id z8so8316442ybh.3 for <tls@ietf.org>; Wed, 28 Sep 2016 10:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t/k1n/upuojQtwTcdmbj+l9nK8KcaHs1vSltQsq7zVU=; b=wGeezbWeRaBHNjvstkGDv3rM2NR5ieDvN1iMgDrwWC8Mffo/rW7CgCpliz7sGpnUL6 dNzpdLyQPvIoSNwr7V8BeSzEgboy2+QOCMr6UJBQIM0o9lwNEn2NxFwwOrxSOPjazgtD 9oeDmT51vpbKD9NF7tcY/Ok6owTPAM8GHXXyFHtx197reD0kluA9GixmAER9Yg+KHCSF F99xs5S4QzM3sNj9D1FL4psinOWes+MZqZd72gmUXxPBeMWxBTRiWm+0NpXI2c4NGwXZ Eq7pjxQ4tFKyXYBdimj50g8tBZ625xDLLb4t4rCm4O0ubexfzYNY9MmnG42KPN+kQuPs zFVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t/k1n/upuojQtwTcdmbj+l9nK8KcaHs1vSltQsq7zVU=; b=R7ulWSSdfTfC+nodG3K0VlnruuPaIVSX0oFnB2yZF+xUODMLsu+MR1ajVfxJ/6mbSq JomsZ8sE+w7HTrq0NSQKCiSadBVzhghI1cSnrxQDmuTUhR0MEwaDDFHoWNSH2ma70rrz +hGkG9phbWADgu3b9Wp+ZClgLqRmCmrW4AGU2/JO1NQlhNWvI86lM9KVqVTMWWXQ5Cwg r+8wT/GLBBgutEqT7sN5SH/Pty2UDTNgpLaJA0ilh6gO25gwaTEAT5aPPQnEVuq8Rrqr iJ98PeXSARX18tnmaqznooZ4M+LCQpTe5Aejpl41sIeawnHpM2IgP8H6+f/c5nBxH6oK bt4g==
X-Gm-Message-State: AA6/9RnyCAE1t2lBzELKBaaiNa/VbYuHbYqqpPWWAxIBQr1yDSyTKPgmE211iANBmBQa27OTZQmhrrRTNT1obA==
X-Received: by 10.37.53.68 with SMTP id c65mr22178951yba.64.1475082935568; Wed, 28 Sep 2016 10:15:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.160.10 with HTTP; Wed, 28 Sep 2016 10:14:55 -0700 (PDT)
In-Reply-To: <153F73EF-492D-4DCC-9D76-62B0FE219F90@pahtak.org>
References: <CABcZeBOJBNt90XmWAcnpUSnXF1mLx4gdqWnvBRws-o5iO3njXA@mail.gmail.com> <660F59E7-5B9C-4E4D-B12F-EE03BAB333E4@pahtak.org> <7b4c8371a44e4c07be9883d2db959a64@usma1ex-dag1mb1.msg.corp.akamai.com> <153F73EF-492D-4DCC-9D76-62B0FE219F90@pahtak.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 28 Sep 2016 10:14:55 -0700
Message-ID: <CABcZeBOuuVx4gH64hWX=UDeOo-mvreLa5zFccGMGQFkzG9FPdg@mail.gmail.com>
To: Stephen Checkoway <s@pahtak.org>
Content-Type: multipart/alternative; boundary="001a114baee063b6d4053d948242"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/e-_3Y2BUE_E5WzPPQDUSjD0Ip3k>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13-16
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, 28 Sep 2016 17:15:39 -0000

I don't really agree that we shouldn't specify client order. We do that
everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one,
which is just a holdover from a less expressive negotiation mechanism.


-Ekr


On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway <s@pahtak.org> wrote:

>
> > On Sep 28, 2016, at 11:08 AM, Salz, Rich <rsalz@akamai.com> wrote:
> >
> >
> >> C.2 Negotiating with an older client says, "If the
> >>   "supported_versions" extension is present, the server MUST negotiate
> >>   the highest server-supported version found in that extension."
> >
> > I agree that an appendix is the wrong place to put this.  And that
> specifying the client order is pointless.
> >
> > But I disagree with this being a MUST.  There may be times when the
> server knows more than the client and will know that a lower version is
> more appropriate.  E.g., interfering middleboxes or regulatory regimes.
>
> Seems reasonable. How about making selection from the list (if the
> extension is present) a MUST and selecting the highest server-supported
> version is RECOMMENDED? Perhaps the second part is unnecessary.
>
> --
> Stephen Checkoway
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email