Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-04.txt

From: [email-masked]
Date: Sat, 23 Nov 2013 23:35:54 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : SMTP security via opportunistic DANE TLS
	Author(s)       : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-smtp-with-dane-04.txt
	Pages           : 20
	Date            : 2013-11-23

Abstract:
   This memo describes a protocol for opportunistic TLS security based
   on the DANE TLSA DNS record.  The protocol is downgrade resistant
   when the SMTP client supports DANE TLSA and the server domain
   publishes TLSA records for its MX hosts.  This enables an incremental
   transition of the Internet email backbone (MTA to MTA SMTP traffic)
   to TLS encrypted and authenticated delivery.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 24 Nov 2013 07:42:49 +0000

On Sat, Nov 23, 2013 at 11:35:54PM -0800, [email-masked] wrote:

> 	Author(s)       : Viktor Dukhovni, Wes Hardaker

This is a bugfix update to 03.  The new material in 03 is a
description of digest algorithm agility.

The text describing anonymous cipher support should now be more
acceptable, it does not say servers SHOULD support these, rather
server MUST NOT fail to interoperate merely because some anon
ciphersuites are offered.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 24 Nov 2013 21:28:45 +0000

> description of digest algorithm agility.

Here it is for your comments, extracted from the draft:

=== Digest algorithm agility

While RFC 6698 specifies multiple digest algorithms, it does not
explicitly specify a protocol by which the SMTP client and TLSA
record publisher can agree on the strongest shared algorithm.  Such
a protocol would allow the client and server to avoid exposure to
any deprecated weaker algorithms that are published for campatibilty
with less capable clients, but should if possible be ignored.  We
specify such a protocol below.

Suppose that a DANE TLS client authenticating TLS server considers
digest algorithm X stronger than digest algorithm Y.  Suppose further
that that a server's TLSA RRset contains some records with X as the
digest algorithm.  Suppose that for every raw public key or certificate
object that is included in the server's TLSA RRset in digest form,
whenever that object appears with digest Y (with some usage and
selector) it also appears with digest X (with the same usage and
selector).  In that case our client can safely ignore TLSA records
with the weaker digest Y, because it suffices to check the records
with the stronger algorithm X.

We take the simplest appraoch and mandate that all published TLSA
RRsets conform to the above assumptions.  Then clients can
unconditionally ignore all but the (equal) strongest digest records
with a given usage and selector.  The ordering of digest algorithms
by strength is entirely up to the client.  Only the future will
tell which algoritms might be weakened by new attacks and when.

Therefore, server operators MUST ensure that for any given usage
and selector, ALL objects with certificate association data with
that usage and selector that are published with a digest matching
type are published with the SAME SET of digests (non-zero matching
types).  In other words, for each usage and selector, the records
with non-zero matching types will be a cross-product of a set of
underlying objects and a fixed set of digests that apply uniformly
to all the objects.

Records with a matching type of "0", that publish the full object
value play no role in digest algorithm agility.  They neither preempt
the processing of records that employ digests, nor are they ignored
in the presence of any digest records.

SMTP clients SHOULD use digest algorithm agility when processing
the DANE TLSA records of an SMTP server.  Algorithm agility is to
be applied after first discarding any unusable or malformed records
(unsupported digest algorithm, or incorrect digest length).  Thus,
for each usage and selector, the client SHOULD only process any
usable records with a matching type of "0" and any usable records
whose digest is believed to be the strongest among usable records
with the same usage and selector.

The main impact of this requirement is on key rotation, when the
TLSA RRset is pre-populated with digests of new certificates or
public keys, before these replace or augment their predecessors.
Were the newly introduced RRs to include previously unused digest
algorithms, clients that employ this protocol could potentially
ignore all the digests corresponding to the currently deployed
certificates causing connectivity issues until the new keys or
certificates are deployed.  Similarly, publishing new records with
fewer digests could cause problems once the new keys are deployed.

Server operators SHOULD follow the following rules.  When adding or
removing objects from the TLSA RRset (e.g. during key rotation),
DO NOT change the set of digests used, change just the list of
objects.  When changing the set of digests used, change only the
set of digests, and generate a new RRset in which all the current
objects are re-published with the new set of digests.

The client-side of this "digest algorithm agility" protocol is
enabled by default in the first DANE for SMTP implementation.  For
key rotation to work non-disruptively server operators MUST ensure
that their TLSA records conform with the above specification.

-- 
	Viktor.