On 9 October 2013 16:55, Stephen Kent <[email protected]> wrote: > Ben, > >> O... >> >> How about a distinction in compliance? That is, you can say you comply >> to RFC xyzw if you implement it, but to say you _securely_ comply, you >> have to switch on the MTUFS (mandatory to use for security) and switch >> off MTNUFS (mandatory to not use for security) features in the RFC. >> Some RFCs could only have a secure compliance mode, of course. >> >> That way, those who argue that the security is too expensive/not >> needed for their use case can disable it, but then can't claim that >> they're secure (regardless of the name of the RFC :-). >> >> So, in TLS, for example, secure compliance might consist of TLS 1.2 + >> AEAD modes only (note: really an example, not an actual proposal). > > That's a novel suggestion, a clever way to try to thread the needle! > But, for many, many years we've had trouble getting the broader community to > recognize than not all RFCs are standards. I doubt that the distinction > you suggest would be better understood.
It's all about incentives. Why would anyone care right now whether an RFC is a standard or not? No-one beats them up for complying with non-standards. Or even failing to comply with standards. If we are proposing to move into a world where we incentivise people to care, then we need to actually call out people who fail to follow the standards - and, as well, who fail to follow the secure standards. Just as now it is at least reasonably well understood by vendors that TLS is desirable, because it gets pointed out if it isn't used, we need to do the same for other secure standards. Note that TLS for SMTP does not enjoy the same level of security as TLS for HTTP. Why? I claim it is because it is completely invisible to users, so there's no incentives for vendors to get it right. We need to make these things visible (and I don't mean "show a padlock", btw, I mean the kind of visibility we propose for Certificate Transparency, namely, if it doesn't work right, you don't connect). _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
