Martin Thomson <martin.thom...@gmail.com> wrote:
> On 8 November 2016 at 14:01, Brian Smith <br...@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.
>
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/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
