Subject: RFC 2538bis security problem with the indirect types

From: Simon Josefsson <[email-masked]>
Date: Sat, 28 Jan 2006 12:58:15 +0100

Hi!

While RFC 2538bis is moving along through the bureaucracy, we have
received some implementation feedback regarding the indirect I* types.
If you are lost now, you may want to refresh the document, see in
particular:

http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis.html#anchor3

The problem is that the IPGP (and ISPKI, IPKIX and IACPKIX too, for
that matter) URL value is not strongly bound to its content.

To see how this is a problem, GnuPG attempt to download OpenPGP keys
automatically using CERT records.  If it finds an IPGP type, it would
fetch the URL.  Without a fingerprint of some kind, the trust gained
by DNSSEC is not carried forward to the content.  GnuPG cannot trust
that the key downloaded is the one the recipient intended.

Traditionally (pre-DNSSEC) there isn't really a problem, because you'd
have to verify the downloaded key out-of-band anyway, but DNSSEC
enable some benefit, if it is possible to trust the CERT data
directly.  This is especially true for anti-spam schemes.

The solution is to somehow embed, within the I* types, a hash of the
content.

I initially thought that we could simply document a new CERT types
that does this, but now I'm less certain.  The problem with adding new
indirect CERT types for existing CERT types is that 2538bis says that
if, e.g., a PGP packet is too large, an IPGP type should be used
instead.  If we define a I2PGP type, that will not interoperate well.

I see a couple of solutions:

1) Add a hash checksum field to the I* types during AUTH48.  David
   Shaw (one of the GnuPG developers) has suggested the following
   approach:

      To recap, the specific change I'd like would be in section 2.1,
      where the I-types are defined as a URL that will serve the
      content.  Defining the I-types as a single length octet n (which
      may be zero) followed by n octets of fingerprint data, followed
      by the URL string up to the end of the RR.

      This gives a good amount of flexibility as it allows an IPGP to
      point to a fingerprint without an URL, a URL without a
      fingerprint, or a URL with a fingerprint for validation.

  We'll have to pick a hash algorithm, and to make it hash function
  agile.  A field that specify which hash algorithm to use is probably
  required, I suggest SHA-256 is the MUST algorithm.

2) Recall RFC 2538bis, publish an updated document with the above fix,
   and ask for another last call on it.

3) Allow RFC 2538bis to progress as an RFC, and immediately update or
   revise it.  RFC 2538bis and RFC 2538ter would not interoperate in
   the CERT I* types, but I don't consider that a serious issue.

4) Specify a URL type that embed the fingerprint.  I have been
   discussion this in other contexts before, and schemes like this
   have been used by other standardization organizations than the IETF
   before.  For example, an HTTP with embedded fingerprint could look
   like:

     http://josefsson.org/key.txt?sha1=aef3a7835277a28da831005c2ae3b919e2076a62

   or it could become a separate indirect URI scheme:

     hash:sha1=aef3a7835277a28da831005c2ae3b919e2076a62:http://josefsson.org/key.txt

   This approach may be difficult to get consensus around, URI schemes
   seem to be allocated pretty conservatively.

5) Specify a new RR for GnuPG's usage.  That would also enable us to
   specify owner name rules for revocation checks, something which the
   CERT document doesn't discuss currently.  (That discussion could go
   into the CERT document too, if it is revised, of course.)

Are there other constructive options?

I don't have a strong preference, so I won't pollute your thinking by
stating it yet.

I'll decide on the path I prefer before the next I-D cut-off, to make
it possible to submit a document solving this problem, if doing so
will be necessary.

General thoughts on how to handle this would be appreciated.

Thanks,
Simon

--
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/>