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

[Paul Wouters <[e-mail]>]

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.

> 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.

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

> 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.

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)

> 3. Presumably it was deliberate to hash using SHA2-256 truncated to
> 224
> 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.

> 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 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)

> 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.

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


> * 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.

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.

> 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.

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

Paul