> -----Original Message----- > From: mrex@xxxxxxx [mailto:mrex@xxxxxxx] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Wednesday, 27. January 2010 08:33 > To: Rex, Martin > Cc: Peter Gutmann; ietf@xxxxxxxx; tls@xxxxxxxx > Subject: Re: [TLS] Metadiscussion on changes in > draft-ietf-tls-renegotiation > > On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <mrex@xxxxxxx> wrote: > > > > That may be attributed to the fact that a large part of PKIX is dealing > > with policy issues with the objective to prevent/prohibit interoperability. The above was a comment about PKIX, not SCSV. > > On the contrary. I believe allowing the sending of both SCSV > and extension might harm interoperability instead. Consider the > case of most popular client implementations are sending both SCSV > and extension (it's easier to do so). > A developer of a server might then consider checking only for > SCSV (since all of the popular ones he tested with send both). > Thus interoperability with less popular clients that only send > extension stops. I'm somewhat confused what makes you saying this. Support for SCSV is *required* for initial handshakes in the -03 document -- if it wasn't, SCSV could be removed from the document entirely. The reason for this is that otherwise existing usage scenarios would be susceptible to downgrade attacks (which is what the confusing reference in section 4.2 refers to). What I am opposing is the MUST NOT for the secure renegotiation. Secure renegotiation requires that both, server and client verify the contents of the "renegotiation_info". If some implementor forgets that without the SCSV MUST NOT, then you have much more serious issues to worry about than SCSV semantics. If _some_ implementors, without this MUST NOT, would really accidentally forget to verify the verify_data of the renegotiation_info for secure renegotiation, then we should dump TLS extension RI and go for the approach draft-mrex-tls-secure-renegotiation, because it is fairly unlikely that you get an implementation of this draft to interoperate in regular interop scenario _without_ getting the secure renegotiation working correctly. > > This scenario might not be very likely, but this kind of issues were > not rare in TLS for quite long :) I would have loved to get rid of the empty TLS extension RI entirely, (making SCSV the mandatory to use signaling method) just like Eric Rescorla proposed here: http://www.ietf.org/mail-archive/web/tls/current/msg04794.html because it would the most robust approach, but it had severe aesthetical acceptance problems (not a single technical problem is on record). -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf