[Top] [All Lists]

Re: cryptographically verifiable fields

2004-01-26 14:30:03

James M Galvin wrote:

So you're in need of a "PKI", essentially.  Well, if we had DNSSEC you
would have one, ideally suited for this application since given an email
address you've got all the information you need for a lookup and the
machinery to do it.

I've looked at the DNSSEC RFCs and reviewed the base DNS RFCs, and it's
not entirely clear how DNSSEC would help with cryptographic verification
in an email context.

I had suggested an SMTP-based mechanism which would
a) localize most of the implementation details in SMTP MTA implementations
b) localize the administrative overhead to SMTP MTA administrators

It seems that any DNS-based approach is going to add load to DNS
Particularly for large organizations, that may be impractical.  This
issue should
not be underestimated; there are typically many more email addresses
than hosts
in a given domain.

Since signing a portion of an email message would have to be performed by an
MUA or MTA, it appears that an approach involving DNS for distribution of
public keys still requires handling the private keys in the MUA or MTA, and
therefore involves synchronization and consistency between two separately
administered protocols (DNS and SMTP).

As email addresses are not domain names per se, there is also the
question of
how well DNS would be able to handle some aspects of distribution of public
keys for email addresses:
a) RFC 1035 section 2.3.4 limits DNS names to 255 octets, whereas an email
    address might be 64 + 3 + 255 = 322 octets (RFC 2821) [addresses
might be
    longer, but RFC 2821-conforming SMTP implementations are required to
    at least that much].  One of the benefits of looking up the public
key for a given
    email address via an SMTP server registered as handling email for
the corresponding
    domain is that that server presumably can handle those email addresses
    appropriately (including length, case-sensitivity (see below),
multiple addresses
    per account, etc.).
b) it's not entirely clear what name would be used for a particular
email address:
  i) RFC 1035 section 2.3.4 requires case-insensitivity, which is fine
for a domain
      name, but not necessarily so for the local-part portion of an
email address
  ii) it's not entirely clear whether RFC 1035 section 8 mailbox
encoding should
       be used.  It appears to be unnecessary, and 1035 doesn't
specifically deal with
       email addresses as names (vs. RR data) -- this would have to be
  iii) then there's section 8.2 experimental mailbox binding (said
         presumably having been abandoned)
c) it's unclear how well DNS implementations would be able to scale up to
    handling KEY RRs for large numbers of email addresses within a domain.
    In particular, zone transfers may be unwieldy.
d) what happens if some DNS server starts handing out bogus keys for non-
    existent email addresses? [remember the Verisign (and others)
wildcard DNS

Some of these issues may of course have counterparts in the case of the
SMTP-only method; others are not applicable.  Issues that would have to
be fleshed
out include:
a) some means of key distribution among multiple SMTP servers operating
as MX
    specified SMTP servers for a particular domain
b) protection of the private keys is an obvious concern
c) some large installations utilize separate groups of servers for
    messages (where signing would take place using private keys) and for
    messages (registered via MX, and presumably where requests for
public keys
    would be handled).  So in those cases, some synchronization would be
    though that would be within the province of email administration
rather than
    crossing email/DNS administrative boundaries.
d) some abuses may still be possible, but handling public keys via SMTP
    registered as MX handlers reduces the scope for abuse (since wildcard MX
    records are explicitly allowed).  The suggested SMTP-only mechanism
    specified retrieval of public keys from MX handlers specifically to
    the potential for abuse.
e) MUAs and/or MTAs that wish to make use of signatures could arrange to
    cache public keys locally rather than retrieve them for each
instance.  While
    use of DNS could automatically cache results, the necessary
information is
    essentially invariant (one may need to verify the signature of a message
    received in the distant past), and such information would probably
best be
    cached by email-specific software rather than consuming generic DNS
    memory with application-specific (email) data.  Caching is of course
not a
    necessity, but could reduce network load.