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

[Viktor Dukhovni <[e-mail]>]

On Sun, Nov 24, 2013 at 07:42:49AM +0000, Viktor Dukhovni wrote:

> On Sat, Nov 23, 2013 at 11:35:54PM -0800, [e-mail] wrote:
> 
> > 	Title           : SMTP security via opportunistic DANE TLS
> > 	Author(s)       : Viktor Dukhovni, Wes Hardaker
> > 	Filename        : draft-ietf-dane-smtp-with-dane-04.txt
> 
> This is a bugfix update to 03.  The new material in 03 is a
> 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.