Re: [TLS] supported_versions question

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 31 October 2016 18:57 UTC

Return-Path: <ilariliusvaara@welho.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 BEDBD129A11 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 11:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] 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 IeeQgNYHlXP4 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 11:57:28 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8675B129A0B for <tls@ietf.org>; Mon, 31 Oct 2016 11:57:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 51B9B1308B; Mon, 31 Oct 2016 20:57:26 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id jNQjXwnk94wV; Mon, 31 Oct 2016 20:57:26 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id F123127F; Mon, 31 Oct 2016 20:57:25 +0200 (EET)
Date: Mon, 31 Oct 2016 20:57:24 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Matt Caswell <frodo@baggins.org>
Message-ID: <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wTMb5ZdkTXInWjkpjeT1THGqa0I>
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 18:57:31 -0000

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.



-Ilari