Re: [TLS] (strict) decoding of legacy_record_version?

Eric Rescorla <ekr@rtfm.com> Tue, 08 November 2016 02:18 UTC

Return-Path: <ekr@rtfm.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 D4B66129604 for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 18:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 efUSC77ObkTU for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 18:18:09 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 43F941295A1 for <tls@ietf.org>; Mon, 7 Nov 2016 18:18:09 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id t125so162384124ywc.1 for <tls@ietf.org>; Mon, 07 Nov 2016 18:18:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p1zwyES1fGE5VRaFUUZpvxyZSFKNyYbs7Mo7Kp5xcqE=; b=abioCZ1atR/DsYG4XnlllvmDcreaWpaJZBqRfviKl0HfaGvt+ljjZUW1BMED8olmpo S6TsmdzTlI1r7wHp5pTAghptwlPWSThM/pRAyE5Xi4MGF2jDkGBOnA+QpYMCkcRR6PEv MsdOMMMfYxCpjQAfYpwbmQSctQ/5kd+pTY7TzMItwW/O+qWJD1oWZeicYK6WdNxOYrTU 5U0MyLuQfznbApM0AIo4qzkyEM9nEC8fK1bSBy7vyd97CEk2W463JP5IA35ndpKq8icH Zl28Cc7yG+baSkV8ACqL8zOuJbafgbv9GZ/gRy0m5BDenv2pvCzufmHGK0vnbDvFl1Up RlFg==
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=p1zwyES1fGE5VRaFUUZpvxyZSFKNyYbs7Mo7Kp5xcqE=; b=Wp2/Zrt9G/OI3Sko/i6t5JQce0SE/HOHht1Lfb24b4rGpbc6flSK4X8LdEpV2KiHcs TOYqPlgXAWrZeQgQgA3dKeeIuoIggo8JssYTGgOxKs+hY/sV5VZIzT+HBVEZIzNZI1N0 21PsX3yge7Bc0Ax5YamBGS//00r6lgUNxF2Lbp3EWPpv1RVL/fWf0WMcFXeIADs42jwp s5GwaPhewDZoi2MWq7OsrP5KgiUSqedYkFJRps8i0nj3+jmrysVShNazFDDRnYQXCtAA /VXgWQGH6Cj5gRHKZBsvhBJHT/JPHWuvGChurjiUiGcbjxT93Wnbqjju/nU0VoBH89cL tG3w==
X-Gm-Message-State: ABUngvfnd0A1uGomjNFo4qyhh5kfrNXADcofQb26Uhk3tVrjJtosJz3D2+JTB6zTTlq8WCEOyf7s0P/n3yI5+g==
X-Received: by 10.129.125.215 with SMTP id y206mr8621826ywc.234.1478571488561; Mon, 07 Nov 2016 18:18:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Mon, 7 Nov 2016 18:17:27 -0800 (PST)
In-Reply-To: <CAF8qwaC2oRqqHAeWRoGm24ZmDe0YAR6xgoA6NWNx59bV+dAOJw@mail.gmail.com>
References: <CABcZeBMeLgqjvr2cjWL=AHTQJbS9siNBB6U2=0654yigbBGkYA@mail.gmail.com> <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <CABcZeBOsN+_gUUb=HoUsoPOTBgANedT5Y5O+pAGXn0qTYjq1jg@mail.gmail.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <CABcZeBMg_QjHQf3b1mJcuDtCH1o2Gpv=YDdDPkAu5GwEhVaCfg@mail.gmail.com> <c83f4ada-f3e7-12f5-aedd-f41ff5e80665@akamai.com> <CAF8qwaC2oRqqHAeWRoGm24ZmDe0YAR6xgoA6NWNx59bV+dAOJw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 7 Nov 2016 18:17:27 -0800
Message-ID: <CABcZeBOwQqWMJwD=6XKvSoYCNVDbvCLbqrUhzJqMaEVRKPoQ3A@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=001a11492dfa5a1fbc0540c0c020
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oysVvwNffCQ8OaIxipwrllbywcg>
Cc: Matt Caswell <matt@openssl.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] (strict) decoding of legacy_record_version?
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: Tue, 08 Nov 2016 02:18:11 -0000

On Mon, Nov 7, 2016 at 4:04 PM, David Benjamin <davidben@chromium.org>;
wrote:

> On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk <bkaduk@akamai.com>; wrote:
>
> (was Re: [TLS] PR#625: Change alert requirements)
>
> Digging up an old sub-thread...
>
> On 09/20/2016 08:03 AM, Eric Rescorla wrote:
>
> in Record Layer there's the following text:
>
>     legacy_record_version : This value MUST be set to { 3, 1 } for all
>     records. This field is deprecated and MUST be ignored for all purposes.
>
> in Record Layer Protection there's the following text:
>
>     legacy_record_version : The legacy_record_version field is identical to
>     TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that
> the
>     handshake protocol including the ClientHello and ServerHello messages
>     authenticates the protocol version, so this value is redundant.
>
> which doesn't say if the version can be ignored completely (skipped while
> parsing) or if it should be verified.
>
>
> These are different fields.
>
>
> There's still the question of whether the receiver should enforce 0x0301
> in either/both cases.
> OpenSSL is implementing and seems to be reading the spec that it MUST be
> ignored (even though I guess strictly speaking that MUST only applies
> before record protection is engaged); if I'm doing my code survey
> correctly, Mint and NSS always enforce, and Boring only checks the first
> octet.
>
> Is there a reason to not do strict enforcement?
>
>
> Before you know the version, it is not safe to enforce. Prior versions of
> TLS did not pin down the value. (BoringSSL checks the first octet because
> OpenSSL did so, and it's vaguely nice to sanity-check on the first few
> bytes of data in the protocol.)
>
> Immediately after you know the version, enforcement is also problematic.
> Alerts sent in response to a ClientHello or ServerHello have somewhat
> ambiguous versions. One side may have decided the version is set while the
> other has not. Prior to 1.3, the record version needs to be set to the
> protocol version (or you break pre-1.3 enforcing implementations). But this
> means a receiver which enforces will fail to parse the alert. Not the end
> of the world, but weird.
>
> Once you've gotten as far as to switch to TLSCiphertext, I don't see a
> reason not to enforce. Keying on versions is problematic (which is why we
> avoided a transition to enforcement), but keying on whether the record is
> encrypted seems fine. I think it just didn't occur to us to base it on
> that. :-)
>

As you say, this is what NSS does. There's no legit reason for a TLS 1.3
encrypted record to have the wrong version number here, so I suggest
changing the text.

-Ekr


> David
>