[Ach] DNSSEC [was: Re: filippo on SSL SMTP encryption]
thomas at preissler.co.uk
Tue Mar 31 21:59:00 CEST 2015
On Tue, Mar 31, 2015 at 03:17:56PM -0400, Daniel Kahn Gillmor wrote:
> We need *more* functional authentication systems, and we need to be able
> to use them in corroborative ways. DNSSEC strikes me as a mechanism
> that can be used alongside CAs or WoT or TOFU as an additional verifier.
but everything is building on DNS right now and everything is expecting
(from a DNS point of view) either a response or NXDOMAIN, nothing else.
With DNSSEC there will be a third state, as 'not trusted'. And you have
to deny further communication then, or DNSSEC would be pointless.
I believe we have gone past that stage to 'change' DNS into something
more 'trustworty' or 'secure' (and this has a lots of different
meanings). What I mean is that DNS cannot be changed easily, you cannot
modify it - or you just create a similar vicious circle what take a
while for IPv6 to take off.
> As for moving the verification to the resolver, that's obviously a
> losing prospect, since it just puts your trust in an unreliable remote
> host (and over insecure transport, even, in the common DNS use case!).
> What we need is for resolvers to transfer the entire signing chain to
> the stub so that verification can take place on the local client.
I believe it doesn't matter where you do your DNSSEC validation, you get
problems everywhere, resolver-side or client-side, some more, some less.
I also believe all of this doesn't really help from a common user point
of view. When you bring in TLS certificates (as SSL is now dead) and
consider its error messages and then DNSSEC as well (which is just +1),
what do you tell the user why your connection is failing?
I don't believe it is helpful to browser venders to display "Domain XYZ
is not trusted" and that's it, users would expect a "Ignore" button
(coming back to the problems what the US are having with DNSSEC
DNSSEC is not the best horse to sit on. It brings too many problems, and
the benefit is minimal. We should work on more user-friendly error
messages and leave DNS alone, as this is now an essential building block
to the whole internet. Instead implement higher level encryption what
DNSCurve (http://dnscurve.org/) for example is suggesting, and this
would also be transparent to the client, ie. much, much easier to
www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415
GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415
More information about the Ach