please move this stuff into DNS

Posted Dec 25, 2008 14:11 UTC (Thu) by TRS-80 (guest, #1804)
In reply to: please move this stuff into DNS by weasel
Parent article: SSL man-in-the-middle attacks

I think the problem with putting the cert fingerprint into DNS is the application doesn't know if the response was secured by DNSSEC or not.

To get rid of CAs for basic cert uses, which is protecting passwords from being sent in the clear, Mozilla should be implementing and advocating RFC 5054, TLS/SRP, however NSS (a Mozilla subproject) won't add it until Mozilla does the UI work, but Mozilla wants to do the UI work as extensions, so needs NSS done first.

please move this stuff into DNS

Posted Dec 25, 2008 20:15 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (4 responses)

Er, if I'm reading this right, it's just an HTTP-authentication-style password exchange system, built out of TLS primitives.

For vain reasons, it'll never be used: web designers like being able to specify how their login boxes look.

please move this stuff into DNS

Posted Dec 26, 2008 2:23 UTC (Fri) by TRS-80 (guest, #1804) [Link] (3 responses)

Well, it's not just applicable to HTTP - you can use it for IMAP and SMTP authentication too. How many people use a self-signed cert for those, and are going to be bitten when Thunderbird 3 comes out with the same anti-self-signed UI as Firefox?

Anyway, for web designers HTML 5 offers a way to have HTML login forms for HTTP auth.

please move this stuff into DNS

Posted Dec 26, 2008 3:18 UTC (Fri) by drag (guest, #31333) [Link] (2 responses)

You know that creating your own signing certificate is not significantly more difficult then making a self-signed... I mean I started off with self-signed for mucking around with doing things, but figured that since I am worrying about encryption anyways I might as well do it myself.

It just strikes me as a bit lazy. Not a lot lazy as the SSL/TLS stuff is difficult to get right. But for as long as this stuff has been out it should be fairly simple to do.

please move this stuff into DNS

Posted Dec 26, 2008 3:36 UTC (Fri) by TRS-80 (guest, #1804) [Link] (1 responses)

The point isn't how easy/lazy it is, the point is to avoiding have to trust (now apparently) untrustworthy CAs. Maintaining your own CA (is that what you mean by signing certificate?) might be OK if you're the only user, but asking other people to install your CA is a right pain, and then you have to worry about keeping the CA secure, plus all the regular PKIX hassles of updating certs etc.

Security problems with CAs

Posted Dec 26, 2008 13:21 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Sad fact is that really checking is expensive, and CAs aren't in the business of "wasting" money to then turn a paying customer away... plus certificates are the same whether they are meant to protect (probably not very interesting) email from prying eyes, commercial transactions in the range of a few tens of dollars, or multi-million dollar movements. The association of the "personal" certificate with all sorts of identifying data makes the planned use of those a privacy nightmare. The whole concept is deeply flawed. For an in-depth discussion of the current issues, look at Peter Gutmann's PKI tutorial (a large PDF presentation).

please move this stuff into DNS

Posted Dec 26, 2008 8:27 UTC (Fri) by weasel (subscriber, #6031) [Link] (3 responses)

I think the problem with putting the cert fingerprint into DNS is the application doesn't know if the response was secured by DNSSEC or not.

Unfortunately the article you link to only states the same fact as you, and does not even try to give an explanation, reason or argument.

At least ssh appears to be able to figure out if information it gets from DNS is secure or not. It does that by checking the AD bit in the dns response (see dns.c in its source and the VerifyHostKeDNS entry in the ssh_config manpage).

please move this stuff into DNS

Posted Dec 28, 2008 23:40 UTC (Sun) by jamesh (guest, #1159) [Link] (2 responses)

Unless I am mistaken, that code is only testing that the DNS server OpenSSH uses thinks that the DNS record is secure. It doesn't actually do any verification itself (following the signature chain all the way back to the DNS root).

If I set up a public wifi network, I could easily provide a DNS server that said every record was secure and use DHCP options to get machines that connect to use that server. How would OpenSSH be able to tell the difference between this network and a secure network where the responses from the DNS server can be trusted?

So there seem to be real problems with applications trusting DNSSEC results given the types of networks people connect to these days ...

please move this stuff into DNS

Posted Dec 30, 2008 14:40 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

You could provide such a DNS server, but you can't force me to trust it.

On a laptop I can choose to run a local DNS server, which implements DNSSEC and (as soon as the root is signed) get a complete end-to-end chain. Perhaps you don't know anybody who does this today, and perhaps in five years you won't know anybody who doesn't.

On a moderately secure wired LAN (or suitably protected wireless one) I can provide a local DNS server and sacrifice the last hop security for improved performance from the shared cache.

What's much nicer about using DNSSEC for this is then all I'm relying on is the immediately evident hierarchy, thus...

physics.soton.ac.uk relies on the root, then the UK government and its DNS operator Nominet, the JaNET (UK academic network) management & operator, and the University (of Southampton)'s management and systems team. This makes sense - it's almost the same hierarchy that issued the machine with an IP address.

Whereas with current CA-based SSL physics.soton.ac.uk may well rely on the integrity of a cheap reseller from Taiwan, who acts as a front for an outfit in California, which in fact subcontracts the technical work to a small business in Finland run by a 14 year old girl. But I can't tell any of that, all I get is a picture of a padlock.

DNSSEC can be leveraged to deliver secure-by-default to the web, something which I think would be more revolutionary than most people realise.

please move this stuff into DNS

Posted Dec 31, 2008 5:37 UTC (Wed) by jamesh (guest, #1159) [Link]

I am sure that you are smart enough not to enable VerifyHostKeyDNS option in ssh for any machine that uses an untrusted DNS resolver. But surely you understand why the option is disabled by default, right?

Until we get to the point where people get a secure DNS resolver installed by default, it doesn't make sense for application developers to trust the DNS response by default. Relying on a pre-shared public key gives the application much better assurance (even if this assurance is weaker than what they'd get from a properly verified DNSSEC response).

Perhaps if an operating system installed a DNS resolver that performed the necessary checks by default, it would make sense for applications to trust the response flags. But until that point, applications are better off using some other trust mechanism.