Re: [TLS] supported_versions question

David Benjamin <davidben@google.com> Mon, 31 October 2016 19:11 UTC

Return-Path: <davidben@google.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 65D69129A3D for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 12:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Y-QIsV6b5mMc for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 12:11:27 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 628C1129A4E for <tls@ietf.org>; Mon, 31 Oct 2016 12:11:22 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id h14so153199051ywa.2 for <tls@ietf.org>; Mon, 31 Oct 2016 12:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKLX6T/NpbyoFFIyphKH1Gt8Jzc5IkoriuFDB7jF+w8=; b=S1/yeJ5LhvxgIHZ4Ye9accWQ5TijIGeKNqwJ9ciF+fgWJ4uUNHZQCfNnbOcTll/Z6e ikO69zooKdyjyYc2lTjlJdtRgacoz0W+m5J6pGJmNsQBB5DRuTqAGR4/jpFg44STFhKu 1+ai9Hwr7ogLgIrsZDkRxTHKC3gjwb0yjDJi6hSUxhH8llmSAJsRFXfIXVlZd2v+KGDS h/r9gOrgm4XD3PYbHGBkhFyqqdgZAw/kGuAHHAsWdMbC2ed3DuAOGG+Mf+tzpZ6l4IPO 8mNvGQnJFnRUmsUfty4urWzrG2bXKMDYO8IFpe+c6Q0In0lL4q1j2+D5PTVTe8/IkaWv yiJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKLX6T/NpbyoFFIyphKH1Gt8Jzc5IkoriuFDB7jF+w8=; b=C2FjHd09l2mUandmM8Xfle95QoSA/ym6i0IYcpSHlmak341PuFKTIoY5KZ6LQfp0Mq aC6QZo5RrCKnPFzo74bsGsXsBHMJO2EEHPaspI0XE2/4SkULxuO3FS2rUba44FdRDE3a zNdX9FuqO7uoDrtJ9tjXYTY7xEcPQ9uXpiBVkttLY2sP0oJ97Dd9/Py0R6tkqCcmvxwr 2mWCtKjgzXzmnCn7jPCEWzM5cEaExpxjIK7o5xl+GGkQTIC7DKEoZbndRdkRqbc/WXkA Tk1r2KnWQSlmeMsHyBQX8me8gQS5J3jIQna4bZee8Owt0+KFdB1Oso7i+wB1ZXrtuLxp G9yA==
X-Gm-Message-State: ABUngveqffOregm6OCUjMBqnaMmftalofXc7IWo9lkyD0B1HBVif6xL4/6uBp0Bg07WIhN9HPZ6U+Ce+d1zeBmJV
X-Received: by 10.36.105.5 with SMTP id e5mr9895399itc.75.1477941081490; Mon, 31 Oct 2016 12:11:21 -0700 (PDT)
MIME-Version: 1.0
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin <davidben@google.com>
Date: Mon, 31 Oct 2016 19:11:10 +0000
Message-ID: <CAF8qwaCe89epMMzCA0BNfXWss9FWpDze8ScydufdoTNTNqmW1g@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Matt Caswell <frodo@baggins.org>
Content-Type: multipart/alternative; boundary="001a11445d5e298b6805402df9e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bFzXp58LNuh_lc-WSNc0kOETX7M>
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 19:11:29 -0000

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.

David