Let me make sure I have the issue straight: A user who uses REQUIRETLS
from a location (or going through a downstream mail server) that doesn't
do DNSSEC verification will not be able to send to domains that don't
publish MTA-STS. Is that correct?
I agree, it makes sense to call this out. But also that this is probably
what the user wants: in a way, not being able to send messages under
some circumstances is a "feature" of REQUIRETLS.
-Jim
On 10/24/18 5:59 AM, Daniel Margolis wrote:
I don't disagree with the points made here. If you know you need TLS
from REQUIRETLS, and you know the desired MX identity from DNSSEC on
the MX records, you don't need DANE or MTA-STS as long as you can
validate the presented certificates. But note now that there are three
(??) ways a recipient domain can be validated for a sender who honors
REQUIRETLS. As a result, "ability to satisfy REQUIRETLS" is no longer
a property of the mailbox domain; it depends on /both/ the recipient
and the sender. For example--assuming everyone has implemented
REQUIRETLS--users of Yahoo may find that they can set REQUIRETLS on
mail sent to Yandex, but users of Zoho may find they cannot. This is a
somewhat poor user experience, though admittedly probably what the
user wants.
I would call this out in the draft. I think the UX concerns here are
worth noting, and they are in fact magnified (a trade made for more
widespread compatibility, of course) but supporting multiple authn
mechanisms.
On Tue, Oct 23, 2018 at 11:09 PM Viktor Dukhovni
<[email protected] <mailto:[email protected]>> wrote:
> On Oct 23, 2018, at 5:05 PM, Jim Fenton <[email protected]
<mailto:[email protected]>> wrote:
>
>> And yet, my preference would have been to not take this approach.
>> Rather each domain that wants to support "REQUIRETLS=YES", would
>> need to implement MTA-STS or DANE. If they already have a signed
>> MX RRset, they could often just add TLSA records and have DANE for
>> little extra effort.
>>
>> The "fly in the ointment" is that many domains are signed, but
their
>> MX providers are not, and so they would then have to implement
>> MTA-STS, just to benefit from protection against MX record forgery
>> that they already have by virtue of DNSSEC.
>
> Let's think about that case more. If the mailbox domain is
DNSSEC-signed (so we got the right MX host), shouldn't it be
sufficient for the mail server to authenticate itself with a
certificate that chains up to a trusted CA? I don't see why
MTA-STS is needed in this case.
You've missed my point, we're in agreement. What I was saying was
that *without* your proposal to let DNSSEC suffice, in the absence
of DANE for the hosting provider's MX host (if the MX host is in-house
the domain could easily also deploy DANE) a signed domain would then
need MTA-STS, but that's a silly requirement, because it just poorly
adds back what the domain already has, namely protection against MX
forgery.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/uta
--
How's my emailing? http://go/dan-email-slo
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
