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.