Re: [TLS] supported_versions question

Brian Smith <brian@briansmith.org> Mon, 07 November 2016 22:02 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 6BD9B1299B5 for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 14:02:37 -0800 (PST)
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 zB9gT2HyVG40 for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 14:02:36 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D22DB1299B2 for <tls@ietf.org>; Mon, 7 Nov 2016 14:02:35 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id q124so52580294itd.1 for <tls@ietf.org>; Mon, 07 Nov 2016 14:02:35 -0800 (PST)
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=jUrlhw2xCwxJICxBW3Bjxal9ZwgoVaS1J5CZFCYB6ck=; b=Vk9GYU1Q8cXDQoaVKTHidfb9BWJljv4SINrApbxQGF7aIEXG68uGL8JoWLHSX57WrI Ua2M0CWEBrc0+yDo7SJjyoUOmwo/4xxQ9BezHB0RXZee9HC1IGoC24WYwUChLHTdEcEy 8dAxfXdaQElv5CK3aQA2562CzVBHJbJufhiz8D1NYNijJC95DIaKjLq+LxCnChfqB3TO MG3T6AliyKiqiVgjhhwgyDhj1nQIf2f5VNrKbS4jMAn5BXZxtKKXQl4Z1F9O+i9Volrc mKMJWS9MuIxWAtG8UU/7VTRtqAW2hRKHV3KhyILhaWxe4Whvi/8AvLaCDnFg0z3kr27D aznw==
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=jUrlhw2xCwxJICxBW3Bjxal9ZwgoVaS1J5CZFCYB6ck=; b=aeQqyFhPZq4UqmXjTRahbDJcYU2T0Ml9hyVssxCdrABhdFJwK9GNbrpAw9ZXSg1qht vKyld1DPlK2hOY1Rbv1GDtk4txnxnBinJ+3pSqu0JvJlzVVU4rRMN3sKu/CXXqwJbW7N jiWvUsdpQEphxyFaDZEsrZgp/t1GkeyEnBe1kMNaRzCAhDKACJABTVvyb7lxdQ25xJuz WMeQ2QHTReSzD6wArFFb7God2eGiArVw8TQhYuU7LrvYOnnOWMZnCTBqV++HTwjmU/9Z GEcV2miSulp+zsfJQ71me0QSXfheBK390T0JQrl/ghTptqC46D1R/O7gppFQzsLRBnEy J4ZA==
X-Gm-Message-State: ABUngveKqNL0FpoFbHP/nfr5YJftlTvNgounNYoZ/AUGgEUK7iWOsK6sPIKreMiwrFcq6Hxq3RNpH3j8QAKlSg==
X-Received: by 10.36.52.129 with SMTP id z123mr6305576itz.117.1478556155253; Mon, 07 Nov 2016 14:02:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.85.83 with HTTP; Mon, 7 Nov 2016 14:02:34 -0800 (PST)
In-Reply-To: <20161031223431.6j23de5gyqx6vpop@roeckx.be>
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCe89epMMzCA0BNfXWss9FWpDze8ScydufdoTNTNqmW1g@mail.gmail.com> <20161031223431.6j23de5gyqx6vpop@roeckx.be>
From: Brian Smith <brian@briansmith.org>
Date: Mon, 07 Nov 2016 12:02:34 -1000
Message-ID: <CAFewVt77Vr-Yd-TCqvAZ6933MM=6wnPYvEZVPchBnFF7mvZL1w@mail.gmail.com>
To: Kurt Roeckx <kurt@roeckx.be>
Content-Type: multipart/alternative; boundary="001a113ad1506a23ab0540bd2eaf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/flqGlPbnLpbgwug6K4gOzOM0l-g>
Cc: David Benjamin <davidben@google.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] supported_versions question
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, 07 Nov 2016 22:02:37 -0000

Kurt Roeckx <kurt@roeckx.be> wrote:

> So I guess you're also saying that a server that implements TLS
> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> ignore the supported_versions even when it knows about it?
>
> I guess I have same questions but with only TLS 1.3 disabled, to
> be sure when we need to look at it.


>From the perspective of the application developer, if I've disabled TLS 1.3
then I'd rather not  have any TLS 1.3 behavior implemented; I'd rather have
the implementation behave the same as before it supported TLS 1.2,
more-or-less. That means in particular that supported_versions should be
ignored if TLS 1.3 and later have been disabled. Put another way, if TLS
1.2 is the maximum version the application has enabled, then the TLS 1.3
specification in total is irrelevant and only RFC 5246 (and perhaps
earlier) apply, and those specifications don't specify supported_versions.

Consider in particular that an application might want to disable (or avoid
enabling) TLS 1.3 to avoid some problem (perhaps a security problem) with
supported_versions processing. It would be bad to not have any way of
disabling supported_versions processing, and it doesn't seem good from a
usability standpoint to have a separate nob to control it.

Cheers,
Brian
-- 
https://briansmith.org/