ietf-dkim
[Top] [All Lists]

[ietf-dkim] [THREAT] poor deployment of secure email

2005-08-17 11:33:38
On Mon, 15 Aug 2005, Michael Thomas wrote:

I think that there's one other important aspect that's hard
for me state concisely. Utility is often bound up in the network
effect, and though PGP and SMIME solve for many of the threats
-- equally or superior -- they have not achieved any sort of
network effect. I believe that DKIM by design is specifically
trying to address the network effect and make it a goal. We
have made some specific design decisions that are ultimately
traced back to that goal:

1) use of DNS, and our lowering the bar on cryptographic trust anchors
2) lowering the expectation of what is actually asserted (ie, domain
   based rather than individual based)
3) absolutely no attempt to deal with encryption
4) the ability to ride "stealthfully" within the existing
   infrastructure without need to upgrade either MTA's or MUA's
5) ease of deployment at choke points (MTA's), and into existing
   naming infrastructure (DNS)

I'm not sure that I ultimately know where the network effect will
take us -- can anybody really predict such a thing with better than
random odds? But pervasive authentication even with lowered expectations
seems like it will enable a lot of things that point solutions with
higher barriers will cannot.

I'll turn Michael's message above into a slightly more formal arrangement
which might be useful in a threat analysis document.


THREAT: clumsy key management

draft-iab-messaging-report-00 says in section 3.6 "Identity Hints and Key
Distribution":

   While it is widely recognized that both message encryption and
   authentication of conversation partners are highly desirable, the
   consensus of the workshop participants was that current business and
   implementation models in part discourage deployment of existing
   solutions.  For example, it is often hard to get new root
   certificates installed in clients, certificates are (or are perceived
   to be) difficult or expensive to obtain, one-click or zero-click
   service enrollment is a worthy but seemingly unreachable goal, and
   once one has created a public/private key pair and certified the
   public key it is less than obvious how to distribute that certificate
   or discover other people's certificates.

EFFECTS:

The clumsy key management of existing email security protocols has
contributed to their poor deployment.

SOLUTION:

draft-iab-messaging-report-00 suggestst that this threat can be addressed
by using the DNS to provide simpler trust anchors and simpler mechanisms
for key distribution and revocation.

CONSEQUENCES:

This solution depends on the security of the DNS, so in the absence of
DNSSEC it does not provide a cryptographically secure identification of
the signer to the degree that existing protocols do. However this weaker
identity is still much stronger than most email identities currently
available, and it is probably strong enough to support new security
features within the message transport system (as opposed to archival
quality security).


THREAT: obtrusive signatures

Existing email security protocols place the signature in the body of the
message. When these messages are handled by legacy clients that do not
understand the security protocol, the recipient is presented with ugly
visual clutter or even a completely unreadable message.

EFFECTS:

Again, this has contributed to the poor deployment of email security
protocols.

SOLUTION:

Unknown header fields are usually hidden by existing MUAs. By placing the
signature in the header we can add security information to a message in a
way that is unobtrusively backwards-compatible with clients that do not
support the new security protocol.

CONSEQUENCES:

Keeping security information in the message header in a way that is
compatible with legacy clients means that we cannot support message
encryption, which necessarily requires support from the recipient's MUA
and requires that cryptographic data appears in the message body. This
is probably a useful simplification rather than a disadvantage, and in any
case encryption is still supported by existing email security protocols.


THREAT: poor scaling factors

Existing email security protocols are designed to work between inividual
users. This implies per-user scaling factors, such as the number of keys
that must be managed, and the number of software installations which must
support the protocol.

EFFECTS:

Again, this has contributed to the poor deployment of email security
protocols.

SOLUTION:

A security protocol which is designed to operate between domains has
better scaling factors. As well as the numbers being much smaller, email
system administrators are much more expert than the general user
population, and so they are better able to perform the necessary upgrades
and configuration.

CONSEQUENCES:

Simple per-domain signing is probably not sufficient to deal with some of
the more complex email usage scenarios, such as outsourced mailing list
management. Therefore a new protocol should have some support for domains
to delegate signing privileges independently of email domains used to
identify the message's author or sender.


Tony.
-- 
f.a.n.finch  <dot(_at_)dotat(_dot_)at>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
ietf-dkim mailing list
http://dkim.org