[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Ted.Lindgreen@tednet.nl, Dan Massey <masseyd@isi.edu>
Cc: dnssec@cafax.se
From: ted@tednet.nl (Ted Lindgreen)
Date: Thu, 19 Apr 2001 11:44:05 +0200
Delivery-Date: Thu Apr 19 20:30:48 2001
In-Reply-To: "Ted Lindgreen's message as of Apr 19, 10:21"
Reply-To: Ted.Lindgreen@tednet.nl
Sender: owner-dnssec@cafax.se
Subject: Re: Keys at apex problem

Oops....

[Quoting Ted Lindgreen, on Apr 19, 10:21, in "Re: Keys at apex pro ..."]
  ....
> Option B assumes:
>  1. you trust the IETF conference cachingforwarder.
>  2. you can use TSIG to be sure you talk with this
>     server, and not some faked one.
>  In this case, your laptop (stub-resolver) is just asking
>  for ssh-KEY of east.isi.edu with CD clear. The IETF
>  conference cachingforwarder is doing all the work above
>  and gives you back the requested RR with AD set.
>  (ALternatively, you could also use your trusted cachingforwarder
>  backhome using exactly the same protocol. Easier to setup, perhaps
>  trustworthier, but cause a bit of extra traffic).
> 
> Option B assumes:

I meant to say "Option A assumes:" here, of course.

>  1. you trust nobody.
>  2. your laptop stub-resolver has a secure entrypoint
>     preconfigured.
>  In this case, your laptop stub-resolver must do the checking
>  walkdown, but can be using the cached info from the IETF
>  conference cachingforwarder. Because your laptop stub-resolver
>  is checking itself it can set the CD and ignore the AD bit from
>  the cachingforwarder.

Regards,
-- Ted.

Home | Date list | Subject list