Date: Fri, 17 Oct 2014 20:17:21 +0000 From: Phil Pennock <oss-security-phil@...dhuis.org> To: oss-security@...ts.openwall.com Subject: Re: attacking hsts through ntp On 2014-10-17 at 08:50 -0700, Tim wrote: > It seems to be a better place to put HSTS-like information is the DNS. > If we ever got to the point where DNSSEC were actually deployed and > not downgradable, then a record of some kind indicating which services > should be "secure" could solve this. That's called "DANE" and it uses TLSA records in DNS. It's slowly bootstrapping into use in SMTP and server-server XMPP as an opportunistic TLS latch, providing the correct trust anchors too. Various feature-request bugs against browsers have eventually gotten closed as will-not-fix or equivalent, because verified DNSSEC is not seen as something which is likely to be widely deployed in clients; there's a chicken/egg problem here. By contrast, servers are more likely to be placed with care and attention to DNS resolution, so someone running an SMTP or XMPP server who wants to use DANE can fix their DNS setup, once. So it's seeing more use there. Postfix has DANE support; Exim has it as an experimental feature (which just means that the API might change); the Prosody XMPP client can be set up to use DANE. (For clarity: the server/receiver side of any connection requires no code changes to support DANE, although having SNI support probably helps; the initiator which verifies the peer is the only one which needs changes, but they're currently ugly ones). > wouldn't be MitM-able since there should be a full chain of trust from > the root servers. You're ignoring the attack vectors against DNSSEC. If someone can get an uncompromised copy of the root signing keys, then DNSSEC is good; but most validators bootstrap via Trust On First Use and any defense against the sorts of acronym agencies who have been abusing mal-issued certificates needs to also defend against local legislating dictating that a national alternative root zone-signing key be used, with alternative root servers. Inline resigning can re-delegate to the elsewhere-valid subsidiary keys where a domain is not "of interest" while replacing the trust keys for domains which are of interest. ie, DNSSEC does *not* protect against nation-state actors who are willing to have their actions be visible and can legislate controls on their nation's ISPs. -Phil
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.