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

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 06 February 2014 02:20 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 4E5041A0266 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 18:20:52 -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 FXl7PkBGuPwB for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 18:20:50 -0800 (PST)
Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF331A0207 for <dane@ietf.org>; Wed, 5 Feb 2014 18:20:50 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLxgUsj01JGWbVY6KvjsOte5hnNRG0z@postini.com; Wed, 05 Feb 2014 18:20:49 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 s162KmcC024415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dane@ietf.org>; Wed, 5 Feb 2014 21:20:48 -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 21:20:48 -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: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgAAPoACALFgggIAABxEAgAAflQCAADGBgA==
Date: Thu, 6 Feb 2014 02:20:47 +0000
Message-ID: <19493552-CDFD-44D6-866A-74B3305073F1@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> <24074206-D8A9-48FE-AE80-46E8C21E684A@verisign.com> <20140205232336.GO278@mournblade.imrryr.org>
In-Reply-To: <20140205232336.GO278@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="us-ascii"
Content-ID: <2F0042F570DCC34C93330B4DB87475BD@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: Thu, 06 Feb 2014 02:20:52 -0000

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

> On Wed, Feb 05, 2014 at 09:30:34PM +0000, Osterweil, Eric wrote:
> 
>> 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).
> 
> Well if the DNS is not available, you won't see the DNS revocation
> either.  So I think you're imagining a situation were a client is
> often disconnected, and caches certificates.

I didn't say DNS was unavailable.  I said the RR was not available ``in DNS.''  This is a _big_ difference, as service #3 of DNSSEC is secure denial of existence.

> In that case, I would suggest the following strategy for an SMIMEA
> capable MUA:
> 
>    Each signed message received by the MUA is initially in an
>    unknown verificaiton state.  When an SMIMEA lookup is successful,
>    and returns a usable certificate the message is marked permanently
>    valid (certificate valid at time of message receipt).  The
>    certificate can be cached for the shortest of the TTL of the
>    SMIMEA RRset, the RRSIG expiration time and a configurable
>    local cache limit (suggested default 7 days).
> 
>    Each new message received generates a new background attempt
>    to determine the SMIMEA records, but if cached data is available,
>    a cached certificate can be used (lies within RRSIG lifetime).
> 
>    Likewise, outgoing mail can be encrypted to a cached certificate
>    only within its DNSSEC validity interval, but otherwise requires
>    a new SMIMEA lookup.
> 
> Basically the MUA operates with a stored (rather than in-memory)
> DANE RRset cache.

I think the above starts to address some concerns, but I think it sidesteps the initial comments I made.  There is a clear semantic we can relay w/ this new flag: ``don't use this cert for this email.''  The above seems like it is trying to address the case where we rush to use certs while they exist, and restrict use after.  I'm ok w/ that, but I think it leaves us with an inference problem instead of being specific.

<snip>

>> 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?
> 
> I don't see any reason to de-authorize by publishing a blacklist,
> when one can just simply stop publishing the record or replace a
> TA record with an EE record.

Well, what about if I run a mail domain, I issue usage type 3 certs, I don't want to run a CRL or OCSP service, and I want to remove a user account from my domain?  

To be honest, I think usage type 4 would be useful, but I'll only press more illustrative examples if the group wants more discussion?  If no one else thinks it's useful, so be it.  However, (at a high level) I do think it is important to point out that deauthorization is fundamentally different than revocation, and OCSP/CRL services have their own warts too.

Eric