Subject: Re: Comment on draft-ietf-dnsext-dnssec-records

From: "Matt Larson" <[email-masked]>
Date: Fri, 2 Aug 2002 20:07:58 -0400

> Tracking down the CERT RR's algorithm field's mnemonic names, I find
> in RFC 2538:

Thanks for pointing that out.  One of the things the editors are going to do
is take a thorough pass through RFC 2535 and look for omissions in the new
documents.  We're going to make sure every RFC 2119 word in 2535 is covered
in the rewrite, as well.

> IMO2 draft-ietf-dnsext-dnssec-records should contain CERT too.  Taking
> RFC 2538 and fixing a few unclear spots (e.g., whether the PGP CERT
> RRDATA should include the checksum field or not) should be sufficient.
> I'll volunteer to do it if human resources is the limiting factor.

That's out of scope.  CERT's never been a part of DNSSEC, even when you
expand the term to include TSIG.  And the DNSSEC rewrite is an editorial
exercise: when we find protocol issues, we bring them to namedroppers.  What
you describe sounds protocolish and would need namedroppers discussion,
anyway.

Matt
--
Matt Larson <[email-masked]>
VeriSign Global Registry Services

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

---

From: "FORENSICS.ORG Security Coordinator" <[email-masked]>
Date: Fri, 2 Aug 2002 14:29:58 -1000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

To Whom It May Interest:

A DNS-based security vulnerability exists that has not yet been disclosed
publicly. The vulnerability was discovered by a third party and
FORENSICS.ORG is acting in the capacity of COORDINATOR pursuant to the
Responsible Vulnerability Disclosure Process, referenced below:

http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0
0.txt

We are in need of input from persons working with DNSSEC in connection with
the planned ADVISORY. Although DNSSEC will not completely solve this
particular problem, it is important to include details of the risk factors
that ARE mitigated partially when DNSSEC is employed. The most likely
security patch will involve mandatory updates to every resolver.

In order to discuss the technical details of the threat in a responsible
manner, it is necessary for us to disclose the vulnerability in full to a
small number of trustworthy individuals with expertise in certain subject
areas, DNSSEC being one of these areas.

If you are interested in contributing to the content of our forthcoming
ADVISORY, please contact us by Thursday, August 8th for consideration by our
team of your eligibility for early disclosure.

Thank you.

FORENSICS.ORG Security Coordinator

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 Aug 2002 12:21:00 +0200

> you describe sounds protocolish and would need namedroppers discussion,

Anyone with an opinion on whether the RRDATA should include the
OpenPGP checksum or not?  Essentially I guess the question amounts to
whether the RRdata should contain the binary or the ASCII armored
version of OpenPGP certificates.  I am using binary, but RFC 2538 is
not clear that this is what is intended.

Discussion on what to do when OpenPGP data exceeds the RRdata
limitation should also be included.  I'll post the solution I'm using
soon.

I'm also storing OpenPGP key revocation signatures using the CERT
"PGP" type, which might not be intended either.  Perhaps a new CERT
type for key revocation signatures should be allocated.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 5 Aug 2002 08:10:52 -0400

At 8:07 PM -0400 8/2/02, Matt Larson wrote:
>Qouting Simon:

In the earliest slide sets on DNSSEC, I claimed CERT RR as part of 
DNSSEC.  But Matt is right.  The CERT RR really isn't part of DNSSEC 
- other than being chronologically related (look at the RFC numbers). 
Especially now that the KEY RR is being restricted and a tighter view 
of DNSSEC is being applied, the CERT RR is further removed from being 
a part of DNSSEC.  I.e., the CERT RR and the application-KEY RR were 
the forays into a certification publication mechanism (which 
sometimes has been incorrectly labeled a PKI).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer