Yoav Nir wrote: > > On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote: > > > Yes. I agree that SCSV could be defined to convey only 1 bit of > > information while RI conveys 2 bits, and agree that -01 (which went > > through last call) does not define it that way. > > > > What I don't understand is why the issue of changing the semantics of > > -01 and -03 to reflect a "1 bit SCSV" is so #$%& important. > > 1. It is trivially easy to code to either version. > > Actually it's easier to hard-code the ciphersuite list on the client, > because it never changes with most applications. Adding logic to > differentiate between initial handshakes and repeated handshakes > complicates the code (though not by much) It more complicated than that, because SCSV is additionally necessary for sensible behaviour even with -03 when doing old renegotiation on a connection where the initial ClientHello did not use any TLS extensions. And it is a different question whether providers of an implementation offer this configuration option (which a number of them likely has to), or wether we recommend that this configuration setting is actually used. These are two different guidances, and the -03 document does not distinguish them, which is a bad idea. > > > 2. There is no security impact of using either version. > > 3. It is easier to articulate and to understand an "identical" soundbite > > than to explain how SCSV and empty RI are semantically different, and > > "SCSV means the client supports RI". There. That was easy to articulate. > An empty extension is less easy IMO. The concept that I had in mind when I created the label TLS_RENEGO_PROTECTION_REQUEST was a signal that indicates "Please protect me from an old-style TLS handshake" And an old-style TLS handshake is one where you have no possibility to detect whether there is an MitM attacking you. > > > 4. The "identical" version is ready to go, in the form of -03 that can > > be published as an RFC right now. Process-wise, Pasi could have made a consensus call on exact SCSV semantics on Dec 17th providing several options, the result of a free and open discussion on SCSV semantics could have been part of -03, Pasi could have re-issued an IETF Last Call on Jan 7th, we would have received further editorial comments and today an -04 document could be in much better shape, ready for IESG approval and in perfect alignment with the IETF processes. > > > And although I hesitate to bring up the following since they are > > non-essential, > > 5. SCSV is a hack meant to appease ancient and/or non-conforming > > servers. That is one ugly baby, and I wish it would just disappear. > > There is absolutely no reason for it ever to be sent in a ClientHello > > containing a non-empty RI (it is a no-op that just wastes N bits of > > bandwidth to convey 0 bits of additional information, and no legacy > > implementation would ever send or interpret it), so I see absolutely no > > downside to prohibiting it during renegotiation. > > To me RI looks like a hack just as much as SCSV. Hopefully in the > future, the way to indicate support for secure renegotiation would > be in the client version of the ClientHello. Unfortunately, that "go away" is impossible for any implementation of TLS that offers interop with protocol versions 0x03,0x00 -> 0x03,0x03 (aka SSLv3 and TLS protocol version v1.0->v1.2). And although clients could stop sending SCSV when they stop using extension-less ClientHellos, the server-side support for SCSV is going to stick forever. Likewise, the TLS extension RI band-aid is going to be with us for at least 20 years. It's not possible to make this design an integral part of a future TLS version that obviates sending this data over the wire. Except maybe defining an alternative and negotiating that as well. The latter could obviate transfering the data, but would require implementations to implement essentialls two solutions for the same problem, which, unless someone finds a problem with TLS extension RI (which I doubt), would be a complete waste of resources. I remember that Stephen Farrell suggested to standardize both (TLS extension RI without SCSV plus a well-discussed successor of draft-mrex-tls-secure-renegotiation), but *I* don't like two solution where one is sufficient. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf