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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 02 October 2014 22:12 UTC

Return-Path: <paul.hoffman@vpnc.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 0D20A1A03D0 for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 15:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 OmSLGGe-rCjI for <dane@ietfa.amsl.com>; Thu, 2 Oct 2014 15:12:16 -0700 (PDT)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051C91A023E for <dane@ietf.org>; Thu, 2 Oct 2014 15:12:15 -0700 (PDT)
Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s92MCBcc011960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 15:12:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAMaMmn=pD--mUM2oEHMWmQ7WuO_ReCZQRfTKgVpHtoXyBxj8zQ@mail.gmail.com>
Date: Thu, 2 Oct 2014 15:12:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <09E89369-55B5-4013-A8A1-D905C966997C@vpnc.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org> <CAMaMmn=pD--mUM2oEHMWmQ7WuO_ReCZQRfTKgVpHtoXyBxj8zQ@mail.gmail.com>
To: Doug Montgomery <dougm.work@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ocZqYEozHLxoupqhdKytNx-3A7M
Cc: dane WG list <dane@ietf.org>
Subject: Re: [dane] draft-ietf-dane-smime
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 22:12:21 -0000

On Oct 2, 2014, at 1:56 PM, Doug Montgomery <dougm.work@gmail.com> wrote:

> I am a little confused as to why we seem to couple the use case of key discovery and distribution in TLS to the use case for email/network-identity.   These seem to be very different use cases to me.
> 
> I looked back at two years of data.   My own, mid-size (3K staff) organization revokes on average 165 net-identities a month.

This is literally the first data I have seen that indicated that email certs were revoked for other than far edge cases. (I'm assuming that you are equating "net-identities" and email certs...)  Thanks for the data.

But, having said that, NIST isn't a typical organization. The fact that you revoke more than half of your S/MIME certs per year is surprising to me, but that may be because I am not familiar with the policies you used.

> As far as I know we have never revoked our TLS cert ... 

Right: TLS certs are rarely revoked. This can be seen by looking at the CRLs from major CAs. However, looking in those same CRLs shows nearly no S/MIME certs revoked either.

> I know of other industry sectors attempting to develop rather complex pub/sub architectures to signal changes in status of email identities from large mailbox providers to other users/uses of the ID. 

This seems different from what you said above. In a pub/sub architecture, there is no reason to revoke the old cert when an individual gets a new identity because the individual still controls the private key of the earlier identity. In other pub/sub systems I have seen, they use short-lived (~1 month) certs and issue new ones for "continuing" usage, so no revocation is needed.

> Overly coupling the use cases and requirements between these uses seems to be a red herring to me.    Maybe we should turn the question around and ask for an explanation why the use cases for TLS should impact the requirements for SMIMEA?

Or, based on what Jakob and I suggested, why shouldn't features that are needed for either use case be shared?

> On Thu, Oct 2, 2014 at 5:00 PM, Jakob Schlyter <jakob@kirei.se> wrote:
> On 2 okt 2014, at 22:56, Doug Montgomery <dougm.work@gmail.com> wrote:
> 
> If you trust in DANE, and the certificate is no longer published in DNS, it is not valid - no revocation is needed. If you do not trust in DANE, normal/legacy revocation procedures (OCSP/CRL) applies.

On Oct 2, 2014, at 2:05 PM, Doug Montgomery <dougm.work@gmail.com> wrote:

> And how is that definitively distinguishable from that email identity never having a CERT in DANE in the first place?
> 

It completely depends on whether the enterprise is using SMIMEA for certificate discovery or key distribution. Our draft explicitly states that it is aimed at the latter, but allows the former. Given that the use case in the introduction is for keys, not certificates, the lack of presence in the DNS makes the key invisible.

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.

--Paul Hoffman