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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
