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

List:       ietf-tls
Subject:    Re: [TLS] Backwards compatilbility problem with variant recordsa
From:       "Yngve N. Pettersen" <yngve () opera ! com>
Date:       2012-03-29 19:17:05
Message-ID: op.wbx46r2jkvaitl () lessa-ii ! oslo ! os
[Download RAW message or body]

On Thu, 29 Mar 2012 20:19:54 +0200, Martin Rex <mrex@sap.com> wrote:

> Yngve N. Pettersen wrote:
>>
>> On Thu, 29 Mar 2012 15:13:05 +0200, Martin Rex <mrex@sap.com> wrote:
>> >
>> > Yngve N. Pettersen wrote:
>> >>
>> >> If the client sends a Recs vector that includes a Wha1 variant, the
>> >> server
>> >> will not be able to read the Rec.payload field, and will likely  
>> crash or
>> >> abandon the connection.
>> >
>> > A reasonable implementation would simply skip to the next TLS  
>> extension
>> > (ignoring the rest of what it didn't understand).  If it crashes,
>> > it is probably an early beta version that should neither be  
>> distributed
>> > nor used in production environments...
>>
>> Counterargument: SSL v3 and TLS 1.0+ required servers to ignore Client
>> Hello content following the compression field. As we all know, a large
>> number of servers did not implement it that way, causing the handshakes  
>> to
>> fail. Similar problem exists for the version indication.
>
> No, the problem here was that the SSLv3 spec was retroactively changed,
> and neither was that change clearly communicated, nor was an updated
> SSLv3 spec prominently published and all prior variants of the SSLv3
> spec without that backwards-incompatible change killed!

Most of the TLS Extension intolerant servers support TLS 1.0 as their  
highest version, not SSL v3. TLS 1.0, at least, is clear on this point.

The most common failure scenario, as I recall, is that the connection is  
closed.

>
>>
>> Maybe I am being pessimistic, but I am concerned about the possibility
>> that implementations of the affected variants records will have failed  
>> in
>> similar fashions. Only an extensive and detailed review of what existing
>> implementations do will reveal what has been implemented.
>
> I agree that this ambiguity must be expected to cause interop problems
> (in the fashion that new name types inserted by clients may cause servers
> to entirely ignore the extension although the very same server would
> understand a traditional TLS extension SNI.
>
> There is a certain likelyhood that for servers that need SNI badly
> to pick the right cert, this would likely cause clients to barf on the
> server picking the wrong cert when not understanding fancy names
> sent by the client.
>
> What I do not understand is (a) servers crashing and (b) servers aborting
> the handshake.  It just does not make sense.
>
>
> What confuses me here is that so many folks claim to have implemented
> and shipped TLS extension SNI (and the RFC went through 2 revs!!),
> and you're the first implementor to point out that there is a problem
> with that part of the spec.

Turns out I wasn't the first to discover the problem space.

> If there is an ambiguity, then it is crystal clear from the spec and
> it is impossible for a sensible implementor to MISS that fact and
> request clarification.  I'm disappointed.  I would really appreciate
> implementors to pay more attention and point out problems that they
> encounter.
>
> The IETF mantra is "running code", and that does not include "crashing  
> code".

"Running code" does not necessarily mean that it has been tested with  
unexpected, but valid data.

As it was, the reason I (re)discovered the issue was that I was thinking  
specifically about how to parse and ignore an item with an unknown type  
when I was implementing a prototype decoder. If I had only followed the  
structure layout and coding exactly that, I might not have thought about  
future changes to the structure.

>
>>
>> The syntax below is AFAIK currently not supported by RFC 5246, and this  
>> is
>> IMO clearly indicated by the fact that similar variant records in TLS,
>> such as Handshake and the Record Protocol records, are not coded in that
>> fashion, but the one I am using above.
>>
>> Extending the syntax might be an option, but at present I don't think it
>> is realistic.
>
> Where does rfc5246 say that variants (section 4.6.1) being a
> variation of Constructed type (section 4.6) can not be defined as  
> variable
> length vectors (section 4.3)?  Just because there is no current
> example / usage of this in the spec, I do not see anything that could
> be interpreted to preclude this.

The variant you suggest may make sense, but at present there is AFAIK no  
example of the Select construct being used in that fashion. I'd just  
prefer to have the example in the text of the protocol specification  
first, rather than adding it in a related specification.

Even struct foo vectors  are IIRC first declared as a structure type, then  
the typename is used to declare the vector. Select constructors are not  
type definitions, they are field definitions, which may be one reason why  
your construct have not been considered.

Another reason it may not have been considered is that the <> vector  
construct is meant for *repeated* structures of the same type, not a  
single item of of a structure with variant length.

To avoid confusion I would think that such a length determined variant  
construct should have a special name and/or textual representation that is  
different from the <> and [] constructs.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

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