On Sat, Jun 17, 2017 at 7:26 AM, Paul Wouters <paul(_at_)nohats(_dot_)ca> wrote:
On Jun 17, 2017, at 10:18, Petr Špaček <petr(_dot_)spacek(_at_)nic(_dot_)cz>
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.
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?
Not to get too into the weeds, but this isn't a coherent question: In TLS
1.1 and TLS 1.2 [0]
the size of the nonce is associated with the cipher suite and it's encoded
onto the wire
without framing. If the sender uses the wrong nonce size, you just get
integrity failures.
To take an example that's more realistic: yes, browsers do indeed decide
that certain
algorithms (e.g., RC4 or DHE below a certain keylength) are insecure and
refuse to
connect.
-Ekr
[0] TLS 1.3 uses implicit nonces.