Re: [TLS] supported_versions question

Matt Caswell <frodo@baggins.org> Mon, 31 October 2016 23:49 UTC

Return-Path: <frodo@baggins.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 9DE8F129BE8 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
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 gqx6_aWty9Yt for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:49:36 -0700 (PDT)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C804B129BE7 for <tls@ietf.org>; Mon, 31 Oct 2016 16:49:35 -0700 (PDT)
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 144E9AF9 for <tls@ietf.org>; Mon, 31 Oct 2016 23:49:33 +0000 (GMT)
Received: by mail-qk0-f180.google.com with SMTP id q130so61872621qke.1 for <tls@ietf.org>; Mon, 31 Oct 2016 16:49:33 -0700 (PDT)
X-Gm-Message-State: ABUngvde3YA6rvaDzeE3BYghVen8VVGU5l6jXUq8HxWs8i7WiT0PlqpZPTaEQRJpZqwnKejvFL7gpVon6YzMIQ==
X-Received: by 10.55.177.5 with SMTP id a5mr17859682qkf.153.1477957772651; Mon, 31 Oct 2016 16:49:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.34.61 with HTTP; Mon, 31 Oct 2016 16:49:31 -0700 (PDT)
In-Reply-To: <CABcZeBPjye1RZZKXNB9mkeJ_uFc2QxyW3bX80NDK6uAn2x50qg@mail.gmail.com>
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> <CAF8qwaAEfa2V4g+fqG0we+cer5PPrgA3jLQZbJfvq5dKTvs_-A@mail.gmail.com> <CABcZeBPjye1RZZKXNB9mkeJ_uFc2QxyW3bX80NDK6uAn2x50qg@mail.gmail.com>
From: Matt Caswell <frodo@baggins.org>
Date: Mon, 31 Oct 2016 23:49:31 +0000
X-Gmail-Original-Message-ID: <CAMoSCWZn=i0KKhQjC6VrfA_nYA5dpfQifW6NYZtMw1t7FzgReQ@mail.gmail.com>
Message-ID: <CAMoSCWZn=i0KKhQjC6VrfA_nYA5dpfQifW6NYZtMw1t7FzgReQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UDvGY0BEEhCYd21gRdH6sgF6jOk>
Cc: "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, 31 Oct 2016 23:49:37 -0000

On 31 October 2016 at 23:35, Eric Rescorla <ekr@rtfm.com> wrote:
> Our current implementation also processes the extension unconditionally.
>
> I'm not convinced that this represents an improvement, both for the reason
> that Kurt
> indicates and just in terms of simplicity of story. The current design is
> simply
> "if supported_versions is present, then use it", whereas trying to clip it
> on 1.2
> is inherently more complicated. I'm not particularly bothered by the anomaly
> that David mentions between legacy_version and supported_versions,
> especially
> given that we're perfectly happy to tolerate deviation the other way.

My biggest concern is that there are a number of corner cases here
where it is unclear what to do because the current wording doesn't
specify it (see my original questions at the start of this thread).
Like, I said earlier, it could be made to work If retaining <TLS1.2 in
supported_versions is desirable, but in that case we need to specify
how we should treat legacy_version and what to do if it isn't 0x0303 -
and in the RSA key exchange case which client_version are we using?

Matt

>
> -Ekr
>
>
> On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin <davidben@chromium.org>
> wrote:
>>
>> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <kurt@roeckx.be> wrote:
>>>
>>> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
>>> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
>>> > <ilariliusvaara@welho.com>
>>> > wrote:
>>> >
>>> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote:
>>> > > > A few supported_versions questions:
>>> > > >
>>> > > > 1) What should a server do if supported_versions is received but
>>> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
>>> > > > ignore legacy_version?
>>> > >
>>> > > If legacy_version > TLS1.2, the spec requires server to ignore
>>> > > legacy_version.
>>> > >
>>> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
>>> > > ignoring legacy_version is reasonable in this case too.
>>> > >
>>> > > > 2) What should a server do if supported_versions is received,
>>> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
>>> > > > not
>>> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
>>> > > > the
>>> > > > handshake, use the legacy_version, or use use the versions in
>>> > > > supported_versions?
>>> > >
>>> > > There's also the case where supported_versions has TLS 1.1 and TLS
>>> > > 1.4,
>>> > > the latter the server has never heard about...
>>> > >
>>> > > > 3) If the answer to (2) above is ignore the legacy_version, and
>>> > > > just
>>> > > > use the versions in supported_versions, which client_version should
>>> > > > be
>>> > > > used in the RSA pre-master secret calculation? The one in
>>> > > > legacy_version, or the highest one in supported_versions?
>>> > > > Presumably
>>> > > > it has to be the one in legacy_version, otherwise thing will fail
>>> > > > when
>>> > > > the client talks to a server that doesn't understand
>>> > > > supported_versions?
>>> > >
>>> > > Yeah, I presume putting the version in legacy_version is the only
>>> > > sane
>>> > > thing to do. But causes other problems with downgrade protection.
>>> > >
>>> > > OTOH, RSA key exchange is known to be very broken and is affected by
>>> > > all kinds of downgrade (and other) attacks. So if one wants actual
>>> > > security, it needs to be removed.
>>> > >
>>> >
>>> > We could say the versions extension only applies to 1.2 and up. I.e.
>>> > don't
>>> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
>>> > 1.0
>>> > when they see them in the version list. That keeps the protocol
>>> > deployable
>>> > on the Internet as it exists, avoids having to evaluate too versioning
>>> > schemes (if you see the extension, you don't bother reading
>>> > legacy_version
>>> > at all), while avoiding the weird behavior where, given this
>>> > ClientHello:
>>> >
>>> >    legacy_version: TLS 1.2
>>> >    supported_versions: {TLS 1.1}
>>> >
>>> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS
>>> > 1.2.
>>>
>>> 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.
>>
>>
>> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
>> disables versions must then gate supported_version handling on whether TLS
>> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
>> gnarliness.
>>
>> (Our current implementation just processes the extension uncondtionally,
>> but we'll also happily negotiate old versions out of it.)
>>
>> David
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>