[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next
From:       Martin Rex <mrex () sap ! com>
Date:       2009-12-17 17:35:59
Message-ID: 200912171735.nBHHZxLk003093 () fs4113 ! wdf ! sap ! corp
[Download RAW message or body]

Martin Rex wrote:
> 
> Marsh Ray wrote:
> > 
> > Obviously the part that says
> > > If this is the initial handshake for a connection, then the
> > >       "renegotiated_connection" field is of zero length in both the
> > >       ClientHello and the ServerHello.
> > is not limiting itself to renegotiations.
> > 
> > I don't know how the IETF rules work, if a future implementaion can say
> > it implements proper TLS without implementing this extension. In
> > practice, every TLS implementation (except perhaps yours) is going to
> > want to implement the security fix properly lest they be shunned by
> > other implementations.
> 
> I'm not an IETF process wizard. but I have not knowingly come
> across such a situation with IETF protocols so far.
> 
> There will likely not be TLSv1.0-2010, TLSv1.1-2010 and TLSv1.2-2010.
> 
> There will be implementations of particular RFCs, but if an
> implementation says TLSv1.0, that will not _by_itself_ imply
> that this includes any updates.  You will probably need to look
> for the update-RFC number to be explicitly mentioned.
> 
> The point in time when a product is developed or shipped or sold
> does not impact this at all.

Btw. if your product implements TLSv1.0+TLSextensionRI and completely
fails to interoperate with compliant implementations of TLSv1.0 without
that update, then _YOUR_ product will be TLSv1.0-incompliant -- there
is no doubt about that!

Any kind of suggestion in the specification that updated client
and servers should completely fail interoperation with compliant
implementations without that update (i.e. also initial handshakes)
is a bad idea, and I explicitly object to that.

A specification with such a suggestion is _NOT_ an update to the
existing specs, it is an entirely new, non-interoperable protocol!

Offering applications or consumers configuration options so that
they can obtain this result is slightly different.  But as soon
as you strongly suggest to kill the entire interoperability or
configure it that way by default, you no longer have an
implementation compliant to the original protocol.


-Martin

[prev in list] [next in list] [prev in thread] [next in thread]