ietf-mailsig
[Top] [All Lists]

RE: DKIM - Version

2005-07-19 10:12:36
OK here you are then:
 

Transition Management in Domain Keys Identified Mail


Phillip Hallam-Baker

Principal Scientist, VeriSign Inc.


1. The Transition Problem


One of the principle shortcomings of most Internet protocols is the lack
of an effective transition strategy for moving to new protocol version.
Most protocols incorporate version numbers that allow the protocol
version to be identified but there are remarkably few examples of their
successful use. Most cryptographic protocols support the ability to use
different cryptographic algorithms but the mechanisms proposed almost
never provide protection against downgrade attack.

The problem of managing the transition to a new version of an existing
protocol is considerably more complex now that the Internet has a
billion users. A number of protocol transitions were successfully made
during the early stages of the Web when most users made use of a small
number of software clients and were used to the need to upgrade their
software on a regular basis. Introduction of new protocol features is
considerably more difficult now that the Web browser market is
comparatively stable.


1.1 Double Ended Adoption


One of the main difficulties faced in a protocol transition is that for
the new protocol feature to be used both the initiator and the responder
in a conversation must support it.

The HTTP protocol only supports a bilateral request/response which means
that support for protocol feature negotiation is considerably more
limited. The only form of content negotiation that is practical in this
scenario is for the initiator to advertise a new capability to the
responder. If the initiator attempts to make use of a new protocol
feature there is a chance that the responder will be unable to support
it. This limits the type of protocol features that can be added.

The SMTP email protocol supports an in-band extension mechanism that
allows the initiator and responder to negotiate the protocol features to
be used. Unfortunately this mechanism can only be employed effectively
at the SMTP protocol (i.e. RFC 2821) level. SMTP is a mediated protocol
and does not operate end to end. It is not possible to use this
mechanism to negotiate capabilities at the message (RFC 2822) level.

The lack of an effective protocol negotiation mechanism leads to either
an unsatisfactory user experience or great difficulty and delay in
deployment of new features. Many of the advanced features of HTTP/1.1
are still unused many years after widespread deployment because of the
consequences of failure in the few cases where the feature is not
supported.

It is worth noting in this respect that the primary reason why DKIIM has
become necessary in the first place is that it is not possible to send
S/MIME or PGP/MIME encoded email without the risk that the recipient
will receive an unacceptable user experience.


1.2 Downgrade Attack


An important consideration in a security protocol is the risk of a
downgrade attack whereby an attacker such as a man in the middle
circumvents a security measure by removing or downgrading the security
enhancements.

Email signing currently suffers from a particularly severe form of
downgrade attack. Since there is no way to advertise the sender's policy
for applying the existing email signing solutions there is no way to
know if a lack of a signature means that the email is false or whether
it was simply unsigned. Equally a signature that uses an unknown signing
algorithm may be the result of the signer using a new algorithm or an
attacker introducing a bogus signature.


2. Transition Mechanisms


Domain Keys Identified Internet Mail provides three mechanisms that may
be leveraged to effect a protocol transition.


2.1 Security Policy Publication


The security policy record allows an email sender (or recipient) to
state the signature attributes of genuine email and the criteria for
accepting email.

For the purposes of this document we assume only that the policy record
will be published by means of the DNS and that at a minimum a text based
attribute value pair construction is supported. We also assume that this
record may be extended to include arbitrary attribute value pairs
without affecting existing semantics.

A policy specification language would ideally support the ability to
provide advance notice of transitions such as the planned introduction
or phase out of feature support.


2.2 Signature Header


The signature header contains the email signature information. As a
minimum this record must specify the data that is signed and the key
used for signing. We also assume that this record may be extended to
include arbitrary attribute value pairs without affecting existing
semantics.


2.3 DNS Key Record


The DNS key record provides a means of authenticating the signature key.
The key record may also specify the signature key value itself. 


2.4 Exceptions Report


The effectiveness of the transition mechanisms and of DKIIM itself would
be significantly improved if there was a standardized means for
reporting protocol exceptions (e.g. failed signature validation, lack of
signature, etc.) out of band. For example via the INCH/RID Web Service.

This would provide a means for parties to determine when it is practical
to phase out support for legacy protocol features or mandate support for
new protocol features.


3. Managing Transitions


While the utility of any given particular transition is debatable it is
almost certain that some transition will be necessary. Even though it is
impossible to anticipate every possible transition a transition plan
that addresses the foreseeable transitions is the best way to prepare
for the transitions that are unforeseeable.


3.1 New Signature Algorithm


In order to deploy a new signing algorithm a sender must either know
that the recipient is likely to be capable of accepting the new
signature format or send the message signed using both the new and the
old signature format.

The architecture of the email system makes it impractical to determine
the ultimate recipient of an email when it is sent. A sender that is
only permitted to choose one signature format cannot therefore determine
the format used by means of a policy publication mechanism. We conclude
that the only practical transition strategy for this case is the use of
multiple signatures on the same message using the different signature
algorithms.

Phase 0:
Emails are signed using algorithm X,

Phase 1:
Emails are signed using algorithm X for backwards compatibility and
algorithm Y for enhanced security.

Phase 2:

      Policy record informs recipients that the phased withdrawal of
algorithm X is planned.

Email recipients take notice that their email verification will stop
working for the specified sender(s) if they do not upgrade their system
for the 

Phase 3:
The use of algorithm X is withdrawn.

Determination of the appropriate moment to withdraw algorithm X may be
made by means of a reporting protocol. For example the sender policy
might request a certain proportion of recipients (0.1% or less) report
on their ability to comply with a proposed algorithm phase-out.

Requirement: The base protocol MUST allow a particular signer to add
more than one signature to a given message.


3.2 Domain Encryption


DKIIM may be readily extended to support domain level encryption using
either PGP or S/MIME as the encapsulation format. In view of the
delirious effects that perceived confusion over standards in this area
has caused in the past is strongly suggested that both message
encapsulation formats be supported.

Adding support for Domain encryption requires a means by which the
recipient can advertise support for encryption and specify the
encryption algorithm(s) and keys to be used. This may be achieved
through the definition of a security policy language for email
recipients.

Conclusion: Support for domain encryption may be effected using existing
encryption formats through a simple and compatible extension of the
policy format.


3.3 Restricted Signature Keys


In certain circumstances it is desirable to restrict the use of a
signature key to a particular account or set of accounts without going
to the level of supporting account level signing for every account. For
example an email sender might want to designate a particular key for use
in an outbound marketing campaign in such a manner that it could not be
used to forge email that appeared to come from the executive officers of
the company.

Such a restriction may be implemented by means of attributes attached to
the DNS key record. For example the key record might list the accounts
for which use is permitted.

Transition to use of restricted keys may be achieved in two ways. Either
the restriction is made advisory so that a recipient is not required to
enforce it or the key record is formatted in a manner that makes it
incompatible and hence unusable for legacy verifiers. The first
transition strategy is unsatisfactory in that it does not provide the
desired security properties and is at best able to support a reactive
security stance. The second transition strategy results in legacy
validators being unable to read the signature at all making introduction
of the feature extremely difficult.

Conclusion: It is not possible to define a satisfactory transition
strategy for use of signature key restrictions and that this feature
SHOULD therefore be supported in the base specification.


3.4 Per Account Keying and Non Repudiation


The domain signature model provides proof of origin tied to the domain.
In certain applications it is desirable to support end to end signatures
so that a particular message may be traced back to a particular
individual for purposes such as non-repudiation etc. The DNS is designed
to provide current data and does not provide archival facilities. As a
consequence the lightweight DNS based key distribution model is not
easily extended to provide long term archival support. While per account
keying may be supported through an extended use of the restricted
signature keys mechanism the full advantages of per-account keying
require the use of a Public Key Infrastructure (PKI).

DKIIM uses the DNS to effect a key centric PKI similar to that
originally proposed by Diffie and Hellman in New Directions for
Cryptography and realized in the XML Key Management Specification
(XKMS). While it may be argued that the DNS provides a sufficient
mechanism for the publication of public keys the DNS is neither designed
to be nor an adequate replacement for the complete key lifecycle
management provided by a purpose designed PKI. The DNS does not provide
a protocol for the registration, recovery or revocation of public keys,
nor is it possible to use the DNS to support a key validation protocol.
XKMS provides these necessary features and in addition supports the long
time archiving of key information required for meaningful
non-repudiation.

Extension of DKIIM to permit use of XKMS requires only a means of
specifying XKMS as the key publication mechanism. While this could in
theory be achieved by means of a DNS key record the ability to specify
that the use of XKMS as a key publication mechanism in the policy record
is preferable.

A similar argument may be made in relation to the use of LDAP or HTTP
based PKIX certificate repositories:

Conclusion: Extension to per user keying may be supported provided the
security policy record may be extended to allow the sender to specify
that keying material is published via XKMS or some PKIX repository
protocol.


3.5 Trusted Third Party Accreditation


The security value of a signature or encryption capability is
significantly enhanced if an accreditation of the key or attribute
binding may be obtained through a Trusted Third Party.

While a TTP may be expected to provide support for a key centric PKI
such as XKMS industry practice amongst TTPs is to employ X.509v3
certificates for this purpose and consequently a means of supporting
X.509v3 must be considered in the short to medium term at the very
least.

The requirement may be supported by means of an appropriate extension to
the DNS key record to alert the validator to the existence of a
corresponding digital certificate.

Conclusion: Extension to support TTP accreditation requires only
ordinary extensibility of the DNS key information record.


3.6 Accredited Attributes


An important form of accreditation in the context of domain based
signing is the ability to support accredited attributes such as a logo
or other conspicuous indicata of the message subject.

The requirement may be met by means of an appropriate extension to the
DNS key record to alert the validator to the existence of a
corresponding digital certificate with an attribute extension, an
attribute certificate or a SAML assertion.

Conclusion: Extension to support TTP accredited attributes requires only
ordinary extensibility of the DNS key information record.


4. Requirements for Transition Capability


We conclude that all the proposed transitions may be supported provided
that the following criteria are met:

*       The base specification MUST support ordinary extensibility of
the security policy and key record formats to allow the addition of
additional attribute value pairs without affecting existing semantics.
*       The base specification MUST provide support for key usage
restrictions such as requiring that a key be only used for a particular
account.
*       The base specification MUST NOT place any restriction on the use
of multiple signatures corresponding to different signers and/or
signature algorithms.

It has been asserted that the existence of multiple signatures within a
single message may lead to confusion. The author disagrees. The removal
of signature evidence is more likely to introduce ambiguity and
confusion since it is impossible to distinguish between a fake message
from one that has passed through an untrusted signer that removed the
original signature and added its own. The effectiveness of the security
policy is unnecessarily and seriously compromised to no purpose allowing
an attacker an unnecessary opportunity for a downgrade attack.

There is absolutely no reason that any ambiguity should arise that a
recipient should not be capable of disambiguating by means of the
signing party identifier. The possibility of ambiguity may be eliminated
entirely if each signer is required to provide a statement of the
signature mode as follows:

*       The base specification SHOULD provide a means by which a signer
can specify the signature mode, i.e. user, originating edge, gateway,
etc.
*       The base specification SHOULD allow a key usage restriction to
specify the permissible signature modes in which it may be employed.



-----Original Message-----
From: william(at)elan.net [mailto:william(_at_)elan(_dot_)net]
Sent: Tuesday, July 19, 2005 12:30 AM
To: Hallam-Baker, Phillip
Cc: ietf-mailsig(_at_)imc(_dot_)org
Subject: RE: DKIM - Version



On Mon, 18 Jul 2005, Hallam-Baker, Phillip wrote

I have dug out my policy paper on the subject (attached).

    2   OK      52 KB     Application, "DKIIMTransitions.doc"

I would appreciate if in the future people don't send documents in
proprietary formats to the list. There are multiple other,
better, options available such as:
  1. Formatted text (i.e. internet draft)
  2. HTML
  3. Rich Text (rtf)
  4. Postscript or PDF

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net



<Prev in Thread] Current Thread [Next in Thread>