On Sat, Jun 17, 2017 at 7:26 AM, Paul Wouters <paul@xxxxxxxxx> 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.
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.