IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 08 November 2016 03:53 UTC

Return-Path: <martin.thomson@gmail.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 AC35F1296EF for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 19:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ip5xdMQltdac for <tls@ietfa.amsl.com>; Mon, 7 Nov 2016 19:53:12 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 632B012967C for <tls@ietf.org>; Mon, 7 Nov 2016 19:53:12 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id q130so202898803qke.1 for <tls@ietf.org>; Mon, 07 Nov 2016 19:53:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NkqOOw5L+dbPaJYEwYLDhyPmSj9F/N7jLwdB/djV57k=; b=LKZJCB+zMEr2GcOQ6bznrCNdi4bBOSal8aDdpLzGphlEZB+rCvU/NTkhiw6WWLLXhX cdp/4sSSBQ+W0sQ4tN8AssnKhuDFQK0bNJGEEhiX2Ss6wMnRbZK5ZYsUOvUH2PZTECa1 TdJiUao2TLQKhxCtgjQAd4AX6zsVBDoc3s3mkmuaIiEsYo1mYhhwUrGdSN0FA6LVg48A EWc6jvJeVtxm2Z/DGcq2W2cj5VqbUcLSmmEQ1Dv5eIKcJdaOM+/coyVgAUNLMpliPcD8 6kLHi20Vt1vHkh4mTULkbn8C6wLvMsqxm2Ju3zA0DbIAo2WbumJAI9k/rdduJfzBqzn/ Wtfw==
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=NkqOOw5L+dbPaJYEwYLDhyPmSj9F/N7jLwdB/djV57k=; b=LRFqFVqzitNQZTT20f9pMWEqWSWF+biVJKcu35bOm4fGMHsOgGMCQv6oBJhWOrpMIf sQPszE/3KwFUkzg/4xDI4eCfFAZUznyjh5oALggH4PjM23fsZF/PE1ZQB2fL2U6YnJOY 8xB4PShNUVOPyzReLc+T+sTyECENOOnOX6cFf4uEyaD/dQvBpHJQLd+xltO/8JScuohp 8ysPQDCudzjklowdS7LYMtaZ0UFphd1ytd/hfYaFqtV+M5bKC8hS63anPeTL0xaf/cW1 oG1wSOylA0OyCP31iRKZsgtDOpiSaGjfNoBJ+XdP67Nuoy082Jq/XjzoR42CDRTDS8m+ vp2Q==
X-Gm-Message-State: ABUngvdr8i3KRGFZpiR8cTHy2wyxMVJcis1NLViRbgLEiDnReCmVKATEj4UAf0doEc5yyHr+GlVNMmDkqkyIKg==
X-Received: by 10.55.184.68 with SMTP id i65mr10910313qkf.5.1478577191625; Mon, 07 Nov 2016 19:53:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 19:53:11 -0800 (PST)
In-Reply-To: <CAFewVt7oBausHM9E83nvzOh1DRCB4f4d92t2X8EmN-CzFU41OQ@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> <CAFewVt7oBausHM9E83nvzOh1DRCB4f4d92t2X8EmN-CzFU41OQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 08 Nov 2016 14:53:11 +1100
Message-ID: <CABkgnnXgOJBThg66ZzXSk4vFqL8XKK3w0KGWZci=vWiLXoQ9Hw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kZKJQMbcg4glrP1sfzHiAhZ_Pyg>
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 03:53:14 -0000

On 8 November 2016 at 14:01, Brian Smith <brian@briansmith.org> wrote:
> Since this field isn't included in the additional_data of the AEAD in TLS
> 1.3 any more, it isn't authenticated. That means an active MitM can use this
> to transport up to 2 bytes of information hop-to-hop if the receiver doesn't
> check it. That seems like a good reason to check it, and also to check
> TLSCiphertext.opaque_type is application_data. Assuming this is the reason,
> the reasoning should be explicitly called out because it is non-obvious.

I don't think that's the primary reason.  A MitM could use TCP headers
to carry other bits if they wanted.

The main reason I can think of is ecosystem health.  If you permit
junk, then you get junk.  Then you can't use the field any more
because it contains junk.

v2.23.0 | Report a Bug | By Email