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
>