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

[Stephen Farrell <[e-mail]>]

Hi,

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.

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.

Cheers,
S.

[1] https://datatracker.ietf.org/ipr/2468/

- abstract: Someone will want DANE expanded. Better to avoid
the acronym maybe.

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

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

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

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

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

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

- section 9: s/MUST not/MUST NOT/ or I-D nits complains

- section 11: I-D nits complains, maybe calling this
"normative references" would help, but in any case, please
consider/fix this.