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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 20 October 2014 15:54 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 C35BE1A1AFD for <dane@ietfa.amsl.com>; Mon, 20 Oct 2014 08:54:51 -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 vIlvrGPSWWxl for <dane@ietfa.amsl.com>; Mon, 20 Oct 2014 08:54:44 -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 9BB981A0369 for <dane@ietf.org>; Mon, 20 Oct 2014 08:54:25 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CC632AB2B5; Mon, 20 Oct 2014 15:54:23 +0000 (UTC)
Date: Mon, 20 Oct 2014 15:54:23 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141020155423.GF19158@mournblade.imrryr.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <E507FC56-947B-4A93-AA81-F0507D2FBC69@ogud.com> <62F1DB86-59B4-4165-9AEE-82A829B6A9A9@kirei.se> <20141017150448.GV20066@mournblade.imrryr.org> <B4AE1805-22D9-4E63-A18C-1EEC55C1C2E3@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B4AE1805-22D9-4E63-A18C-1EEC55C1C2E3@verisign.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xHaX1Qi93gRP9uuOusMeCVfbSis
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: Mon, 20 Oct 2014 15:54:51 -0000

On Mon, Oct 20, 2014 at 03:24:07PM +0000, Osterweil, Eric wrote:

> For example, a single DANE TA could be used to authorized all of an
> organization?s S/MIME users, and selective ``user-no-longer-valid'' (i.e.
> revocation) entries could override this.  

The preferred way to "revoke" a DANE-TA(2) binding for a single
end-entity is to publish a DANE-EE(3) binding for that entity until
the previously issued certificate has expired.

Where normally one would have:

    _smimea._dane.example.com.               1H IN SMIMEA 2 0 1 {blob}
    <entity1-smimea-label>.example.com.      1H IN CNAME _smimea._dane.example.com.
    <entity2-smimea-label>.example.com.      1H IN CNAME _smimea._dane.example.com.
    ....
    <entity100000-smimea-label>.example.com. 1H IN CNAME _smimea._dane.example.com.

When the keys for entity42 are compromised, you publish:

    <entity42-smimea-label>.example.com.     1H IN SMIME 3 1 1 {blob}

(or perhaps "3 0 0" instead of "3 1 1" if that's more appropriate
for SMIME).  Once the compromised certificate has expired back to:

    <entity42-smimea-label>.example.com.     1H IN CNAME _smimea._dane.example.com.

This is fine for validating sender presented chains.  When looking
for a recipient key to encrypt to, an end-entity binding is
unavoidable.

> I think we are all on the same page, and perhaps the text was not clear
> enough?  Maybe it's also possible there was some misunderstanding from
> the protracted email discussion?  The revocation discussion (IIRC) really
> had to do with an assertion that TLS did not have revocation needs.

My view is that revocation is not terribly useful without accurate
signalling of when something was revoked, and whether the revocation
applies to content validated prior to the revocation.  Just publishing
a binary "revoked" bit in DNS would I think be a mistake (do more
harm than good).

With SMIME used so little, there has been little investment in
figuring out how to do revocation correctly.  Reasoning by analogy
with interactive protocols encrypting data in motion is deeply
flawed when applied to data at rest.

-- 
	Viktor.