-----Original Message-----
From: mrex(_at_)sap(_dot_)com [mailto:mrex(_at_)sap(_dot_)com] On Behalf Of
Nikos
Mavrogiannopoulos
Sent: Wednesday, 27. January 2010 08:33
To: Rex, Martin
Cc: Peter Gutmann; ietf(_at_)ietf(_dot_)org; tls(_at_)ietf(_dot_)org
Subject: Re: [TLS] Metadiscussion on changes in
draft-ietf-tls-renegotiation
On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <mrex(_at_)sap(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf