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

[Brian Smith <[e-mail]>]

Martin Thomson <[e-mail]> wrote:

> On 8 November 2016 at 14:01, Brian Smith <[e-mail]> 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/