Re: [dane] [Gen-art] Review of draft-ietf-dane-smime-15

[[e-mail] (Dale R. Worley)]

Dale Worley <[e-mail]> in his review:
> 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.  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.

>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
    ; [e-mail]
    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