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

Re: draft-richardson-ipsec-opportunistic-02.txt



-----BEGIN PGP SIGNED MESSAGE-----


  Guys, I'm reposting to the design list and namedroppers, if for no other
reason than for a record... 

  The movie so far:
      1) Simon emailed Henry, DHR and I about our use of TXT and KEY.
      2) Michael responded, saying that we use KEY to store raw RSA keys
	 for the endpoints.
	 We use TXT records (see the draft) to provide authorization of
	 delegation from end-nodes to gateways (and to discover the gateways)
      3) Henry has responded, with the text below, which I'm quoting.
      4) A large Aladdin-type Genie, but with Bruce Schneier's voice, pops
	 out, and solves the global-PKI problem. 

>>>>> "Henry" == Henry Spencer <henry@spsystems.net> 
>>>>> "Simon" == Simon Josefsson <sjosefsson@rsasecurity.com> 

    Simon> Ok -- right now the trends within the DNSEXT group seems to be that
    Simon> KEY should only be used for DNSSEC internal purposes as well, and to
    Simon> have some other RR for application related purposes.  (The DNSSEC
    Simon> specs are being revised.)

    Henry> As Michael said, we're already using KEY for the purposes endorsed in RFC
    Henry> 2535.  Changing that will involve some difficulties, because of the need
    Henry> to get support for an alternative record into BIND etc., but it could be
    Henry> done if necessary, sigh.

  Simon, your above statement suggests to me that you don't want us to use
KEY to identify host info at all. Is there a document that explains this in
detail? KEY seems to have lots of bits designed to distinguish different
uses.

  We could certainly use two kinds of CERT record - one for the raw RSA host
key, and the second for delegation authorization. The second one is discussed 
below:

    Simon> I have intended to write a draft that says CERT RRs should be regarded
    Simon> as containing "application security related information".  Requiring
    Simon> that CERT must contained signed data is irrelevant from a DNS point of
    Simon> view...

    Henry> Indeed so.  Relax *that* requirement -- which could be read as an accident
    Henry> of wording rather than a matter of fundamental intent -- and CERT would be
    Henry> a good match for our needs.

  I think that we are in agreement. I didn't take the "signed" part of the note too
heavily anyway. 

    Simon> With your permission, I'd like to include your IPSEC usage as a
    Simon> example of what the CERT RR could have as sub-types...

    Henry> Yes, by all means, go ahead.  As Michael noted, there are two or three
    Henry> variations involved (IPv4 address, IPv6 address, DNS name), but that's
    Henry> a secondary issue if it's being used purely as an example.

    Simon> You would need to write the CERT sub-type registration yourself, if you
    Simon> think CERT RR's is a good idea.  What do you think?

  I think that this would be appropriate for a "Opportunistic Encryption
version 2" specification. We believe that there are a number of things
unrelated to the syntax used to store the keys that need to be solved
first. Our solution, while in-elegant is functionally identical to one that
had CERT RRs instead.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBO/GzXYqHRg3pndX9AQESNwQAp1yZ71ETFaJMWRFiPUfFQ03ynEtF+NG4
QVo/i21MXDDcAcx1qwST/Saa6gCTO1HCipTwCVi+Whi/wCFv+gAOySIvC4Ge6s23
CmhzhyKi8YNlSQNPlXs52RjGKhJNlokTilY69LPGdC6GHJFME8UeaTev52KzeuYQ
28ecYXHPfd0=
=YQkQ
-----END PGP SIGNATURE-----