Return-Path: 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 CFCFE129DAA for ; Tue, 8 Nov 2016 10:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.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 vy3xZwvK3lj7 for ; Tue, 8 Nov 2016 10:59:50 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 B6205129DA8 for ; Tue, 8 Nov 2016 10:59:16 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id u205so226610609itc.0 for ; Tue, 08 Nov 2016 10:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKS5tbJ+vVmsAOYxkd7OY56rAaV+tYRCH2Ig9XnN90c=; b=L46aMHbSDSkXauYAnwmShyRM+7GyboXoJmuG+1zPb9w46tsROehswse4lapSr8caTQ TCOU3G7xbdxvZygMQB+Vw6fgmFYWyP2kR3fyyP7Pd+XRc6hnbwbGkEYptsg/p/KleaNo +tJESdAkF+zeG4ZCSqO19c9gpLr9XSR0PHpza7Cxs50RsbSEf+dgTEV9Dx6JyjjRdTYp c0n3FNda0Qmzr3PX+0nRVSNl1t1pwh1jWhfoOSYKb+cfWsEU3I62OEkqrpeb6gFbwAz6 xuv6xozS4+hw9jDMIxSI95j96wWMPZ8SsZUcZlCdTcq/JL3xWcxXMPvS1MEiQyQotNd2 P6Jg== 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=IKS5tbJ+vVmsAOYxkd7OY56rAaV+tYRCH2Ig9XnN90c=; b=gau5NNBnQnwcgTyXPNJNb7Y8SQM0QqM5Qv30OR8LAJbBTbZJbaEaWWWBE7RyWBVMgp t6qLdCj30zzCCO7foYJCk/Hgz35lbG8o+GSd0Ak/NjwYKbyrLx/L/h+lS5xYcZ8UtkNT 6E0kItHKZMALSJgOG0wBwyzD9xuRmaVk9sCejDlVhqBxjpWzau4Z8j+HnPHyKwjMIGMn nNC2TL+QS+2+gi7hJuA8NJKJnfuvY94W9gr/J6g6ATEiyqTN916992n6HzyU97v2rxUV yK5yXyiNDHj1Tpd4t4P2SoUr3+KNm0GlmkCCwcF+0d3xLTxq8uQavIT11uvBc7m6hav6 BIlQ== X-Gm-Message-State: ABUngvcFXvUOZy9iqiWzTYYXIBGsT1xoYbl9zvXazCaUWV+02icsvuKy4tzHi5aot4aRsS8/Hf0zdtdElqqtmw== X-Received: by 10.107.1.138 with SMTP id 132mr13988797iob.72.1478631555955; Tue, 08 Nov 2016 10:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Tue, 8 Nov 2016 10:59:15 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Brian Smith Date: Tue, 8 Nov 2016 08:59:15 -1000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113965aea5ab810540cebc23 Archived-At: Cc: Matt Caswell , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 18:59:53 -0000 --001a113965aea5ab810540cebc23 Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > On 8 November 2016 at 14:01, Brian Smith 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. > Smuggling at the application layer would be more reliable for them, though. I'd say the goal of the check isn't to prevent all possible smuggling; rather it's part of a solution to it. Anyway, this is the only convincing rationale I see for requiring ("MUST") vs allowing ("MAY") the checking. > 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. > This isn't a pervasively shared goal, though. It's good to let the browsers police things if they want, but I think a lot of implementations would prefer to avoid doing work that isn't necessary for interop or security. Cheers, Brian -- https://briansmith.org/ --001a113965aea5ab810540cebc23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 8 November 2016 at 14:01, Bri= an 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 ca= n use this
> to transport up to 2 bytes of information hop-to-hop if the receiver d= oesn'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 re= ason,
> the reasoning should be explicitly called out because it is non-obviou= s.

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

Smu= ggling at the application layer would be more reliable for them, though. I&= #39;d say the goal of the check isn't to prevent all possible smuggling= ; rather it's part of a solution to it. Anyway, this is the only convin= cing rationale I see for requiring ("MUST") vs allowing ("MA= Y") the checking.

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

This isn't a pe= rvasively shared goal, though. It's good to let the browsers police thi= ngs if they want, but I think a lot of implementations would prefer to avoi= d doing work that isn't necessary for interop or security.

=
Brian
--
--001a113965aea5ab810540cebc23--