Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

[Chris Newman <[e-mail]>]

 
On April 17, 2016 at 13:45:24 , Jim Fenton ([e-mail](mailto:[e-mail])) wrote:
> On 4/16/16 10:23 AM, Chris Newman wrote:
> >  
> >>> So while Viktor made a compelling case that the TLS version directive is not appropriate for SMTP relay, I think it is appropriate for the MUA STS scenario where it’s simpler to implement, where very old MUAs are in wide use requiring permissive servers, and I’d really like to be sure my client is using the stronger versions of TLS as long as I don’t have to manually configure it.
>  
> I'm a little confused by the language in section 9.1 "All [client and
> server] implementations MUST be configurable to support implicit TLS
> using the TLS 1.2 protocol or later." So why not insist in TLS 1.2 all
> the time? There must be a deployment corner case that I'm not considering.  

SSL appliance boxes tend to get updated slowly. Also the model has to cover two versions to explain how upgrading works.

> But, as you noted in section 6, the choice of TLS version isn't the only
> thing that needs to be considered. Why does TLS version rise to the
> level of importance of creating a directive, but cipher suite doesn't?  

Cipher suites are necessarily fluid and it’s not always clear whether one will be better than another indefinitely. To the extent we can have TLS stack vendors be the only people who care about what cipher suites are enabled/preferred, we’re going to have better outcomes than if we expect non-security folks to control those knobs. The primary need is the ability to turn on/off old cipher suites as dictated by a site’s interoperability vs. security balance. Client policy is more likely to cause problems than to improve security in the cipher suite area.

The TLS version, on the other hand, is where the security community really ratchets up the minimum security for TLS. Minimum version is controllable in TLS APIs, and indeed a common TLS client design error is failure to expose that control knob. Thus when SSL3 & TLS1.0 vulnerabilities became well known, it required software updates to turn those versions off in many products (rather than a configuration or policy change). Having it in the standard might encourage implementers to pay attention to that important TLS stack control knob.

> I don't see the complexity and interoperability risk associated with all
> this to be warranted by the relatively low level of security risk.  

For MUAs, this is not complex. It would be very straightforward to implement (a few lines of code) once the account confidentiality level model is implemented (which is the important part of MUA STS). I don’t see significant interoperability risk in the MUA space.

> Also, if we're talking about some unification of STS and DEEP (as
> "MUA-STS" or something, if I recall correctly), and the STS policy is
> retrieved in a "webby" manner, the policy record probably also needs to
> adhere to its own standards for TLS version, cipher suite, etc. Which
> could be problematic if an attacker can publish a record for a
> known-vulnerable cipher suite or something.  

Unification is a non-goal. Protocol/model alignment where it makes sense is the goal. I believe a strong case has been made that STS policy is very application-specific. In SMTP relay STS, the default is deliver forward with zero security and there is communication with many badly behaved peers that all have to be tracked separately. The business motivation is: 1. never bounce legitimate mail to avoid support costs and 2. generate a reputation for confidentiality whether or not that reputation is reflected in reality. The ISPs with these two motivations control their SMTP relay clients & servers. Just getting the cert checked in the most barebones fashion is going to be a difficult ask for the infrastructure. The MUA world is different. Many MUAs already support an “SSL-required” mode that checks certs — they just have no way to move from the no-SSL to SSL-required mode and no indication of which mode is active. ISPs generally don’t control which MUA the customer uses, so the ISP motivation is to make the common MUAs work well. If (and only if) the MUA provides a visual indication of the account confidentiality level, the ISPs will change to get the label. There also tend to be a lot of very old MUAs in use in some countries, so ISPs often have very permissive server configurations (e.g., likely to support TLS1.0, RC4, SHA1, etc to interoperate with old MUAs). Ratcheting up the minimum TLS version is much easier to implement in MUA STS than SMTP relay STS, and it’s more likely to actually improve security.

	- Chris