Re: [dane] draft-ietf-dane-smime and certificate discovery

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 05 February 2014 23:50 UTC

Return-Path: <viktor1dane@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 385EF1A0220 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 15:50:07 -0800 (PST)
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 FtRYNgVgT6UM for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 15:50:04 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E51A015A for <dane@ietf.org>; Wed, 5 Feb 2014 15:50:04 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DA0362AAD0D; Wed, 5 Feb 2014 23:50:02 +0000 (UTC)
Date: Wed, 5 Feb 2014 23:50:02 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140205235002.GP278@mournblade.imrryr.org>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <A1C41700-578C-45C1-9A66-ACC051970F47@gmail.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <FAB9D9AB-023B-48E3-BD26-15FC9B87FE3F@verisign.com> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
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: Wed, 05 Feb 2014 23:50:07 -0000

On Wed, Feb 05, 2014 at 03:29:29PM -0800, Paul Hoffman wrote:

> So, WG: is "DNS for delivery vs. DNS for delivery and discovery"
> a topic people want to revisit?

Since I am relatively new here, I'll ask:  What is the distinction?

My best guess is:

    - Discovery, one time lookup of data that is retained indefinitely
      and refreshed infrequently, in particular potentially beyond
      the shorter of the DNS TTL and the RRSIG expiration.

    - Delivery, lookup as needed with optional caching bounded by
      the shorter of the record TTL, the RRSIG expiration and any
      applicable local policy.

Is that about right?  If so, since TLSA in an online protocol, it
seems clear that TLSA should be "delivery".

For SMIMEA, the case is a bit less clear-cut.  Whenever one is
capable of receiving new email one is presumably online, and so
receipt of associated SMIMEA records should be feasible.  When
composing encrypted replies one would often, but not always have
a cached copy of the sender's encryption cert and one may not be
online.  

The MUA could defer the encryption step until it is back online,
but then an unencrypted copy of the message sits in the local outbox
until network connectivity is restored.  Otherwise, the user would
have to accept the risk that the most recently cached cert is no
longer valid (no way to check SMIME for a revocation either).

I don't see much of a role for SMIMEA revocations in either case.
Any time one can look-up a blacklist one can lookup a (possibly
empty) whitelist instead.

So it is not clear how "discovery" is a better protocol than
delivery.  Feels like printed credit card black-lists in the 70's
before credit card verification went online.

-- 
	Viktor.