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

David Benjamin <davidben@chromium.org> Tue, 08 November 2016 00:04 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 DBB75129A72 for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 16:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 (1024-bit key) header.d=chromium.org
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 x4IqRpRmkGD2 for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 16:04:22 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 E5EA0129620 for <tls@ietf.org>; Mon, 7 Nov 2016 16:04:21 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id u144so32421924wmu.1 for <tls@ietf.org>; Mon, 07 Nov 2016 16:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qAPQs6/j+1cxBfvwBcRMF+qFAtil3du4I5U/w2c3sRo=; b=Xyy1GLz/3DYz6jenCSkwEBOR32ZmWVtJ/OCEQB7IQ9XyXVPNlI7tt73aLc/8P6HrFS 54zqaELMcKWHyo6/IvrBiLTPeuT2xCBgVKYKOC9iKEOC4KZCd/mnYeekwdSqXqU+DMCT VVYQZTedJx7W01rDBCEM5u+3SgRa8Bsm67df4=
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=qAPQs6/j+1cxBfvwBcRMF+qFAtil3du4I5U/w2c3sRo=; b=ksIwkbNrnsf0UMqAyQb2gJPzsJC5inXfSHDtzTXAGwtMRWe1/mHwdUOz020BUt5NKH zme63YpM7N39mr6a0FTcrwIpgmUZyhue887a/+LPrGLh/U0u8VbArnNkz6u3J7pJsB2G qPq8MdNDQGKX6bNWYaUM7JeThvnnVjyRIm1JQjrAbOU6u6Qs97e+8HWs8X0W78eNOzCD XUHM272zGNZOOuycA48ezpUr8RZXJjH4hMXvf6ILSmIqrqiMehP0S0Q8f/eOFoVifasw dqyD8cXsqhn6xvd06VwmI9Trzb/nk8KVo94iQS3DhK1IFnuO4BNNHlDkxMuKB0HYXHUb G6xg==
X-Gm-Message-State: ABUngven5tBlvULTauXVaBzbtUH/61pdyNGcrhTgrzaXLdtdBFKu8nzFLz+Dbr+0pTGrQEQS8O8dkLps+VpQSCpz
X-Received: by 10.28.18.194 with SMTP id 185mr8260186wms.124.1478563460284; Mon, 07 Nov 2016 16:04:20 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <c83f4ada-f3e7-12f5-aedd-f41ff5e80665@akamai.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 08 Nov 2016 00:04:09 +0000
Message-ID: <CAF8qwaC2oRqqHAeWRoGm24ZmDe0YAR6xgoA6NWNx59bV+dAOJw@mail.gmail.com>
To: Benjamin Kaduk <bkaduk@akamai.com>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a11469f6ad462bc0540bee1f9
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/izWKNKVW1M1p_kZVj5PiJBac7-k>
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 00:04:24 -0000

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. :-)

David