Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

["Rex, Martin" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Nikos 
> Mavrogiannopoulos
> Sent: Wednesday, 27. January 2010 08:33
> To: Rex, Martin
> Cc: Peter Gutmann; [e-mail]; [e-mail]
> Subject: Re: [TLS] Metadiscussion on changes in 
> draft-ietf-tls-renegotiation
> 
> On Wed, Jan 27, 2010 at 1:05 AM, Martin Rex <[e-mail]> 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