A slightly different view of things, inline: On 10/25/2017 11:16 AM, Viktor Dukhovni wrote:
> We're losing track of a few facts here: > > - It is not the client that has enhanced security requirements, > rather it is the recipient domain that is politely requesting > enhanced security, and the client that supports STS is typically > willing to oblige the server. I wouldn't even characterize it as a request, but rather that the recipient domain has a policy that it offers TLS to SMTP clients. It's no more of a request than the STARTTLS response to EHLO is, it's just a way of making that statement that is hopefully more resistant to intermediaries, and includes information on the certificate that should be presented in the negotiation. Even the "enforce" mode is only advisory because it will be ignored by non-STS-implementing clients. But: > THEREFORE: > > * Servers MUST NOT be picky about the minimum TLS parameters > they support. They MUST support a broad range of protocol > versions, ciphers, ... that are still used by a sufficient > fraction of fielded clients. This may change over time, > but bleeding edge security floors are NOT for SMTP. The > advice in RFC7435 about security gains being primarily a > result of raising the ceiling (not the floor) applies here. I see the "MUST NOT" here as being entirely outside the scope of STS. I agree with you that being picky is likely to cause more breakage than benefit, but deploying STS should not prohibit servers from being more picky, perhaps for a server that is only accepting mail from a specific community. > > * Clients SHOULD avoid deprecated and weak parameters that > be needed for interoperability of unauthenticated TLS with > non-STS/non-DANE servers when the server signals better > TLS support via DANE TLSA records and/or STS. We should > specify a minimum floor that servers are expected to meet > so that clients don't overshoot the server's capabilities. > Given that this is SMTP and the alternatives are no > authentication at all or even cleartext, the bar should > not be set unreasonably high. Again, since STS is not specifying TLS parameters, so it should refrain from telling the client what to do here. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
