Re: [dane] draft-ietf-dane-smime

[Viktor Dukhovni <[e-mail]>]

On Thu, Oct 02, 2014 at 03:12:09PM -0700, Paul Hoffman wrote:

> This is not to say that TLSA/SMIME should not have the feature of carrying
> "this certificate was revoked" information; the WG may want that. But it
> seems weird, at least to me, that this feature could be considered only
> for S/MIME.

There is an underlying difference that may drive a need for DANE
revocation in SMIME, while DANE revocation remains pointless with
TLS.

    * With TLS communication is real-time, and keys authenticate
      data in motion.  There is no need to revoke keys held by the
      server yesterday once they are no longer published as valid
      today.

    * SMIME encrypts data at rest.  It is not uncommon to access
      messages long after the initial delivery.  If a signing key
      was valid at the time at which the message was initially
      received, the message is authentic.

Which raises an interesting problem.  Since the proposed TLSA RR
does carry a revocation start time, it invalidates *all* past
traffic, also covering the time at which the key was not invalid
or compromised.

To handle revocation correctly with SMIME, the revocation RR would
need a more structured association data (to include a revocation
start time).

Note that there is little need to revoke non-signature keys, just
don't deliver email to the no longer affiliated recipient.  In fact
removing all email encryption keys for a particular recipient risks
rather unpleasant consequences for email security when sensitive
email is sent to multiple recipients.  There may be MUAs that as
a result send cleartext to at least that recipient or perhaps all
recipients.

[ Apple's mail.app automatically enables least common denominator
security when sending mail to multiple recipients, so email is only
encrypted when encryption keys are available for all recipients.
So one would have to be ever vigilant when composing email, to make
sure the security indicators are set to one's satisfaction. ]

-- 
	Viktor.