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