Review of draft-ietf-dane-smime-15

[Dale Worley <[e-mail]>]

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]