> Pushed to the extreme, the result is a sort of protocol drift, in which buggy > variants get first tolerated, and then accepted as de-facto standards. Indeed, we're seeing several instances of this protocol drift in TLS 1.3 (2.0? 4.0?), e.g. the relaxed rules around the signature_algorithms extension and the version negotiation workaround that just got adopted...
Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Friday, September 23, 2016 5:52 PM To: 'Peter Gutmann' <pgut...@cs.auckland.ac.nz>; 'Andreas Walz' <andreas.w...@hs-offenburg.de> Cc: tls@ietf.org Subject: Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations On Friday, September 23, 2016 1:39 AM, Peter Gutmann wrote: > Andreas Walz <andreas.w...@hs-offenburg.de> writes: > >>However, where would you draw the line between "I can't" and "I don't >>want to"? > > It's one of those judgement-call things, I don't know if you can > strictly define it but as a rule of thumb I'd say that if you > encounter it during normal processing it's an I-can't problem while if > you have to add special- > case checks to identify it and refuse to continue it's an > I-don't-want-to problem. Yes of course, but there is another aspect to it, the general health of the ecosystem. Postel's rule is nice, but it removes the pressure on broken implementations to fix their code. Pushed to the extreme, the result is a sort of protocol drift, in which buggy variants get first tolerated, and then accepted as de-facto standards. This tends to hinder future evolutions, not to mention adding complexity. We often hear that "the IETF has no protocol police," but in fact it does. Each implementation that takes a strict view of standard compliance contributes to this policing. -- Christian Huitema _______________________________________________ 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
