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

Viktor Dukhovni <> Thu, 02 October 2014 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1490F1ACE39 for <>; Thu, 2 Oct 2014 16:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8cQOnCl6rA5Y for <>; Thu, 2 Oct 2014 16:07:29 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B3001ACEF9 for <>; Thu, 2 Oct 2014 16:07:25 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 0C6162AB2D6; Thu, 2 Oct 2014 23:07:25 +0000 (UTC)
Date: Thu, 2 Oct 2014 23:07:24 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [dane] draft-ietf-dane-smime
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Oct 2014 23:07:31 -0000

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

    * 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

    * 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

[ Apple's 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. ]