On 17.6.2017 16:26, Paul Wouters wrote: > On Jun 17, 2017, at 10:18, Petr Špaček <petr.spacek@xxxxxx> wrote: >> >> >> This is exactly the point where our opinions differ. >> My point of view is that specification should clearly define extension >> points and implementations should: >> a) Use Postel's principle within defined 'extension' points. >> b) Treat any deviation from documented protocol (including non-defined >> aspects of protocol outside of extension points) as an error. > > So abort all your HTML pages from loading? > > b) is an error that should be handled in a Postel way and the RFC should > be updated to address the issue. Then maybe years down the line you can be more strict on the failure. Please let me clarify that can be reasonably applies only to new protocols or new extensions of existing protocols. We do not have time machine and I'm not proposing to break existing deployments... > Also the consequences of being strict can be worse. Should a TLS connection fail if the nonce size for the integrity algorithm is too weak? Will the result be a retry using plaintext offers greater risks? What if the connection is for a public webpage? What if it is for a nuclear control channel? To use your example, it might be better to refuse opening a "nuclear control channel" if it is giving just false sense of security by using nonce size 1 byte :-) Now seriously: If the protocol and strict approach to its implementation was specified from the very begining (again, this is applicable to new development) we could easily refuse to open connection because almost all implementations would do the same, so incentive to fix it would be significant. > if things were an easy black and white, we wouldn't have this discussion every couple of years. Sure. That is why I'm advocating for getting stricter and stricter from now on. I hope it clarifies the point. Also, please refer to langsec article from the previous point, it has a lot to say about security reasons for stricter approach. -- Petr Špaček @ CZ.NIC