Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity
Eric Rescorla <ekr@rtfm.com> Sat, 03 March 2018 00:42 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 02A7A126CC4 for <tls@ietfa.amsl.com>; Fri, 2 Mar 2018 16:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] 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 gMGIwrv74thM for <tls@ietfa.amsl.com>; Fri, 2 Mar 2018 16:42:03 -0800 (PST)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 DD567126C26 for <tls@ietf.org>; Fri, 2 Mar 2018 16:42:02 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id w142so14197464qkb.8 for <tls@ietf.org>; Fri, 02 Mar 2018 16:42:02 -0800 (PST)
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=gQb/iohVRAYr0+ye6hwLCqi73hSWTfqd0uDslETCBI8=; b=pYi3Zvsyi4yHjUYopoLv1Knh73gbnVlth4wgYwzZf19vnabB0HFA04hIFqpCx+Rj9N Mj09uX5nv6yNhlpePD7+Gforb5JDtsjkrvnBrWWoO4uj3ybhjxbfBuay5DgS1ZFimSCS 0+khPjIRuCeW04wL13JIYCKe7TukEJJM7grSgI4Nuk/JHCEKb0HWUw5bM3h+r8NUpYhe s/7rD4hSpBiiwPoaXNb6n1QYvoh4UXSXWkjgalJWY9zQOrdvRs/7t7Cm680ei+gPFzoc KaCtD8srYjmXDFZhYAnDzYIaUQeLEJuE1CbCYoEwcykpLvScvcUBMRHMwxm31gGnYvZ0 qLPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gQb/iohVRAYr0+ye6hwLCqi73hSWTfqd0uDslETCBI8=; b=LUidKCKCg4OjrVjJ4mh9nJ77f4tjyafF/TVIk08RjDnLGITbBSI/eDKRcINQR4iZXP 8By2V9oMP7hf6Jfqz7NYmFZlC8nI+qGIYCpFv68ZUst5pZdNa9i6OuIg1sqYoU04QHEG sWSFL+gDHibhdTWlRkq05crBXDOTJZpaf4DS7SLFOMPUXnp/L0EHpEVkuFOCc0fGIIG8 8w0pjcNklF7bWnNVt8TF6sATh7L5fSn+JDwpwYogbZ8T4bmVRyJznwfwuE8oLO8xMx6V Wrng81WaM1EL7cwGctES07IbK3toTpj+Oo1i87qx2hb5nx9ClSUrb1Ui0L2bR09RvDet HYkg==
X-Gm-Message-State: AElRT7GQn64M8k0W9SsSyg3xDRwH59rjjxE5YHQgUDQxqci0Svg87LDs yTNYN+K2v0vO9qHImiNV4YNTFxeffNA9wIZbgNPzVA==
X-Google-Smtp-Source: AG47ELt6h6wxe7hTaodffDCVN0Smlw/v5F2y0g7gYrIVpLNvruzlO0v0UuoB5rdkbWcI8Ji5fXmuJRdExl8JO0SA1LQ=
X-Received: by 10.55.195.145 with SMTP id r17mr11098079qkl.83.1520037721878; Fri, 02 Mar 2018 16:42:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Fri, 2 Mar 2018 16:41:21 -0800 (PST)
In-Reply-To: <1519978911.514.6.camel@redhat.com>
References: <9233569e-fc21-e6dd-b84c-6a98e29a4f02@nist.gov> <1519978911.514.6.camel@redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 02 Mar 2018 16:41:21 -0800
Message-ID: <CABcZeBOSMDG0q4OtUKcZfPENrG7A8Y3cgc8buc2hATW40nTLNw@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: "David A. Cooper" <david.cooper@nist.gov>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1147a3247583320566775c94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/S-slz9IOAqx9fzzve2xoLUOSlT4>
Subject: Re: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 03 Mar 2018 00:42:05 -0000
On Fri, Mar 2, 2018 at 12:21 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote: > On Thu, 2018-03-01 at 10:49 -0500, David A. Cooper wrote: > > > > I believe you are misinterpreting the text, but agree that it could > > be > > made more clear. > > > > Suppose that the ClientHello includes a supported_versions > > extensions > > that contains two values, TLS 1.4 and TLS 1.0, and the server > > supports > > TLS 1.3 and below. My interpretation of the current draft is that > > the > > server MUST use the supported_versions extension to determine the > > client's preference, but then once deciding to use TLS 1.0 for the > > connection sends a normal TLS 1.0 ServerHello, with version field set > > to > > 0x0300 and no supported_versions extension. Note that Section 4.2.1 > > says > > that > > > > A server which negotiates TLS 1.3 MUST respond by sending a > > "supported_versions" extension containing the selected version > > value (0x0304). > > > > It says nothing about a server that negotiates an earlier version. > > > > If my understanding is correct, then I believe the text in Section > > 4.1.3 > > could be made more clear. Draft -21 said that the version field of > > ServerHello "contains the version of TLS negotiated for this > > connection." (this is similar to what RFC 5246 said). The current > > draft > > says: > > > > In TLS 1.3, the TLS server indicates its version using the > > "supported_versions" extension (Section 4.2.1), and the > > legacy_version field MUST be set to 0x0303, which is the > > version number for TLS 1.2. > > > > To be consistent with RFC 5246 and earlier, it seems like the text > > should say something like: > > > > For a TLS 1.3 ServerHello the TLS server indicates its version > > using the "supported_versions" extension (Section 4.2.1), and > > the legacy_version field MUST be set to 0x0303, which is the > > version number for TLS 1.2. For a TLS 1.2 and earlier > > ServerHello > > the legacy_version field contains the version of TLS > > negotiated > > for this connection. > > I understand that this is an interpretation that makes more sense and > aligns with the -21 behavior, but I do not think that this is what this > text literally says. Both Eric in his previous email and another > engineer I've discussed the issue seem to agree that the intention is > to use the new mechanism for all negotiations. You disagree on that, > and it thus apparent that this text needs clarification. > I don't think that's what I meant. I agree with David that if you send ServerHello.supported_versions it ought not to contain TLS 1.2 or below. I missed this in -25, but I have a PR up for it now, so if this looks OK, I'll merge and spin -26. See: https://github.com/tlswg/tls13-spec/pull/1163 -Ekr > The text was written for -21 version which didn't have the server-side > part of the extension, and the flow was natural for pre-TLS1.3 > versions. When the change was done in -22 to include the server-side of > the extension, this ambiguity (in your view) and complicated side- > effect (in my view) was introduced. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] draft-ietf-tls-tls13-24 supported_versions … Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… David A. Cooper
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… David Benjamin
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… Yuhong Bao
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… Eric Rescorla
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… Nikos Mavrogiannopoulos
- Re: [TLS] draft-ietf-tls-tls13-24 supported_versi… Eric Rescorla