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


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

Home | Date list | Subject list