Re: DNSSEC - Signature Only vs the MX/A issue.

[Paul Vixie <paul@vix.com>]

> > christian, your words echo some i heard recently from stuart cheshire:
> 
> Well, Stuart and I often disagree, so you might consider that us agreeing
> somehow shows something...

it does.

> I am not so much looking at SSL than at end-to-end security.

you're also willing to consider a design that creates security-haves and
security-have-nots, such that any application that cares at all about security
has to do it end-to-end.  if all an application wants is confidence in the
kind of information that's easy to store in dns, like SPF or A or PTR or PGP
or MX, and is otherwise not concerned about authorization or encryption, then
in your model they have to do some kind of end to end security thing which in
your model involves non-internet key exchanges (sneakernet, x509, whatever).

in my model, applications who don't care so much about security that they're
willing to pay an end-to-end complexity penalty (like ssl or tls), can still
get moderate confidence in the basic results of a dns query.  once this is
established, we're in a position to add more types of data to dns, which the
current confidence-free system does not really encourage.

> What would be the characteristic of a DNS security system that
> complements, rather than replace, end-to-end security? For me, the
> obvious answer would be to ensure availability of the DNS service. The
> secure DNS should guarantee that, if the relevant name servers are
> available and reachable, the name resolution transaction will complete. 
> 
> The best "secure DNS" would be one that provides that guarantee at the
> least possible deployment cost. 

so you're allowing for NS-only security.  others have proposed that, but it
was decided early on (by consensus among those willing to to volunteer to do
work in this area) that end-to-end application security was something we
wanted Secure DNS to be a building block for.  so the Secure DNS model is
end-to-end rather than interior-only.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>