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

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

Paul Wouters <[e-mail]> writes:
> Regular processing rules for CNAME and DNAME apply - I don't think it
> 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.

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

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

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

That makes sense.

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

"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