On April 17, 2016 at 13:45:24 , Jim Fenton
(fen...@bluepopcorn.net(mailto:fen...@bluepopcorn.net)) 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
