Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality

"Rose, Scott W." <scottr@nist.gov> Fri, 05 December 2014 15:23 UTC

Return-Path: <scott.rose@nist.gov>
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 CACD31A899C for <dane@ietfa.amsl.com>; Fri, 5 Dec 2014 07:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 qU98rj_beQW8 for <dane@ietfa.amsl.com>; Fri, 5 Dec 2014 07:23:03 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4281A89A8 for <dane@ietf.org>; Fri, 5 Dec 2014 07:23:03 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 5 Dec 2014 10:22:52 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.377.0; Fri, 5 Dec 2014 10:23:01 -0500
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id sB5FMtdP016562 for <dane@ietf.org>; Fri, 5 Dec 2014 10:22:55 -0500
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "Rose, Scott W." <scottr@nist.gov>
In-Reply-To: <alpine.LFD.2.10.1412041127450.13902@bofh.nohats.ca>
Date: Fri, 5 Dec 2014 10:22:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <6FDA22D1-153B-4926-88D2-3A9F1942A6EF@nist.gov>
References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov> <alpine.LFD.2.10.1412041127450.13902@bofh.nohats.ca>
To: dane WG list <dane@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
X-NIST-MailScanner-Information:
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Qv-21B8fcqQCnRdo8N2ew-iRRc4
X-Mailman-Approved-At: Fri, 05 Dec 2014 09:34:49 -0800
Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality
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: Fri, 05 Dec 2014 15:23:09 -0000

On Dec 4, 2014, at 12:06 PM, Paul Wouters 🔓 <paul@nohats.ca> wrote:

> On Thu, 4 Dec 2014, Rose, Scott wrote:
>> A varient of that could be an enterprise using a local trust anchor (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all domain users), and generating encryption certs and using CU=3 since clients won't be able to perform full PKIX validation to the local trust anchor if they don't have it stored locally.  In a way, the encryption certs could be views as opportunistic S/MIME.  So you have:
>> 
>> *._sign._smimecert.example.com  IN SMIMEA  2 0 1 <blob of local TA>
>> 
>> and for each user that is allowed to accept encrypted mail:
>> <user>._encr._smimecert.example.com  IN SMIMEA 3 0 0 <blob of local TA (or self) signed cert>
> 
> What does an SMIMEA DNS record signify?
> 
> I thought it meant "you can verify signatures on received email" and
> "you can send encrypted email using this encryption key".
> 
> I do not think it can mean "this user is allowed to accept encrypted
> email". Whether or not to encrypt is a local policy of the sender. If
> and only if the sender wants to encrypt it, it will look for the
> appropriate encryption key.
> 
It would be up to the org's policy about who can accept encrypted mail, and it wouldn't necessarily be signaled by DANE, just if a client discovers a cert that it can use to send encrypted mail, it could use it.  


> I would envision an organisation to either allow individual encryption
> keys, or a global encryption key. If you use a global encryption key,
> you might still want to have individual signatures of people within
> the organisation. So I can see that as a use case.
> 
> That use case _could_ also be solved by having two keys:
> 
> <user>._smimecert.example.com  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>
> <user>._smimecert.example.com  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>
> 

True, I admit there are several ways to publish the RR's


> Where one has the signing EKU set and one has the encryption EKU set.
> 
> This is much more straight forward and prevents situations where the EKU
> and the DNS _prefix disagree and eliminates a lot of corner cases.
> 
>> The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert
> 
> It should always rely on it for CU=1 and CU=2. And CU=3 should clearly
> not be used if there is domain policy covering an individual.
> 
I was thinking this too, but it isn't in the explicit in the text right now.  The problem I see is when an org decides to use CU 3 and doesn't bother to include a keyUsage or EKU.   If that isn't the case and can be prevented with best common practices, then that is ideal.


>> , and what to do if the field is not present in the cert at all.
> 
> I would say PKIX validation determined an SMIME certificate without
> signing EKU cannot be used to verify signatures. An SMIME certificate
> without encryption EKU cannot be be used for sending encrypted email.
> (and if encryption is mandatory according to local policy, no email
> should be sent in the clear either)
> 
>> A lot of this can be done without the naming convention, but it allows more flexibility and allows for easier management for some usage scenarios.
> 
> In my experience with X.509 and IKE and various EKU's and interop, many
> vendors come up with many different EKU's related to the policy of
> authentication and encryption. I'd really prefer not to see a zillion
> _prefixes and a new RFC whenever a vendor comes up with a new EKU.
> 
I wasn't aware of that - yes that is a problem and a good argument against having DANE signal/confuse things.  

Scott

> Paul
> (and yes, I have had to do interop tests by adding 20 non-RFC EKU's to see
> if a certain phone vendor would finally use the damn certificate for IKE)

===================================
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================