On 13 July 2016 at 13:22, Dave Garrett <davemgarr...@gmail.com> wrote: > I am aware that discussion ended up on accepting sloppy error reporting as > acceptable. Changing the disputed missing_extension alerts to SHOULDs would > be an acceptable compromise if that decision is still actually going through.
"sloppy" is a bit of a mischaracterization. There are good reasons for this decision. It allows implementations to be structured differently. In particular, if there are two relevant error conditions, different implementations could discover them in different orders. MUST-strength requirements on alerting for one of those conditions means that you have to order your checking in a particular way; MUST-strength requirements on multiple concurrent conditions are basically impossible to meet. It also allows an implementation to decide that abrupt cessation of communications is preferable to generating a report. That can be important for DoS mitigation. In the end, we concluded that you shouldn't lie about error conditions; if you determine that there is a missing extension and you decide to send an alert, then it has to be the missing_extension alert. David's PR goes to the core of the first of my reasons here. The ways in which servers decide on the things like version and cipher suite when presented with a ClientHello is in practice hugely different between implementations. That's healthy, but it does mean that we need flexibility. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
