[dnssec-deployment] dnssec automatic trust anchor configuration

[Roy Arends]

On Mar 8, 2007, at 1:58 AM, Paul Wouters wrote:

> On Thu, 8 Mar 2007, Roy Arends wrote:
>
>> In a sense, RIPE is already using the concept of certificates to  
>> authenticate
>> their Trust Anchors to the administrator: It relies on the admin  
>> to (1) start
>> a browser, (2) type in the right url, (3) check if the site is  
>> secure, if so
>> then (4) click on the right link, (5) download it a certain  
>> location, (6)
>> download the PGP sig, (7) start pgp to authenticate the file from  
>> step 5 using
>> the sig from step 6, if authenticated then (8) configure the keys  
>> in the
>> trust-anchor store.
>
> Note that there are several authentication methods here. The CA/X. 
> 509 cert and
> the PGP signature (with web of trust, decentrally located  
> elsewhere) and the less
> secure "It's in their DNS servers so it must be right" and the  
> "It's on their
> website therefor it must be real" method.

I agree.

>
>> This can be automated.
>
> Yes. And while doing so, you would verify that:
> - website hasnt been taken over
> - dns hasn't been polluted
> - Presented on a trusted SSL webserver, having seen out of bounds  
> verification
> - Presented with trusted PGP signature, having seen out of bounds  
> verification.
>
> To attack all of those (eg all pgp keyservers, and hack into a  
> certified CA
> provider) would be next to impossible (and hopefully someone would  
> detect it).

With 'this can be automated' I meant: the process of adding a Trust  
Anchor to the Trust Anchor Store can be automated. I wasn't  
suggesting to use some script to automate step 1 to 8 exactly as  
portrayed.


>
>> The concept that DLV uses is similar to a Certification Authority.
>
> Not at all. The CA (or DLV) is a single point of failure. The above  
> is not.

not sure what you mean.

>
>> My validator needs to go to the DLV registry, possibly several  
>> registries, to get its crypto-fix.
>>
>> My proposal was to have a CA scheme that is not limited to signing  
>> TLDs, and
>> is not dependent on location outside the resolution graph.
>
> using DLV, we add more especially good targets apart from the Root  
> key. Suddenly,
> I also have to trust the root servers, Affilias' procedures on the  
> security of .org,
> ISC's security of their own domain and the DLV records they are  
> serving.
>
> Unless we are hardcoding the keys for dlv.isc.org, in which case  
> we've just
> moved the problem of a signed root key, and we now need another  
> solution to pass
> along the DLV uber key.
>
> Or perhaps I do not understand your solution?

I think you missed the point.

My point is:

instead of using DLV, use a CA
instead of publishing data signed by DLV in a DLV-zone, publish data  
signed by CA in the signed zone

Spot the difference

DLV setup:

trust anchor DLV.isc.org in validator
lookup bla.something.  -> is signed but no trust anchor
lookup bla.something.dlv.isc.org.
validate bla.something.dlv.isc.org. using dlv.isc.org trust anchor
store bla.something. in trust-anchor-store if validated

CA setup:

root-CA ca-isc-org in validator
lookup bla.something.  -> is signed but no trust anchor
lookup bla.something. CERT
validate bla.something. CERT using ca-isc-org root CA
store bla.something. in trust-anchor-store if validated

Hint: DLV depends on a physical infrastructure. CA does not.

hope this helps

Roy