Re: A proposal

ok, so DNSSEC makes it hard to spoof DANE records if the root domain's 
DNSSEC public key is baked into the client.

it however makes the root domain (.) DNSSEC private key the single most 
valuable secret in the history of the world.

What happens if this gets out or gets stolen or brute-forced?

At least CA certs expire, and there are lots of them.  This is seen as a 
negative in the DANE RFC, but it can be a positive in the 
all-eggs-in-one-basket argument.

Sorry if this is O-T, but if we're building the internet on DANE....


------ Original Message ------
From: "Adrien de Croy" <adrien@qbik.com>
To: "Amos Jeffries" <squid3@treenet.co.nz>; "ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 20/11/2013 1:24:53 p.m.
Subject: Re: A proposal
>still not free. Seems like a bunch of work there.
>
>Certs can therefore no longer be used to provide identity. Only 
>presumably verify admin control over a domain.
>
>But also makes it even easier (at least for us) to MITM, since we are 
>also the DNS server for the client, we can alter such records, and then 
>we wouldn't even need to deploy a signing cert.
>
>Adrien
>
>
>------ Original Message ------
>From: "Amos Jeffries" <squid3@treenet.co.nz>
>To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>Sent: 20/11/2013 12:19:46 p.m.
>Subject: Re: A proposal
>>On 2013-11-20 11:15, Adrien de Croy wrote:
>>>even if a cert is $0 it is not zero cost.
>>>
>>>Time and effort are not free.
>>>
>>>All these options involve an ongoing management/maintenance cost as 
>>>well
>>>
>>>And are we really proposing the internet should be built on certs 
>>>from
>>>free cert providers? How will they stay in business or the certs
>>>remain free once the demand for free certs is multiplied by several
>>>orders of magnitude?
>>
>>DANE.
>>
>>* generate your own CA certificate.
>>* have your DNS provider sign it as part of your DNSSEC signed zone 
>>records
>>* profit
>>
>>
>>Payment (of lack of it) will be part of your contractual agreement 
>>with DNS provider and avoids the CA authority mess currently blighting 
>>trust in TLS.
>>
>>
>>Amos
>>
>>
>
>

Received on Wednesday, 20 November 2013 01:33:39 UTC