>>> Eric Rescorla <e...@rtfm.com> 11/23/16 2:18 PM >>>
> In general, it should ignore it. It's going to become increasingly common to
> have this be a version you don't support given the recommendation to use
> 0301 and the ongoing deprecation of TLS 1.0. I think it would be fine to
> sanity
> check the major version, but I'm not sure what would be gained by requiring
> this.
The one benefit of checking at least the record's major version I see is that
one
preserves means for the future to signal a record format incompatible with the
current one. Otherwise, this field is given away for arbitrary and
non-standardized
(ab)use ...
Thanks and Cheers,
Andi
___________________________________
Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>> Benjamin Kaduk <bka...@akamai.com> 11/10/16 5:22 PM >>>
On 11/08/2016 06:25 PM, Martin Thomson wrote:
On 9 November 2016 at 05:59, Brian Smith <br...@briansmith.org>
wrote:
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.
If you permit someone to enforce it, then that is sufficient. I
don't
think that we should ever force someone to enforce these sorts of
things (as you say, sometimes strict enforcement isn't cheap or even
desirable).
Agreed. We should probably change the text a bit, though, as right
now readers can get two different readings depending on whether they go for
a strict decode_error (or illegal_parameter?) since the struct doesn't
match the definition, or follow the "MUST be ignored for all purposes".
-Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
