(Sorry, "frontage" was a Swype typo. I meant "deliberate")
The intent of this proposal itself is to resist downgrades and *deliberate* mis-routing of messages /m --- Mark Risher | Google | 650-253-3123 On Apr 4, 2016 11:03 AM, "Mark Risher" <[email protected]> wrote: > >> Do you really think an end-user can understand what it means if the MTA > will transport encrypt the next hop of mail relay but can say nothing about > relay hops after that or how the mail is handled by either service > provider? Perhaps I’m missing the motivation for doing this, can you > explain why this is useful? > > The intent of this proposal itself is to resist downgrades and frontage > mis-routing of messages. I agree users will not understand this, and any > effort for communicating encryption status covering the entirety of the > journey from user to user would require additional work beyond STS (such as > DEEP, REQUIRETLS, and other proposals). > > >> I’ve seen few DNS additions deploy effectively, and I’ve seen a bunch > of SMTP extensions deploy effectively. > > Can you share examples of each? We chose DNS over the new verb for ease of > deployment; one example is the rates of adoption of SPF (which only > requires DNS updates) versus DKIM. > > Thanks for the feedback. Looking forward to the face to face in a few > hours, > /m > > --- > Mark Risher | Google | 650-253-3123 > On Apr 4, 2016 10:44 AM, "Chris Newman" <[email protected]> wrote: > >> On April 4, 2016 at 2:42:15 , Daniel Margolis ([email protected]) >> wrote: >> >> Thanks for the clarification. >> >> Sounds like a feature to me. Having MUAs do insecure DNS lookups (which >>> is what they’d probably do) and make misleading assertions about relay >>> security (which couldn’t be made even if DNSSEC/HTTPS was employed to trust >>> the STS information, given that forwarding is in the infrastructure and all >>> that). If you want to have MUAs make assertions, you’re moving in the >>> direction of the SMTP extension draft, and as Victor pointed out, the >>> infrastructure is going to ignore even those assertions under some >>> circumstances if that were to deploy. >> >> I am (perhaps parochially) thinking mostly about webmail systems where >> the MUA and the sending MTA are mostly the same piece of infrastructure. So >> my real goal is for the MTA to be able to tell the MUA at compose time that >> it has a policy for the recipient domain and can guarantee certain >> behavior. >> >> Do you really think an end-user can understand what it means if the MTA >> will transport encrypt the next hop of mail relay but can say nothing about >> relay hops after that or how the mail is handled by either service >> provider? Perhaps I’m missing the motivation for doing this, can you >> explain why this is useful? >> >> In this context, I think having policies be per-domain is important, but >> as you note, you could have a policy semantic which allows a single MX to >> communicate a domain-wide policy even with an in-band channel. >> >> > Your suggestion, in that light, should be interpreted to say that >>> > the STS URI should be used to only secure the routing information >>> > (security for MX records via HTTPS rather than DNSSEC), and that >>> > once the routing information is secured, security policy for the >>> > given relay be in-band via SMTP and modeled on DEEP. >>> >>> Mostly yes. I’d also want to consider an optimization to skip the HTTPS >>> step for self-hosted domains just to reduce overall new traffic. >> >> >> To clarify a bit the individual steps needed, then, it seems like you're >> proposing that given the following stages: >> >> 1. Routing information: What MX hostnames are expected >> 2. Authenticating the MX: Determining that the server TLS cert matches >> 3. Policy: Ensuring the minimum level of transport-layer encryption >> >> You propose to put #1 in either DNSSEC or HTTPS (with an optimization to >> use in-channel in place of HTTPS if the MX domain matches the email domain) >> and #2 and #3 in the SMTP exchange? >> >> Basically right. >> >> But this doesn't necessarily eliminate the extra DNS or HTTPS lookup (at >> least in the case where the MX domain does not match the email domain), >> right? You still need to get the routing information somehow, and we're >> still trying to make this viable for domains that can't yet deploy DNSSEC. >> So in that light, you're proposing that all domains would need at least the >> SMTP in-band exchange and that some domains would also need step #1 to be >> done over HTTPS--meaning that sending domains would have to still support >> both options, right? >> >> Presuming there is WG rough consensus that use of HTTPS meets the >> cost/benefit cutoff when compared to DNSSEC, then yes that is correct. >> >> I can see the appeal of doing much of this in-band given that it's >> consistent with what DEEP proposes, but I'm still concerned that if we need >> *also* support out-of-band, we're just increasing complexity. What do >> you think? >> >> As long as the only out-of-band is verification of routing information >> and not policy, then I don’t see it as increasing complexity. Indeed it’s a >> somewhat more conservative approach to architectural cost (trying to >> minimize use of extra packets and protocols when performing the core SMTP >> relay operation). >> >> But I’ll admit I have some experiential bias in that I’ve seen few DNS >> additions deploy effectively, and I’ve seen a bunch of SMTP extensions >> deploy effectively. >> - Chris >> >> On Mon, Apr 4, 2016 at 6:27 AM, Chris Newman <[email protected]> >> wrote: >> >>> On April 1, 2016 at 19:18:31 , Viktor Dukhovni ([email protected]) >>> wrote: >>> >>> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: >>> >>> > I feel very strongly that policy for SMTP relay should be advertised >>> by >>> > SMTP and protected by SMTP TLS. Doing anything else creates a much >>> larger >>> > attack surface on the policy information and is both more complex and >>> less >>> > secure. The preferred mechanism to sign SMTP relay routing (DNS MX) is >>> > DNSSEC. I'm open to proposals for alternate mechanisms to sign MX >>> record >>> > information due to the difficulty of deploying DNSSEC, but such >>> mechanisms >>> > should not be confused with security policy. >>> >>> Unfortunately, in MTA-to-MTA SMTP, the receiving SMTP server has >>> no idea what domain the sending SMTP client wants to deliver mail >>> to at the time that it advertises its ESMTP extensions in the EHLO >>> response. >>> >>> This correctly identifies a key difference between SMTP relay and SMTP >>> submission. I had missed this, thank you for raising it! >>> >>> For SMTP submission, there’s an early-indication of domain ownership >>> from the mandatory user authentication (multi-domain hosting services tend >>> to use email address as user name to get this benefit). For SMTP relay we >>> have no mechanism to indicate the intended domain so to handle the case of >>> a multi-domain hosting service that offers different policies for different >>> domains we’d need to add a way to communicate intended domain early. This >>> can be done with an SMTP verb (adding a round trip) or by using TLS ALPN or >>> something similar (no new round trip). >>> >>> For this (and other related) reasons, in-band SMTP security policy >>> can only be communicated for the given SMTP server, and not the >>> recipient domain. >>> >>> I’m not convinced this is true. I’d like to hear those other reasons. >>> >>> A relay MTA MUST NOT make any conclusions about recipient domain >>> security based on security policy advertised by a particular MX >>> host. An individual MX host cannot advertise security policy >>> (implicitly) for every single domain it happens to receive mail >>> for, except for future relaying via that *same* MX host. >>> >>> If the MX-from-DNS isn’t trusted, then no policy can be trusted. But >>> STS-from-DNS has the same issue. >>> >>> To secure SMTP relay traffic to a recipient domain, the routing >>> needs to be secured by some means. STS (with sensible modifications) >>> proposes doing so via an HTTPS well-known URI associated with the >>> recipient domain. This is achieved via DNS-based signalling of >>> the existence of the STS well-known URI, and likely DNS-based >>> signalling that a cached policy is stale and should be refreshed. >>> >>> Your suggestion, in that light, should be interpreted to say that >>> the STS URI should be used to only secure the routing information >>> (security for MX records via HTTPS rather than DNSSEC), and that >>> once the routing information is secured, security policy for the >>> given relay be in-band via SMTP and modeled on DEEP. >>> >>> Mostly yes. I’d also want to consider an optimization to skip the HTTPS >>> step for self-hosted domains just to reduce overall new traffic. >>> >>> Note that consequently, a domain would be able to downgrade to a >>> non-TLS provider, by serving a routing-only policy that references >>> new MX hosts that don't support a new relay-MTA flavour of DEEP. >>> >>> We decide in the specification whether the policy attaches to the domain >>> or the SMTP hostname. This is a design choice. >>> >>> Also, when a sending relay sees new MX RRs incompatible with a >>> cached routing policy, it would be able to refresh that policy, >>> (provided the well-known STS URI is still up and running) and >>> deliver via the subset of MX hosts that match the refreshed policy. >>> >>> This all follows from a conclusion I don’t agree with. >>> >>> [ MX hosts that don't match the policy MUST NOT be ignored when >>> doing relay loop elimination. They would have to be treated >>> as though connections to them are failing, not as though they >>> weren't part of the MX RRset. ] >>> >>> Once policy is latched for a domain, any SMTP relay not complying with >>> the policy is a failure. We’ll want to make sure we get the 4xx vs. 5xx >>> rules right in the spec for this. >>> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> >> >> >> >> >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> >>
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
