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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]