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
administrators.
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
support
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
clarified.
iii) then there's section 8.2 experimental mailbox binding (said
experiment
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
shenanigans?]
Some of these issues may of course have counterparts in the case of the
suggested
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
originating
messages (where signing would take place using private keys) and for
receiving
messages (registered via MX, and presumably where requests for
public keys
would be handled). So in those cases, some synchronization would be
required,
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
servers
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
mitigate
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
cache
memory with application-specific (email) data. Caching is of course
not a
necessity, but could reduce network load.