Re: [dane] AD review of draft-ietf-dane-smime-14
"Paul Hoffman" <paul.hoffman@vpnc.org> Tue, 14 February 2017 01:29 UTC
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6F129789 for <dane@ietfa.amsl.com>; Mon, 13 Feb 2017 17:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 81N4eQJFUaJd for <dane@ietfa.amsl.com>; Mon, 13 Feb 2017 17:29:57 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 6CF021294CF for <dane@ietf.org>; Mon, 13 Feb 2017 17:29:57 -0800 (PST)
Received: from [10.32.60.18] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v1E1SX8M042868 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Feb 2017 18:28:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.18]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Mon, 13 Feb 2017 17:29:49 -0800
Message-ID: <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org>
In-Reply-To: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie>
References: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5344)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/k8hjn2NSF5_iQISA7bYtY4rFihg>
Cc: dane <dane@ietf.org>
Subject: Re: [dane] AD review of draft-ietf-dane-smime-14
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 14 Feb 2017 01:29:59 -0000
On 7 Feb 2017, at 8:12, Stephen Farrell wrote: > I've done my AD review of this draft. My own comments > on the content are below (the one I'd most like to > see fixed is the "escrow" stuff) and are ok to be > handled along with other IETF LC comments. We decided to take these on now, before the IETF LC. > However, before I start IETF LC I would like to be > sure that the WG are ok with the IPR declaration [1] > filed in 2014 that said "Licensing Declaration to > be Provided Later." I think 2017 is "later" enough > to ask whether that the WG (via the chairs) explicitly > declare that they are ok that this has yet to be > clarified. Warren has stated the question explicitly, and we await the response. --Paul and Jakob ====================================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-15.txt Pages : 11 Date : 2017-02-13 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dane-smime-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15 ====================================================================== > - abstract: Someone will want DANE expanded. Better to avoid > the acronym maybe. Done. > - intro: "Some people want..." is odd - that is not a > technical justification and the entire paragraph is not that > convincing. I'd say deleting that para would be better. Or > add a real justification for the experiment which I think > relates more to attempting to mitigate the difficulty of > finding certs from outside the enterprise than anything else. Many people here liked the justification, but we agree that your justification is a good one as well. Added. > - intro: I'd suggest adding a sentence about how this is > similar to RFC7929. As a reader, I'd find it odd to only find > that out later. Done. > - section 3: This is the same idea as in RFC 7929 right? > (Other than _smimecert I mean,) If so then saying so is right > as it'll help with IETF LC and IESG review and for > developers. If those differ, then saying how and why I think > would be needed. Done. > - section 4: Please check whether this is all fine when also > considering draft-ietf-lamps-eai-addresses (also in IETF LC). > That check may need to wait a little bit until we're done > with the LC comment handling for the LAMPS deraft. The current text is "all fine" with the LAMPS draft. > - Section 9: the discussion of an MTA doing the outbound > encryption seems a bit theoretical - I don't recall that > being dnoe in reality except maybe in very special cases like > nested smime, or military messaging. Am I wrong about that? Yes, you are. There have been products doing this for many years (possibly more than a decade). Having said that... > - section 9: I think the text about escrow would be better > after the current last para (where you call out the danger of > bad public keys being put in the DNS), and this (escrow) > ought be described as a special case of that attack, where > the attacker is the organisation itself. (While there are > cases where the organisation doing this is not intended as an > attack, were it done for most DNS names, it would mostly be > an attack, and is not distinguishable from an attack for the > sender, so therefore it ought IMO be considered an attack.) Yes, good call. Done. > - section 9: s/MUST not/MUST NOT/ or I-D nits complains And we must keep the tool happy, mustn't we? Done. > - section 11: I-D nits complains, maybe calling this > "normative references" would help, but in any case, please > consider/fix this. The tool is wrong, but we can fix it easily anyhow. Done.
- [dane] AD review of draft-ietf-dane-smime-14 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-smime-14 Paul Wouters
- Re: [dane] AD review of draft-ietf-dane-smime-14 John Levine
- Re: [dane] AD review of draft-ietf-dane-smime-14 Paul Wouters
- Re: [dane] AD review of draft-ietf-dane-smime-14 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-smime-14 John Levine
- Re: [dane] AD review of draft-ietf-dane-smime-14 Marc Groeneweg
- Re: [dane] AD review of draft-ietf-dane-smime-14 Warren Kumari
- Re: [dane] AD review of draft-ietf-dane-smime-14 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-smime-14 Warren Kumari
- [dane] free wasRe: AD review of draft-ietf-dane-s… D S Misell
- [dane] free for use was Re: AD review of draft-ie… D S Misell
- Re: [dane] AD review of draft-ietf-dane-smime-14 Warren Kumari
- Re: [dane] AD review of draft-ietf-dane-smime-14 Paul Hoffman
- Re: [dane] AD review of draft-ietf-dane-smime-14 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-smime-14 Stephen Farrell
- Re: [dane] AD review of draft-ietf-dane-smime-14 Warren Kumari