To:
Keith Moore <moore@cs.utk.edu>
Cc:
Steve Hanna <steve.hanna@sun.com>, Simon Josefsson <simon+keydist@josefsson.org>, Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From:
Derek Atkins <warlord@MIT.EDU>
Date:
14 Jan 2002 18:52:26 -0500
In-Reply-To:
<200201142340.g0ENeLi00807@astro.cs.utk.edu>
Sender:
owner-keydist@cafax.se
User-Agent:
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Subject:
Re: looking for draft volunteers
Keith Moore <moore@cs.utk.edu> writes:
> > >From a security standpoint that is not necessarily an unreasonable
> > requirement. Then again, nothing says that you can't have a different
> > SSL key for each user key. But if you're going to do that, why not
> > just store the user key in DNS in the first place?
>
> how well would this support a zone like aol.com that has tens of
> millions of users, with a fair percentage of these keys changing
> each day?
That's a reasoable question to ask, and I don't have an answer.
> > > that's fine. but unless the SSL key is verifiable from DNSSEC,
> > > you don't know for sure that you're talking to the right server.
> >
> > Right, that was my point. That's why you need the SSL key (or a hash
> > thereof) in the NAPTR referral, signed by DNSSEC.
>
> again, I don't think the key (or a hash) belongs in the NAPTR referral,
> but that's just an argument about what's reasonable to put in a NAPTR
> RR.
The problem is that if you dont put a key or key-hash in a NAPTR, then
you can't get a secure referral. If NAPTR points you to server X,
someone could TCP-hijack your connection X and send you bogus
responses (if X uses UDP it's even easier to spoof!). However, if
there is a key or key-hash in the NAPTR, then the attacker (hopefully)
wouldn't have the secret key tied to that so wouldn't be able to
impersonate X.
I must admit my knowledge of NAPTR isn't very good, so if you need to
make 'A' querries after you receive your NAPTR response, then I
suppose you could obtain the key's that way. So long as NAPTR is
signed by DNSSec (and the A and key records are too), then you've got
the equivalent of a secure referral in two or three round-trips
instead of one.
> > Why should you trust the information you get from e.g. www.mit.edu?
>
> since I don't currently use that information for anything critical
> or sensitive, I don't currently need to trust it.
True, but that wasn't the point. replace "mit.edu" with some site
that you _do_ use for information retreival. What about
"www.cnn.com", for example?
[snip]
> I think we understand each other here; we just basically disagree
> on what it means for DNS to do this "well".
Perhaps ;)
> Keith
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available