I don't think we discussed exactly that issue. We did entertain early on the idea of having the policy in a TXT record instead of via HTTPS, but moved to HTTPS for the obvious reasons.
I do think the observation that you don't really even need the policy (except for the "mode" switch) in the event of DNSSEC validation is cool. But I'm not sure what to do with it. A new draft, as Viktor says? Sorry. Not a very constructive response. I think you have a very good point. I don't know if I would pursue it simply due to the additional complexity, however. In particular, it seems to only apply in the case where the MX is on a zone that can't/won't do DNSSEC but the mailbox domain does do DNSSEC (thus DANE doesn't work). This isn't necessarily uncommon (as small domains hosting their mail on e.g. GSuite may be in exactly such a situation), but if that's the primary application, maybe the "reverse proxy" method is in fact just as easy, no? On Wed, Nov 7, 2018 at 12:05 AM Alice Wonder <[email protected]> wrote: > On 11/06/2018 02:58 PM, Viktor Dukhovni wrote: > > > > > > Here I disagree, or misunderstand your point. With a fresh > DNSSEC-validated > > TXT record, there seems to be little reason to cache, and you even get > > downgrade protection on first contact. What you don't get is defense > from > > compromise of any of the all too many WebPKI CAs, and the weak DV domain > > verification they perform. But if that's all that's available, it is > better > > than nothing. > > > > Okay, I defer to your expertise and better grasp of the issues. > > _______________________________________________ > 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
