Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

["Andreas Walz" <[e-mail]>]

>>> Eric Rescorla <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
 [e-mail]
 https://www.ietf.org/mailman/listinfo/tls