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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 02 October 2014 23:07 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1490F1ACE39 for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 16:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cQOnCl6rA5Y for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 16:07:29 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3001ACEF9 for <dane@ietf.org>; Thu, 2 Oct 2014 16:07:25 -0700 (PDT)
Received: by mournblade.imrryr.org (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 <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141002230724.GP13254@mournblade.imrryr.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org> <CAMaMmn=pD--mUM2oEHMWmQ7WuO_ReCZQRfTKgVpHtoXyBxj8zQ@mail.gmail.com> <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-vUQu0Ytxgwl79xad3R_yjewS2E
Subject: Re: [dane] draft-ietf-dane-smime
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=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
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.