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
- [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Watson Ladd
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Andrei Popov
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements David Benjamin
- Re: [TLS] PR#625: Change alert requirements Timothy Jackson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Martin Rex
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Salz, Rich
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Hannes Tschofenig
- Re: [TLS] PR#625: Change alert requirements Benjamin Kaduk
- Re: [TLS] PR#625: Change alert requirements Martin Thomson
- Re: [TLS] PR#625: Change alert requirements Ilari Liusvaara
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Sean Turner
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- Re: [TLS] PR#625: Change alert requirements Hubert Kario
- Re: [TLS] PR#625: Change alert requirements Eric Rescorla
- [TLS] (strict) decoding of legacy_record_version? Benjamin Kaduk
- Re: [TLS] (strict) decoding of legacy_record_vers… David Benjamin
- Re: [TLS] (strict) decoding of legacy_record_vers… Eric Rescorla
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Brian Smith
- Re: [TLS] (strict) decoding of legacy_record_vers… Martin Thomson
- Re: [TLS] (strict) decoding of legacy_record_vers… Benjamin Kaduk
- [TLS] Treatment of (legacy_record_)version field … Andreas Walz
- Re: [TLS] Treatment of (legacy_record_)version fi… Eric Rescorla
- Re: [TLS] Treatment of (legacy_record_)version fi… Andreas Walz