Re: [TLS] SCSVs and SSLv3 fallback

[[e-mail] (Martin Rex)]

Yngve N. Pettersen wrote:
> Martin Rex <[e-mail]> wrote:
> >
> > Why would you ever check for 4.xx version numbers?
> >
> > Rejecting 4.x version numbers is perfectly OK for TLS servers!
> >
> > rfc5246 says:
> >                                                           TLS servers
> >    compliant with this specification MUST accept any value {03,XX} as
> >    the record layer version number for ClientHello.
> >
> >    TLS clients that wish to negotiate with older servers MAY send any
> >    value {03,XX} as the record layer version number.
> >
> > A TLS client that uses a version {04,00} at the record layer or in
> > ClientHello.client_version is squarely in undefined territory,
> > and every conceivable server behaviour is perfectly compliant
> > with the TLSv1.2 spec.  (Personally, however, I believe that
> > crashing is never a valid option for the server).
> 
> The keywords are "forward compatibility".
> 
> And your quote concerns the *record* layer version, which is 3.1 in my  
> testcase.
> 
> The 4.1 that I am using in my test, is set in the  
> *ClientHello.client_version* field.
> 
> IMO a SSL/TLS server MUST tolerate ANY ClientHello.client_version larger  
> than its own highest supported version, and when returning the Server  
> Hello will reply with whatever its highest supported version is.


Quoting from rfc4346 (TLS v1.1 Record Protocol PDU):

       http://tools.ietf.org/html/rfc4346#page-18

       struct {
           uint8 major, minor;
       } ProtocolVersion;

       struct {
           ContentType type;
           ProtocolVersion version;
           uint16 length;
           opaque fragment[TLSPlaintext.length];
       } TLSPlaintext;


A TLS client that sends a ClientHello.client_version with major=4,minor=1 and
expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2 is just as misguided
as a client that sends a ClientHello.client_version with major=254, minor=255
and expecting interop on SSLv3,TLSv1.0,TLSv1.1 or TLSv1.2.

The meaning of the latter protocol version is defined here:
  http://tools.ietf.org/html/rfc4347

and there is *NO* reservation or requirement in rfc5246 that would could be
interpreted to make "major=4" any less invalid than "major=254".


-Martin