Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

"Osterweil, Eric" <eosterweil@verisign.com> Wed, 05 February 2014 21:30 UTC

Return-Path: <eosterweil@verisign.com>
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 D079D1A020D for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 13:30:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 YvEAIk6fmyZJ for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 13:30:36 -0800 (PST)
Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81F1A01D1 for <dane@ietf.org>; Wed, 5 Feb 2014 13:30:36 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUvKteySefFyvY9NbDd2m7ra4LxJbaPzZ@postini.com; Wed, 05 Feb 2014 13:30:36 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s15LUZp2016187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dane@ietf.org>; Wed, 5 Feb 2014 16:30:35 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 16:30:34 -0500
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: "<dane@ietf.org>" <dane@ietf.org>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAABxEA
Date: Wed, 5 Feb 2014 21:30:34 +0000
Message-ID: <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <A1C41700-578C-45C1-9A66-ACC051970F47@gmail.com> <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org> <20140205210516.GN278@mournblade.imrryr.org>
In-Reply-To: <20140205210516.GN278@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <D664E14CAC0AA74F90B5CB92B20507A2@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
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: Wed, 05 Feb 2014 21:30:40 -0000

On Feb 5, 2014, at 4:05 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote:
> 
>>> 2. a new CU value for "revoked" to indicate that this user's
>>> certificates have been revoked.
>> 
>> We considered things like this for TLSA, and the WG seemed very
>> hesitant to have the DNS be used as a second, unofficial revocation
>> mechanism. For instance, what would it mean for the DNS to say that
>> an S/MIME cert is revoked, but when the user pulls a fresh CRL,
>> the cert isn't there? The best we might do is to have a signal for
>> "go refresh your revocation view" in the DNS, but that seems like
>> very marginal value.
> 
> I strongly support Paul's comment.  Unlike stale on-disk certificates
> held by third-parties, published DANE records (SMIMEA, TLSA, ...)
> are maintained by the subject's domain and can be presumed *current*
> when the publishing domain is not negligent.
> 
> Therefore, there is no need for a fragile blacklist mechanism.
> The DANE data in DNSSEC is a comprehensive whitelist.  Every
> certificate not listed in DANE is the wrong certificate, unlike
> CRLs DANE fails closed.

Hey Viktor,

So, I worry that this relies on implicit assumptions being made about processing being done on the MUA (RP) side.  If something is not available in DNS, does that mean I shouldn't use a cert I may already have in hand, I shouldn't fall back to AD, I shouldn't use a previously seen value, etc… How do I know the domain was ever serving SMIMEA if there is nothing in there now?  I suppose we could conflate deauthorization of certs with revocation of certs.  However, I was suggesting that we _could_ use this opportunity to express an unambiguous piece of evidence that clients should use SMIMEA-processing, and should _not_ use a specific cert (even though it may not be universally revoked).

> When the DANE associated data published for a user is a CA that
> signs multiple EE certs and a particular user's keys need to be
> revoked, the simplest solution is to publish an EE association for
> that user until the revoked certificate expires.  Either way there
> is a special EE DANE record for the user in question, but one or
> more valid EE certs are more useful than a list of invalid EE certs.

As I think you said above, ``DANE records (SMIMEA, TLSA, …) are maintained by the subject's domain and can be presumed *current* when the publishing domain is not negligent.'' I think it's a nice option to give DNS provisioning systems to set a flag in an RR that deauthorizes a cert w/o having to have the CA issue a new association.  Perhaps I'm off here, but it seems far more complicated from an operational perspective to have to hop through a CA and get something issued in order to deauthorize a cert rather than just updating the RR, no?

Eric