Subject: [dane] Review of draft-ietf-dane-smime-15

From: Dale Worley <[email-masked]>
Date: Sun, 26 Feb 2017 06:10:47 -0800

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]

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 26 Feb 2017 19:44:39 -0500

>    The DNS does not allow the use of all characters that are supported
>     Although labels can contain any 8 bit values in octets that make up a
>     label, it is strongly recommended that labels follow the preferred
> I suspect there is by now a defined way to have "UTF-8 labels". Given
> 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

>From draft-ietf-dane-smime-15:

> 9.2.  Email Address Information Leak
> 
>    The hashing of the local-part in this document is not a security
>    feature.  Publishing SMIMEA records will create a list of hashes of
>    valid email addresses, which could simplify obtaining a list of valid
>    email addresses for a particular domain.  It is desirable to not ease
>    the harvesting of email addresses where possible.
> 
>    The domain name part of the email address is not used as part of the
>    hash so that hashes can be used in multiple zones deployed using
>    DNAME [RFC6672].  This makes it slightly easier and cheaper to brute-
>    force the SHA2-256 hashes into common and short local-parts, as
>    single rainbow tables [Rainbow] can be re-used across domains.  This
>    can be somewhat countered by using NSEC3.

After thinking about this more, it seems to me that the draft is
suffering from conflicting requirements.  On one hand, it wants to not
have the SMIMEA records provide a complete list of local-parts for the
domain name.  On the other hand, simply hashing the local-parts does not
provide enough protection of the local-parts because one dictionary can
be used to attack every domain that uses SMIMEA.  And hashing the
local-parts with the domain name makes it impossible to present the same
set of SMIMEA records for several domain names (that are e-mail
equivalent) using DNAME records.  This, I think, leads to justifying
using hashes as labels for the RRs even though the local-parts are
encoded in UTF-8, and could be used as labels themselves.

It seems to me the way out of this conflict is to salt the hashes of the
local-parts.  That is, each domain has a salt value of e.g. 128 bits (16
octets) which is hashed with the local-part to produce the label for the
RR.  The natural way to distribute the salt is in an RR attached to the
_smimecert domain (which ensures that several domains can use DNAME to
redirect to one tree of SMIMEA records), and it seems that an easy way
to do that is to use an SMIMEA RR with another "certificate usage" value
(presumably 4) to specify that the "certificate association data" field
holds the salt value:

    $origin example.com.

    ; salt
    _smimecert IN SMIMEA 4 0 0 0f215f3ab4a8bd21b831c8316379d5b0
    ; [email-masked]
    51dfb169b7e8f5eeb4c853bf2cc2d9481cb6e9f3bd156afeb3b1cf42._smimecert (
        IN SMIMEA 0 0 1 
        d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 )

It would even be upward-compatible from the current system if we defined
that if there was no SMIMEA record for the _smimecert domain, then the
hash is unsalted.

Dale

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Feb 2017 14:26:13 -0500 (EST)

On Sun, 26 Feb 2017, Dale Worley wrote:

I'm not an author but I am the author of the similar OPENPGPKEY RFC-7929
which actually went through all the discussion on the same matters
you raise. The smime draft waited for that discussion to finish and
for 7929 to be published so it could re-use the same text and methods.

> not for host names, but their grandparent node is a host name.

Regular processing rules for CNAME and DNAME apply - I don't think it
requires additional text.

> though the DNS architecture (RFC 1035) seems to admit binary labels.

Yes, you can find 100+ messages in the archive or you can listen to
a few hours of heated debate at some of the previous DANE IETF
meetings. (So heated in fact, that I'm not even comfortable giving
you a 1 line summary)

> bits rather than use SHA-224.

Yes, the Microsoft crypto api lacks support for SHA-224. We did want
the shorter length so SHA256 truncated was chosen.

> local-part that is intended to be used to authenticate the message?

The SMTP people raised strong objections about interpreting anything
as this is forbidden by the SMTP specifications. You will also find
dozens of messags and recordings of meetings in the archive that lead
to the current compromise text (which was also used in OPENPGPKEY, RFC-7929)

> to be entirely about further experimentation.

I don't think you will find anyone willing to restart that battle.

> grandparent node of any SNAMEA is a host name.

CNAMEs can be used for most RRTYPEs (excluding NS, SOA, CNAMEs) and it
might be that people will have multiple email addresses where they want
to prevent duplicating long blobs of certificates in a zonefile. So
CNAMEs are very useful.

> 7671 contains a lot of operational information about DANE.

The bulk of that relates to the TLSA record, which doesn't apply here.

Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 28 Feb 2017 15:33:42 -0500

> requires additional text.

OK, I've used CNAME records but wasn't that familiar with the
specifications.  After reading in the RFCs, it looks like resolvers are
requied to follow CNAME and DNAME records, so those are invisible at the
application level.

> meetings. (So heated in fact, that I'm not even comfortable giving

"Here be dragons."

Well enough.  Actually, I thought about this issue some more, and that
led to my followup e-mail.  I think there is a real desire to not have
the DNS provide a direct catalog of valid e-mail addresses, but it
conflicts with the weak security of non-salted hashes.  As I said in
that e-mail, I think this could be improved by providing a hash in a DNS
record, which would mean that hashes would be well-justified as
providing substantially more privacy/security than direct UTF-8 (or
base64 or anything reversible).

> the shorter length so SHA256 truncated was chosen.

That makes sense.

> to the current compromise text (which was also used in OPENPGPKEY, RFC-7929)

"Here be dragons."

Though I was thinking of a message header, not a feature of SMTP.  But
no doubt people will start experimenting with that anyway.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 28 Feb 2017 15:39:46 -0500

[email-masked] (Dale R. Worley) writes:
> [How about salting the hashes?]

OK, this has been discussed...

Dale

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Feb 2017 17:03:30 -0500 (EST)

> base64 or anything reversible).

I don't think that justifies differentiating the lookups of OPENPGPKEY
versus SMIMEA records. So even if I agreed with you, I think it is
too late to change this.

But I also do not agree :) Email addresses are not secrets. The only
difference between publishing or not publishing OPENPGPKEY or SMIMEA
records is that the spammer can do an offline versus an online attack.
And with easilly available botnets these days, I don't think that
makes any meaningful difference.

Paul

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2017 05:05:24 -0000

>versus SMIMEA records. So even if I agreed with you, I think it is

They're experiments.  I'd think it'd be useful for the experiments to
see whether salted or unsalted hashes work better (or worse.)

R's,
John