[Cryptography] DNSSEC = completely unnecessary?

[Greg]

> It's true as we bolt more and more stuff into HTTP Headers (HSTS,
> Public Key Pinning, etc) the value of DNSSEC _for HTTPS_ goes down.
> But there is still value there to be gained for other protocols,
> nearly all of which bootstrap off DNS.

I'm curious, what are these other protocols, and why can't they be secured simply by using SSL/TLS + some type of cert. verification?

Let's say that they can, and that it takes 1000 man hours to do this. Let's also assume that it takes 10x as much time to implement widespread DNSSEC use. Then why are we wasting all those man hours on implementing DNSSEC instead of using them to add SSL/TLS + cert. verification to other protocols?

Why is anyone still using HTTP?!? It's 2013!

Why does it cost any money to get an HTTPS cert?

These seem like more pressing problems to me.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Nov 4, 2013, at 7:36 AM, Tom Ritter <tom at ritter.vg> wrote:

> On 3 November 2013 23:33, Greg <greg at kinostudios.com> wrote:
>> In all my readings on it I kept walking away thinking that I understood its
>> purpose, but I'd then come back at myself with the same question: what does
>> it give us over HTTPS?
> 
> DNS does not provide authenticity, DNSSEC does.  Not everything we do
> online uses SSL, so while many protocols have some amount of
> authenticity built in to them (each flawed in their own way, as
> Zooko's Triangle dictates some practical limits) - DNSSEC lets us
> bootstrap authenticity for any protocol.  "The person you want to talk
> to is [here] and he will use [this key fingerprint]."
> 
> 
>> In the presence of functional SSL/TLS, DNS
>> cache poisoning can only produce a denial of service attack. The scenario
>> we're trying to prevent is, "A thinks he is talking with B, but is actually
>> talking with C." Cache poisoning can give A the address of C instead of B,
>> which is a start, but C can't pass himself off as B unless he compromises
>> the SSL/TLS process.
> 
> DNSSEC prevents cache poisoning, when used correctly. And SSL/TLS does
> not protect HTTP, which I would venture is a laaaaarge percentage of
> web traffic, even when SSL is available.
> 
> And if you argue "Well, the HTTP problem can be solved by HSTS" I will
> say "Okay, how do you securely communicate HSTS to a host to which the
> answers are: 'Hope the user isn't owned the first time', 'Bake
> preloaded HSTS into every browser', or 'Securely transmit HSTS
> information using some other protocol like DNS."
> 
>> What say you list? To me, the DNSSEC thing seems like it might be mostly a
>> waste of a bunch of people's time.
> 
> It's true as we bolt more and more stuff into HTTP Headers (HSTS,
> Public Key Pinning, etc) the value of DNSSEC _for HTTPS_ goes down.
> But there is still value there to be gained for other protocols,
> nearly all of which bootstrap off DNS.  The other big win for HTTP
> we'll see is the ability to use self-signed certificates via DANE,
> which relies on DNSSEC.
> 
> -tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131104/e6bce809/attachment.pgp>