Re: [TLS] Supported Versions extension

Brian Smith <brian@briansmith.org> Mon, 17 October 2016 22:49 UTC

Return-Path: <brian@briansmith.org>
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 0B8FA12957C for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 15:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 F4lUa5J5fmtY for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 15:49:31 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 820DE1297C6 for <tls@ietf.org>; Mon, 17 Oct 2016 15:49:31 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id e187so16214193itc.1 for <tls@ietf.org>; Mon, 17 Oct 2016 15:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NVa8D/7zQuZdn3MxHRsUw11m6lnJWQ0135QTeqssND8=; b=IEu9YsTWl2Bajw8yjLbQzgXOa6A7Q4eq/ir8zTsTm33dv6vgn1BQJu+gyRvF8m7N88 Q1MMQ5im2N60CuODJBT0H9MiJPTh1qrH5szzL8clODOM52+08Lt40CMeqBuL9zdj5+6s Zbc1dV6RhcMeoM7LmByIbQI04Y7E1RWsmCpH6xO5uKYwQkQ9e7bKnKYyQ/Lq8pzW5L45 QZFmjJYuENxARhsKNlNWL7LPqANGnwEUnW0BgKbvGx40p45VwnkSdspexr49RFgxO37X gDRXGpgptbW+BiQXAOuYV7vIdpAs4uf2oK9oKRvAjxtOmduD+WQM23DSY4hSr2lfZEwX 3JIQ==
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=NVa8D/7zQuZdn3MxHRsUw11m6lnJWQ0135QTeqssND8=; b=FgsNYnuR67pN6j+Co1hKVilaQo/S3QBVOOmhcw+tJc9Dp4eDVgEYpbYVb5Ckx9oxZU 7+CC0Pf4+GxSm55NAj80skEBAYu95DTzdfFf2djVaruoEYVST0gM6HuDs6H0cz0W6d6R XIYPrJLkr5Zi7i2qfzvQ8IwLdTf2Y7LSCvyIXGWRz6pStrqH6OgqKSbVk/mE6S8Aedwm BUoMOCYymqULzz4YCjJgiq9KB5or1FgdKg2ZLpgSrjErAhrfUcalKJQ1DN4sHCxwLpKz jcLrdUXwmzP1K6r0jL0uyThId8Es6Mj7FaMFFigEnO5TvkPBgf3uz76slAcv6rKvuHtU LlYA==
X-Gm-Message-State: AA6/9RmO/GZFFRnCEONQiScU1meqrVJshvE4trsw7hsWOCL2OJaVyBmLQbmGKA3tqqhgyvvGGe+nSJlDkf0ToA==
X-Received: by 10.36.29.14 with SMTP id 14mr10714833itj.117.1476744570843; Mon, 17 Oct 2016 15:49:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.85.83 with HTTP; Mon, 17 Oct 2016 15:49:30 -0700 (PDT)
In-Reply-To: <CABcZeBPr7=+JyowSojmeW9nB=U1NR7FsXavXsy_kY3B8mMKrPQ@mail.gmail.com>
References: <1536297.j5uQUWNHeS@pintsize.usersys.redhat.com> <CAFewVt6_6PK09DjTQZnU5eKLVgJG7o8e7wDheANBQU4ms-Oe7w@mail.gmail.com> <20161017203741.GA26847@LK-Perkele-V2.elisa-laajakaista.fi> <CAFewVt6dJ1vgn8411jx3ftC9Z5Sgs_rB0F==WLNv_=ZVf6DLRw@mail.gmail.com> <CABcZeBPr7=+JyowSojmeW9nB=U1NR7FsXavXsy_kY3B8mMKrPQ@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
Date: Mon, 17 Oct 2016 12:49:30 -1000
Message-ID: <CAFewVt7CkFPq7x0yQCNknuJKdwwYhFbSZyyVVbT9w72HeELqSg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1143ed6291f5a8053f176326"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fHDsaKWRWMSqyPyL5Fy1eViqxS8>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Supported Versions extension
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: Mon, 17 Oct 2016 22:49:33 -0000

Eric Rescorla <ekr@rtfm.com> wrote:

> Brian Smith <brian@briansmith.org> wrote:
>
>> Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>>
>>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when
>>> there
>>> are higher versions supported, but not overlapping).
>>>
>>
>> Could you provide a concrete example, please?
>>
>
> When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and
> TLS 1.3 draft-17.
>

>
I would prefer to stick with the current design where if supported_versions
> exists it is the sole mechanism for negotiation.
>

Note that in my suggestion, supported_versions is the sole mechanism for
negotiation as well. With my suggestion, in your example where two
different TLS 1.3 drafts are supported, by each end, the server will see
that no supported draft of TLS 1.3 is supported and then negotiate TLS 1.2
if it supports TLS 1.2; otherwise it would give up. It can make this
decision purely based on the contents of the supported_versions extension.
Then if the client supports TLS 1.2 it will continue; otherwise it will
abort. So there doesn't seem to be a significant benefit to advertising TLS
1.2 support in the extension.

Especially since TLS 1.2 is a superset of TLS 1.1 and TLS 1.0, I don't
think there's any need for  TLS 1.0 or TLS 1.1 to be mentioned in the
extension at all, even if the client supports them, because a server that
supports this extension shouldn't ever negotiate TLS 1.0 or TLS 1.1.
Imagine that we wanted to support clients that support TLS 1.0 and/or TLS
1.1, not TLS 1.2, but TLS 1.3, for some reason. Then we'd need to allow the
legacy_version field to be TLS 1.1 or TLS 1.0. But, I don't think it's
useful to support this.

Cheers,
Brian