On Tue, Mar 12, 2019 at 7:10 PM Viktor Dukhovni <[email protected]> wrote:
> > On Mar 12, 2019, at 8:01 PM, Eric Rescorla <[email protected]> wrote: > > > > I'm sorry, but I don't see how any of this is meaningfully different > from the > > situation with HSTS. In both cases, the receiving system indicates that > > the sending system ought to use secure transport, and if the sending > > system conforms to the specification providing that indication, it is > > required to use secure transport. See: > > https://tools.ietf.org/html/rfc8461#section-5 > > The difference is that MTAs with published DANE and MTA-STS policies > nevertheless in the majority of cases still accept email not only > from senders who don't do DANE or MTA-STS (and use unauthenticated > opportunistic STARTLS), but also in cleartext! > > Unlike HSTS where the port 80 website typically only serve the HSTS > policy and a redirect to HTTPS, the MTA's published DANE or MTA-STS > policy is an offer of support for security delivery to the sender, > it is NOT a mandate. > I'm not sure why this is relevant, given that an active attacker can simply continue with the HTTP connection and proxy it to HTTPS with the server. And of course in many cases the sensitive information has already been said.. The normative MUSTs in e.g. the DANE SMTP RFC are there to ensure that > senders implement DANE correctly *when* they choose to do that, and don't > do something half-baked leading to a false sense of security. > And similarly, clients can choose not to do HSTS, but when they do HSTS, there are rules for what they do. > There is no expectation that DANE preëmpts sender policy, and MTAs use > whatever rules they have for a particular "envelope" to determine the > relevant security policy. The plain language I cited, which requires the conformant client to behave a certain way. If there is some textual evidence to the contrary, please cite it. Otherwise, we just have different interpretations of the intent of this text and I don't see a reason to adopt yours. > My perspective on the SMTP security landscape is based on 18 years of > Postfix development and a decade as Postmaster at Morgan Stanley where > among other activities (email for the Google IPO) I managed mandatory > TLS peering with many business partners, and saw first hand what it > takes to deal with all the edge-cases. Email is different from the Web, > and experience learned in one doesn't always carry over to the other. > Surely you're familiar with the term "argument from authority". -Ekr > -- > Viktor. > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
