Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
>>> Eric Rescorla11/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 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 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
Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
On Wed, Nov 23, 2016 at 3:39 AM, Andreas Walzwrote: > Dear all, > > bringing up this thread again > > In the course of studying the way TLS implementations treat the "version" > (or "legacy_record_version") field in the record header, we were wondering > (please excuse if we missed some arguments here from past discussions): > > (1) What is an implementation (in particular when receiving the first > bytes over a new connection) supposed to do if the record's version field > signals a protocol version the implementation does not support? I > understand that, at this stage, enforcing a specific value (e.g. 0x0301 > according to the TLSv1.3 draft) is detrimental to interoperability. > However, if that field bears any meaning (in either TLSv1.3 or previous > versions), what is it? I would expect this field is supposed to allow > signaling a potentially non-backward compatible record format > (inauspiciously interfering with a receiver disregarding the record > version). Provided this field isn't treated as an enum, what about > checking/enforcing at least the major version as BoringSSL does (as far as > I know)? In any case, I would propose to be very clear about this in the > text (my sense was that there is some work in progress, but I couldn't find > anything). In implementations ( interpretations. > 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. > (2) What is an implementation (up to TLSv1.2, as the TLSv1.3 spec is > rather clear about that) supposed to use for the record's protocol version > field before a version has been agreed upon (e.g. when sending an alert > after receiving an unparsable ClientHello)? My best guess would be to set > it to the lowest (TLS) protocol version that uses the same record format > (probably 0x0301). However, we observe several servers which, in such > cases, answer with an alert with weird record protocol version values, e.g. > 0x.] > Yes, this seems like a reasonable procedure. Not sure how to tell TLS 1.2 impls what to do at this point, though. -Ekr > > 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 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 > 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
[TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]
Dear all, bringing up this thread again In the course of studying the way TLS implementations treat the "version" (or "legacy_record_version") field in the record header, we were wondering (please excuse if we missed some arguments here from past discussions): (1) What is an implementation (in particular when receiving the first bytes over a new connection) supposed to do if the record's version field signals a protocol version the implementation does not support? I understand that, at this stage, enforcing a specific value (e.g. 0x0301 according to the TLSv1.3 draft) is detrimental to interoperability. However, if that field bears any meaning (in either TLSv1.3 or previous versions), what is it? I would expect this field is supposed to allow signaling a potentially non-backward compatible record format (inauspiciously interfering with a receiver disregarding the record version). Provided this field isn't treated as an enum, what about checking/enforcing at least the major version as BoringSSL does (as far as I know)? In any case, I would propose to be very clear about this in the text (my sense was that there is some work in progress, but I couldn't find anything). In implementations (>> Benjamin Kaduk 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 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