Date: Thu, 01 Feb 2018 09:29:21 +0000 From: Daniel Margolis To: khm@sciops.net Cc: draft-ietf-uta-mta-sts@ietf.org Subject: Re: draft-ietf-uta-mta-sts [-- OpenSSL output follows (current time: Thu Jun 23 17:14:01 2022) --] [-- End of OpenSSL output --] [-- The following data is signed --] Hey, You're definitely making a sane observation. This came up a bunch of times in the past; in fact, I wrote a short (and really now quite outdated) FAQ on this at one point in the now-distant past: https://github.com/mrisher/smtp-sts/wiki/Why-not-support-DNSSEC. Tldr: We did originally want to use DNS; in fact, when we were originally exploring ideas, I had originally wanted not to use HTTP at all, and just kind of use some plaintext DNS something something (say, stick a signed policy with the signature in a TXT record)--but that's not really feasible, since many DNS servers/hosts/infrastructure caps the size of/number of TXT records, so it's hard to fit the whole cert chain to use CA-signed certs to sign random blobs like that. So then the next idea was to allow people to optionally use DNSSEC to broadcast their signature--but if you can do DNSSEC, why not just do DANE? Ultimately, as problematic as it is in some ways to require web services to use STS, our conclusion (documented quite heavily in the archives of the list, though I can hardly fault you for not wanting to read through it all!) was that HTTPS was fairly accessible, with fairly well-understood semantics of cert validity and so forth. Hope that helps. Dan On Thu, Feb 1, 2018 at 2:51 AM Kurt H Maier wrote: > Is it the intention of this document to effectively require all > compliant MTAs to also implement web services? Is there a particular > reason that HTTPS is the only supported policy transport? Would the > working group be amenable to exploring DNS-only methods for expressing > MTA-STS policy? > > Thanks, > khm > [-- End of signed data --]