On Fri, Nov 15, 2013 at 7:55 AM, Iljitsch van Beijnum
<iljitsch(_at_)muada(_dot_)com>wrote:
On 15 nov 2013, at 12:14, Hannes Tschofenig
<hannes(_dot_)tschofenig(_at_)gmx(_dot_)net>
wrote:
We mandate other things in protocol specification as well (that aim to
take performance, for example, to a specific level) then why not also
certain security features.
I'm all for mandating certain security features. A big part of that is not
having insecure stuff in version 1 of protocols, because once the can is
open, the worms never (completely) crawl back in. However, mandates in the
form "if you do X you may only do it in manner Y" don't mean much, because
the IETF has no real-world power beyond the text of its specifications.
That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much
security in a world where CAs are not trustworthy, people still use
RC4/MD5, use woefully short keys for otherwise strong algorithms, browsers
have effectively trained people to always click "visit anyway" and so on.
Well fortunately we don't live in that world.
How many security vulnerabilities does Microsoft patch every month? how
many does Cisco patch? how many do the browser vendors patch? How about
Apple?
How many are known but not patched?
I know it is the fashionable and popular thing to blather on about CAs but
our industry can count the number of failures. That is not something the
rest of the industry can claim.
PKIX has a mechanism for dealing with failures in the trust system
including the far more common failures as system managers lose control of
keys and legitimately credentialed subjects defect. One might think that if
there was really a problem in the CA system that browser providers would be
anxious to implement revocation properly but instead many are moving to
abandon it.
--
Website: http://hallambaker.com/