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

Agreeing with Eric's point to ensure the UC 4 discussion doesn't focus on certificate revocation. 

Use case 4 for SMIMEA does not revoke a certificate. Rather, the domain revokes an S/MIME user. In contrast to any evidence the user has to claim association, the domain is positively stating that user X is not valid for SMIME applications. I consider that substantially different from the absence of a DANE record (or addition of a bogus record to force validation failure). 

WG can decide on the merits.

Todd

-------- Original Message --------
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
From: "Osterweil, Eric" <eosterweil@verisign.com>
Date: Wed, February 05, 2014 9:20 pm
To: "<dane@ietf.org>" <dane@ietf.org>

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

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane