On 14/03/2014 05:23, Viktor Dukhovni wrote:
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.
Ok.
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.
Ok.
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.
No, it is not obvious, otherwise I wouldn't have asked.
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.
I am not sure I understand. If there are multiple subjectAltName values
of the same type, any match works. Unless you mean something else.
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,
I think so, yes.
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 general, I prefer when references are repeated.
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.
I think your current text can be misinterpreted that such validation is
allowed. Use of normative language didn't help. I think I interpreted
some of the requirements as applying to SMTP clients, where they applied
to ISPs.
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.
Thank you.
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).
Ok. If you are departing from RFC 5280, they you should state all new
requirements.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
