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

[Stephen Farrell <[e-mail]>]

On 14/02/17 01:29, Paul Hoffman wrote:
> 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.

And for the record, I'm fine with those changes. (Though
a grammar fix may be needed, that can be done later.)

Thanks,
S.

> 
>> 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.
> 
>