[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141017201721.GA84519@tower.spodhuis.org>
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.
