Exactly right on both counts. It's quite probably working as intended, but it *is* a strange user experience. I think the only alternatives (similar to my original email) would be to not do authn at all or to dictate one specific mechanism for authn, neither of which are obviously better. So I would personally support calling it out in the draft as something to be aware of.
On Wed, Oct 24, 2018 at 7:37 PM Jim Fenton <[email protected]> wrote: > 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]> > wrote: > >> > On Oct 23, 2018, at 5:05 PM, Jim Fenton <[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] >> https://www.ietf.org/mailman/listinfo/uta >> > > > -- > How's my emailing? http://go/dan-email-slo > > > _______________________________________________ > Uta mailing [email protected]https://www.ietf.org/mailman/listinfo/uta > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > -- How's my emailing? http://go/dan-email-slo
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
