Nelson B Bolyard wrote: > > On 2010-01-27 07:37 PST, Martin Rex wrote: > > Yoav Nir wrote: > > >> 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. > > I think you meant to write "necessary to prevent vulnerable renegotiation on > a connection where the initial ClientHello did not use any TLS extensions". > If that is what you meant, please confirm. It is necessary to actually perform an old-renegotiaion successfully while at the same time preventing an attacker from being able to proxy that old renegotiation into a renegotiation handshake of an updated server that still allows backwards-interoperable old renegotiation for old clients. > > What you wrote sounds more like you were expecting "old renegotiation" to > succeed. Correct, I am expecting that. That is a configuration option that implementations (hotfixes into installed base, early during the transition) are likely required to offer. That we recommend to discontinue old-style renegotiation is a totally different issue. > > If you were indeed expecting that, then why does SCSV play any > role in that at all? The purpose of SCSV is to reliably prevent any undesired renegotiations from being possible. The only handshakes where you can reliably distinguish desired from undesired is those between updated clients and updated servers. If an implementation of TLS offers a configuration option to allow old-style reneogitation for interop with installed base old servers, then we should an can limit that fallback to old servers. This is what the brand-new section 4.2 tries to explain (although it is in dire need of editorial fixes in order to become comprehensible). -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf