That's a long one. I have a few comments, most of them minor. I
found only one typo.
-------------------
Section 2.2.2, Regarding the problem nameservers for
largeemailprovider.com: If an insecure MX record is returned pointing
to largeemailprovider.com, skip TLSA lookup, because even if we got a
signed response, the insecure MX to the domain could have been
MITM-ed. Makes sense.
But I wonder if there might be a scenario where the insecure MX record
appears to be insecure, but is not actually. In which case the TLSA
lookup would provide security. For example, if an admin specifically
configures a mapping inside the smtpd (I think this is transport_maps
in postfix?) - this type of mapping _could_ be labeled as 'secure'
inside the data structures, because of it's origination, but this
would be more state to track through more functions. Another example
would be locally configured DNS names (smtp_host_lookup with 'native'
in postfix?) - maybe a .local domain that resolve to public IP space
or overrides in /etc/hosts. These are securely delivered even though
they're not DNSSEC.
I agree that skipping the TLSA record after getting a public insecure
MX record cannot increase security. But I don't think it decreases it
either. I think it mainly affects latency. And there may be situations
where the smtpd cannot distinguish between 'no DNSSEC and insecure'
and 'no DNSSEC but I can trust anyway.' So I would suggest a SHOULD
proceed with TLSA lookup instead of a SHOULD NOT, noting that it in
_most_ cases it won't actually increase security but we'll give it a
shot because it won't _hurt_ security either.
If there were mechanisms in a MTA to somehow flag a message as
'securely delivered', which I don't believe there are, they would not
apply.
-------------------
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
Forgive my ignorance, but these are MX records each with a 0 priority,
right? If so, maybe make it '10' and '20' as it would be more
apparent to people like me. There are at least two places this is
used.
-------------------
These paragraphs are spread around, but say the same thing.
The SMTP client SHOULD NOT deliver
mail via the corresponding host unless a TLS session is negotiated
via STARTTLS. This is required to avoid MITM STARTTLS downgrade
attacks.
...
When at least one usable "secure" TLSA record is found, the SMTP
client SHOULD use TLSA records to authenticate the SMTP server.
Messages SHOULD NOT be delivered via the SMTP server if
authentication fails, otherwise the SMTP client is vulnerable to MITM
attacks.
Perhaps the first should say behavior is defined in Section 2.3.2 (the second)?
It also seems to contradict the later paragraph in 6.1:
Unless
local policy specifies "audit only" or that opportunistic DANE TLS is
not to be used for a particular destination, an SMTP client MUST NOT
deliver mail via a server whose certificate chain fails to match at
least one TLSA record when usable TLSA records are found for that
server.
-------------------
It took me a good long time, but I finally found a typo (missing
period). This was the only typo I found.
name is based entirely on the TLSA record association The server MUST
-------------------
Section 2.3.1.3
Strong disagree with this paragraph:
SMTP client treatment of TLSA RRs with certificate usages "PKIX-
TA(0)" or "PKIX-EE(1)" is undefined. For example, clients MAY (will
likely) treat such TLSA records as unusable.
First off, I think it's inappropriate to use capital MAY in an example
about how clients might behave, immediately after saying it's
undefined. Lowercase 'may', sure, but capital implies something else.
Second off, I think it's inappropriate to suggest that clients ignore
these settings. I agree with the sentiment that it has no increase in
security. I also bet you some large corporation or government agency
somewhere has some requirement to publish CA-validated certs only, and
thus would need to publish these usages anyway.
I think it is better said that clients SHOULD process these TLSA
records and MAY treat them as the corresponding PKIX-less variants.
(And leaving it stated that servers SHOULD NOT publish these
variants.)
-------------------
Is it really necessary to include the Reference Identifier Matching in
2.3.2.3? It can't be referenced in another document? The behavior
seems different from what is actually valid in other contexts, and
omits some restricts as I understand them.
-------------------
Suppose that a DANE TLS client authenticating a TLS server considers
digest algorithm BETTER stronger than digest algorithm WORSE.
I would suggest renaming these algorithms to something like
"AlgoBetter" and rephasing it "considers a digest algorithm named
AlgoBetter to be stronger than...". This avoids the backtracking
needed to realize that BETTER is a name, and not an emphasized
adjective.
-------------------
If the client sends no SNI extension,
or sends an SNI extension for an unsupported domain, the server MUST
simply send its default certificate chain.
To me it seems it would be more appropriate to say that the server
MUST send some certificate chain, and the choice of which certificate
chain to send is left undefined.
-------------------
I can submit github PRs for these sometime next week if desired.
-tom
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
