Hi, >> Section 3.2 still treats SSL 3.0 differently to TLS 1.0. Why is it >> ok to fall back to TLS 1.0 but not SSL 3.0 if both offer the same >> security? > > This is a good question. I believe the answer is, because much of > the server population still only supports TLS 1.0, and if we > recommend otherwise, the recommendation will be ignored for > (justified) interoperability reasons. But I may be wrong about the > prevalence of such servers.
Someone should chime in here, but I remember the state of TLS extensions is a concern for SSL 3. Anyway, TUM's Internet-wide measurements showed SSL 3-only deployment to be around 3%, so I don't think we have a problem there. If you need a citable source, we might have to ask Ivan Ristic for data from SSLPulse. TUM is not going to publish a Technical Report at this time, so you'd have to take my word for it. >> Also client MUST send an ec_point_formats extension > > As I mentioned earlier, "RFC 4492 specifies the MUST/SHOULD status > for these extensions. I don't think we should be repeating or > overriding that." This question seems to pop up reltaively frequently, however. I am starting to think we might compromise here - after all, the BCP is a collection of practices that are otherwise distributed over many (non-RFC and RFC-) sources, and it might not do us worse if we happen to reiterate on this one issue. If we can keep it limited to this one. Another concern of mine is that normal RFCs often go unheeded anyway by software implementations - maybe this BCP has a better-than-average chance of being noticed. >> Clients MUST include the “supported elliptic curve” extension > > See above. Same would apply here. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
