Re: [dane] Review of DANE SMTP draft

[Viktor Dukhovni <[e-mail]>]

On Thu, Mar 06, 2014 at 01:44:17PM +0000, Alexey Melnikov wrote:

> In the terminology section: what about no MX record case (A or AAAA only)?

Thanks.  This was a global replace error.  The term used to define
"MX Host".  All of its occurrences got replaced with "SMTP server",
no longer specific to MX hosts of domains, but the terminology is
now wrong.  I am going to just delete this dangling definition.

> In 1.3.1: why mention SMTP URIs? How would introduction of such
> URIs help with securing SMTP? I suggest you just mention that there
> is no signalling of "secure" SMTP.

There are no URIs and none are desired.  This is an attempt at a
contrast with HTTP, and yes the point is that there is no signalling
of HOP by hop security policy in the envelope address (which is
more of a feature than a bug).  I'm tweaking the text to talk about
signalling more explicitly, rather than a hypothetical URI scheme.

> In 2.2: Network address instead of MX hostname - I think this
> deserves an example.

[ Second-last paragraph of 2.2 ]

Is it not obvious that this means the misguided:

	example.com. IN MX 0 192.0.2.1.

I am not adding this yet, do others feel this really warrants more
text?

> In 2.2.3 (page 17, 3rd from the last para): and possibly other places:
> TLS server certificate matching rules should be fully specified. Use RFC
> 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify
> the rules directly.

In 6125 (where the exceptions dominate the rules) there are no
provisions for matching one of a set of candidate names.  So, I
guess, we should be more explicit about the wildcard matching
(perhaps generically in the SRV draft) and otherwise defer to
6125 for international domain names, Subject commonName vs.
subjectAltName:DNS, etc.

FWIW Postfix by default (Postini work-around) supports wildcard certificates
that match multiple DNS labels:

    http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels

The folks at Postini have a wildcard cert for "*.psmtp.com" and clients
publish MX records of the form:

    verisign.com.           IN      MX      100 verisign.com.s6a1.psmtp.com.
    verisign.com.           IN      MX      200 verisign.com.s6a2.psmtp.com.
    verisign.com.           IN      MX      300 verisign.com.s6b1.psmtp.com.
    verisign.com.           IN      MX      400 verisign.com.s6b2.psmtp.com.

I have not given much thought to writing DANE-specific rules for
SMTP TLS with respect to the mechanics of matching of any particular
candidate name against the certificate.  (To be honest, I did not
need to write any new code for this, since name matching is handled
in Postfix TLS policy generically for DANE and PKIX.  The existing
PKIX code was already flexible enough to do all the work, so this
did not cross my radar).  In

    https://tools.ietf.org/html/rfc6125#appendix-B.4

we have matching with just "*" as a wildcard (no "foo*.example.com"
or "*foo.example.com") and only for a single label.  While SMTP-AUTH
forbids chasing CNAMEs insecurely, it only works well for MSA hosts,
not MX hosts which already lose after insecure MX delegation.  With
DANE we have a secure TLSA base domain, so this does not apply.

I don't know whether the Postfix (on by default) Postini work-around
deserves IETF blessing.  Perhaps it would be better for Postini to
fix their certificates, or if they ever deploy DANE to publish only
DANE-EE(3) certs, which make the question moot.  I don't know
whether any other sites are attempting to use SMTP with wildcard
certs for multi-label sub-domains.  There is not enough authenticated
TLS happening for SMTP today to know what's out there in the wild.

> Page 22, 3rd para: please add reference for the SNI TLS extension (a
> Normative reference, because you use normative language when referencing
> the extension) and various versions of TLS.

RFC 6066 is referenced on page 6 (second last paragraph) and appears
in the References section.  Should the reference be repeated on
page 22?

> In 2.3.3: it is not clear whether the client needs to check that for every
> record covered by the WORSE hash there is a corresponding record covered
> by the BETTER hash.

This is not possible.  The records don't carry separate "instance"
identifiers that allow one to identify all the TLSA records of a
single certificate or public key.  The various digest algorithms
are not invertible!  All that the client can check is that the
number of records for the best algorithm is the same as that for
all other algorithms within each combination of usage and selector.

We may need a separate thread on pinning down algorithm agility
(unless it is good enough as-is, perhaps with clarifications if
the intent is not completely clear).

> In Section 3, last para: add "or bounced", as this can be more serious
> than just being delayed.

Fine.

> In 4.2, last para: did you mean "SHOULD"?

Perhaps so, though this may hold up publication of the SMTP draft
until the "ops" draft is also done.  We could cut/paste the relevant
text, or move it to the more generic SRV draft.

Ultimately, there is a real need for DANEbis, but it looks like it
won't move forward until there are more published and deployed
protocols, so we'll all be parroting the "missing" text in multiple
drafts, or perhaps the normative text from "ops" can be published as
a standards track "clarifications" to 6698?  Any suggestions from
the chairs?

> I've heard Not checking expiration dates in certificate - I don't think
> this was mentioned in the document.

This is in the "ops" draft, but I'll add it to the description in
the SMTP draft, after we figure out exactly what should be ignored
in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor
certs).  (Separate thread on this soon).

-- 
	Viktor.