Hi, Thanks Dale for the detailed review and the discussion. I've had a read through the resulting thread and don't see anything that wasn't discussed in the WG that needs a major change (please do yell if I've missed something), so I'll leave this on the March 16th IESG telechat for IESG evaluation. (In part to try get this document done before I'm finished as an AD so we can cleanly close the dane WG:-) That said, I've not seen a response from the authors to the details below, and it'd be good to see that, so authors, please do reply to this and make any editorial changes needed. If you can do have those changes done by the end of Friday (or close-to) that'd be great so it's not changing while the IESG are reading it. Thanks, S. On 26/02/17 14:10, Dale Worley wrote: > 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] > > >
Attachment:
signature.asc
Description: OpenPGP digital signature