Re: [dane] AD review of draft-ietf-dane-smime-14

["Paul Hoffman" <[e-mail]>]

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.