Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dane-smime-15 Reviewer: Dale R. Worley Review Date: 2017-02-26 IETF LC End Date: 2017-03-03 IESG Telechat date: 2017-03-16 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. * Technical points 1. I assume that in parallel with RFC 6698, DNAME records must be followed during SMIMEA resolution. It's not clear to me whether CNAME records must also be followed or how, given that SNAMEA records are not for host names, but their grandparent node is a host name. 2. Presumably it was deliberate not to have the first label for an SNAMEA record be the canonical UTF-8 string for the local-part, even though the DNS architecture (RFC 1035) seems to admit binary labels. 3. Presumably it was deliberate to hash using SHA2-256 truncated to 224 bits rather than use SHA-224. 4. Is it worth suggesting that some mechanism might be devised for annotating an e-mail message with the canonical form of the sender's local-part that is intended to be used to authenticate the message? The last sentence of the 1st paragraph of section 1 suggests that this is deliberately out of scope for this document, but it might be worth suggesting experimentation regarding this in section 4, which seems to be entirely about further experimentation. * Editorial/Nits Should there be an explicit statement that the resolver must follow CNAME and DNAME records? That seems to be required by RFC 6698 section A.2.1, but that requirement is buried rather deeply. Also, is CNAME following required? My vague understanding is that CNAME can only be used to alias host names, and SMIMEA records are not for host names (contrasting with the DANE records for TLS) -- though the grandparent node of any SNAMEA is a host name. Also, some adjustments of the resolution process of RFC 6698 re CNAME records were made in RFC 7671, but this draft only mentions 7671 in passing, in the introduction. It seems that it should be noted that 7671 contains a lot of operational information about DANE. 1. Introduction There are other requirements on the MUA, such as associating the identity in the certificate with that of the message, that are out of scope for this document. "that of the message" isn't quite right, as "that" is parallel to "the identity", and the message doesn't itself have an identity. More accurate would be "the purported sender of the message", as was used in 3rd sentence of the paragraph. 2. The SMIMEA Resource Record ... the semantics are also the same except where RFC 6698 talks about TLS at the target protocol for the certificate information. s/TLS at/TLS as/ 3. Location of the SMIMEA Record The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. I don't have the full background on this. My memory ends at RFC 1035: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. I suspect there is by now a defined way to have "UTF-8 labels". Given that this draft doesn't use such a mechanism, there's probably a discussion out there why just using a UTF-8 string as a label doesn't work. It would be helpful to put a reference to that discussion here, because the mechanism in the draft is doing a lot of work to avoid the seemingly obvious mechanism. 2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any whitespace (CFWS) around dots (".") is removed. Any enclosing double quotes are removed. Any literal quoting is removed. I think this could be more exactly expressed along the following lines. Given the costs of not having this implemented exactly the same way in all implementations, it's probably worth the extra words. 2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any whitespace (CFWS) around dots (".") is removed. If the local-part is quoted, the enclosing double quotes, contained FWS, and the initial backslashes of quoted-pairs are removed. (The obsolete local-part format obs-local-part is canonicalized similarly: CFWS around dots is removed and any word component that is a quoted-string is canonicalized as if it was a separate local-part.) -- 4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name. Why use "SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets" rather than "SHA2-224 [RFC5754]"? (The two aren't the same, because SHA-224 has a different IV than SHA2-256, but they seem to have the same security properties.) Is this because implementations will already implement SHA2-256 (for matching type 1)? You probably want to specify hexadecimal case here. DNS is considered to be case-insensitive, but it's probably unwise to depend on that fact. (Or is this known not to be a problem in DNS?) 7. Certificate Size and DNS The algorithm type and key size of certificates should not be modified to accommodate this section. The term "algorithm type" is not defined; what is meant here? Also, "of certificates" seems awkward; the encryption/signing algorithms and keys exist prior to the certificate which vouches for them. Perhaps: A user's S/MIME encryption/signing algorithms and keys should not be changed solely to reduce DNS RR sizes. 9. Security Considerations If an obtained S/MIME certificate is revoked or expired, that certificate MUST NOT be used, even if that would result in sending a message in plaintext. Shouldn't this be moved to section 6? This seems to be a specification, but it is not contained in the definition of the semantics. The "security considerations" section is where you would see the explanation of the reason for this specification. [END]