On Sun, Jul 6, 2014 at 7:11 PM, Ralph Holz <[email protected]> wrote: > 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.
Why are we not including 1/(n-1) record splitting when TLS 1.0 is negotiated? Furthermore, we should mention workarounds for Triple Handshake and Lucky 13. I think we mention CRIME already. Sincerely, Watson Ladd > > 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 -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
