Re: SKIP in IPSEC: is it really simple?

[Germano Caronni <[e-mail]>]

Robert Moskowitz wrote:
> >no reliance on shared time, 
> very goodness

How do you plan to handle certificate expiry without shared time?

Germano

Message-Id: <[e-mail]>
To: John Gilmore <[e-mail]>
Cc: "C. Harald Koch" <[e-mail]>, [e-mail], 
    Stephen Kent <[e-mail]>, [e-mail], [e-mail]
Subject: Re: DNSSEC can't retrieve "A" and "KEY" records in the same query 
In-Reply-To: Your message of "Thu, 12 Sep 1996 01:56:09 PDT."
             <[e-mail]> 
Date: Thu, 12 Sep 1996 09:10:12 -0700
From: Paul A Vixie <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> This is a DNSSEC implementation issue, not a SKIP issue.  DNSSEC does
> not currently require this.  It piggybacks SIG records in the
> additional records portion even if you didn't ask for them, but only
> provides KEY records if you ask for them.

i think donald says this isn't an accurate story.

> The DNS specs permit several questions to be asked in a single DNS
> query.  Unfortunately the widespread implementation, BIND, only
> answers queries that contain a single question.  If it implemented the
> full spec, the resolver could send in a DNS query that asked:
> 
> 	Send me all the "IN A" records for foo.com.
> 	Send me all the "IN KEY" records for foo.com.
> 
> and get the response back in a single packet exchange.

the full spec does not answer some of the important questions that come up
if qdcount>1, like how can you tell which answer goes with which query if
the queries generate similar answers?  consider wildcard RRs and CNAMEs.

rather than answer this off the cuff, BIND (correctly) considers it a format
error to have more than one question.  the only _real_ or intended (i asked
PVM) reason why qdcount could ever be >1 is for IQUERY, which BIND deprecated
a while ago and will shortly remove.

multiple questions would be nice but it will take a completely different
encoding, probably one that allows multiple DNS Messages per datagram so that
the question and answer and additional and authority stuff doesn't get mixed,
but compression pointers will work fine so we can save a lot of name bytes.

> One could ask for "ALL" records, but that would probably end up
> returning enough data to require a TCP connection, which already
> involves a multi-packet exchange.

this won't work -- we couldn't do it for AAAA/A RRs either, since if your
question goes to a nonauthoritative server (like a LAN's caching forwarder)
it will give you "ALL" of what it has, which might be nothing or everything
or something in betwixt.

> We could conceivably require DNSSEC-conforming implementations to
> handle multiple questions in a query, but the resolver library would
> still have to be able to fall back to asking one question at a time it
> got a FORMERR (format error) from an old server in response to a
> multi-question query.  This fallback would also require multiple
> packets.

this is a slippery slope, let's not solve it as part of DNSSEC.  what i'm
proposing for AAAA is that it be a metaquery -- retrieving AAAA RRs if any
exist, or A RRs if any exist, or NXDOMAIN if neither exist.  it sounds like
donald solved the similar problem in KEY via additional data.



From: Rich Skrenta <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Using SKIP as inspiration, not as gospel
To: [e-mail]
Date: Thu, 12 Sep 1996 10:17:32 -0700 (PDT)
In-Reply-To:  <[e-mail]> from "John Gilmore" at
Sep 12, 96 01:35:34 am
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

John,

The fact that the SKIP camp is not willing to open up a solidified, mature
design to rewhack it into something that looks just like Photurus does not
make us "hamstrung".  To suggest that we change SKIP to make it "more like
every other key management protocol" misses the point of this entire
debate.

> The SKIP certificate discovery protocol (CDP) is silent on a big
> question: *where* to send a certificate discovery request.

To the host you're trying to send encrypted packets to.  This works quite
well in practice, as the remote side (be it an endpoint or a site gateway)
generally has their own certificate.