ietf
[Top] [All Lists]

Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

2017-06-18 03:26:07


On 17.6.2017 16:26, Paul Wouters 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.

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