On Wed, Feb 27, 2019 at 08:18:19PM -0600, Benjamin Kaduk wrote:
> > With MTA-STS, yes, the name would have to match the certificate.
> > (Which makes deployment more difficult in some use-cases, but
> > c'est la vie).
>
> Section 2 has this nice note about "MUST verify successfully using DANE as
> specified in RFC 7672". I am demanding an equivalent level of
> specification for the previous clause, about "verify successfully in a
> trust chain leading to a certificate trusted by the SMTP client", which
> sadly lacks a current single comprehensive reference.
What's happening here is that there are three ways to satisfy the
authenticated delivery requirements, the last of which could perhaps
be made more explicit, even if largely obvious from context:
1. DANE per RFC7672
2. MTA-STS per RFC8461
3. DNSSEC-validated MX records + WebPKI authentication of the MX host.
The reason 3 is new with this specification, is that both DANE and
MTA-STS are opportunistic security, to be used when supported by
the peer and enabled at the sending system, but otherwise messages
are sent with "traditional" unauthenticated opportunistic TLS,
(perhaps even cleartext). DANE and MTA-STS therefore first and
foremost provide a more robust way to signal that TLS should be
available, and only then about how to authenticate the peer over
that expected (STARTTLS) channel.
With "RequireTLS yes", the signal that TLS should be expected, is
no longer needed, it is instead provided by the sender. Which
leaves just the authentication part, which is not viable unless the
MX hostname can be obtained securely. But once the MX hostname is
not subject to forgery, authentication is just basic WebPKI.
Which means that absent DANE, the peer can be authenticated either
once DNSSEC provides a tamper-resistant MX RRset, or MTA-STS validates
the MX RRset out of band (HTTPS).
So one way to frame the sender's decision-tree is:
1. If the MX RRset is not DNSSEC validated, use MTA-STS
2. Otherwise if the current MX host has no TLSA records,
do WebPKI by the book with the MX hostname as the
reference identifier.
3. With both DNSSEC and TLSA records present, do DANE.
What's new here is the second possibility which is not covered by
any previous SMTP security specification.
> > There is no implicit TLS for MTA-to-MTA relay, and none in the
> > foreseeable future, so this issue is moot.
>
> So why can't (4) use the string "STARTTLS" and be less confusing to the
> reader?
No objections if you feel that's less confusing, either way it is
STARTTLS. FWIW, I did not take into account the possibility of
some sort of local policy for a particular destination that routes
email via an alternate port (not 25) possibly via an SSH tunnel,
implicit TLS or IPSec, etc. Such arrangements are rare, but an
exhaustive list of all the various encrypted channels is difficult
to compile. Also, what are the requirements for authenticating an
SSH tunnel or an IPSec tunnel?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
