Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-renegotation: next

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Martin Rex wrote:
>>> Sending SCSV with no extension in a renegotiation Hello is a very
>>> questionable thing to do. That combination of values is needed for
>>> clients that wish to send an _initial_ hello and interoperate with
>>> extensions-intolerant servers! Overloading to also mean (and be
>>> ambiguous) with "I'm intentionally _renegotiating_ in a manner known to
>>> be insecure" is bad. And that is a technical objection.
>> Now you're trying to make something up in a haste.
>>
>> I'm wondering which vendors are this that have already shipped
>> an implementation based on the original TLS extension RI proposal
>> and are now trying hard to prevent any changes to the document
>> that would require them to patch again.

I don't know of any vendors that have "shipped" an implementation. The
closest I know of is OpenSSL has something in their source control
system but doubt they would have any problems with whatever changes.

Implementing the proposed fix is just not that hard, compared to the
difficulty of analyzing the proposals from all angles.

>> You are aware that the wording that I proposed does _not_ say
>> that sending a TLS extension RI as the only extension would
>> not be allowed.  It is allowed, its up to the vendor.
>>
>> Yes, it would happen that some updated clients send only SCSV and
>> expect the server to understand that.  I don't think that is a problem.
>> That update would be with much less time pressure, and then I was
>> assured so many times that sending extensions was so standard and
>> just everybody was doing it already, that I can not believe this
>> to become an unsurmountable problem for early adopters.
> 
> 
> I got confused.  It is about early adopter clients that send
> TLS extension RI (not knowning about SCSV) and might run into
> updated servers that look only for SCSV.

Such servers are not permitted by the current proposal.

>From http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt
>    Upon receipt of the "renegotiation_info" extension, both client and
>    server implementations which support the extension MUST verify that
>    it contains the correct contents as specified above (the previous
>    client Finished.verify_data in the ClientHello and the concatenation
>    of both Finished.verify_data values in the ServerHello).  If the
>    contents are incorrect, then it MUST generate a fatal
>    "handshake_failure" alert and terminate the connection.
[...]
>    TLS servers MUST support both the "renegotiation_info" extension and
>    the TLS_RENEGO_PROTECTION_REQUEST SCSV.  TLS servers which support


> But as I described,
> these are going to be servers that do not renegotiate anyway,

TLS does not define such a thing as a "server that does not
renegotiate". There may be in fact some application protocols or servers
which do not, but TLS provide no way to indicate this in the handshake.

In practice, it requires deep code inspection to prove and many
application authors have been surprised to find out that their TLS
implementation will renegotiate for them automatically.

Therefore, it is impossible for a general-purpose client to know this
about any specific server.

Therefore, it is a useless consideration for the protocol design.

> so there even is _no_ security problem involved.

An unpatched TLS connection can only be believed secure with code
inspection done on _both_ endpoints to prove that renegotiation can
never happen and/or application protocol analysis. Since a primary
feature of TLS is to support interoperability between diverse client and
server implementations, this is just not a common enough case to be
worth considering.

The fact that you are confident that some of your systems are
implemented that way is just not a useful consideration in developing a
solution for the general case.

> Those
> that implement secure renegotiation will always have to be able to
> recognize a TLS extension in ClientHello.

Yes, you will need to be able to recognize one particular extension in
order to support the fix for renegotiation.

I've proven that that basic code for this can be written in less than an
hour, with some test cases. Some organizations may take slightly longer.
Organizations which cannot handle that degree of complexity should not
IMHO be implementing security protocols.

> So really, making up an argument against a mandatory SCSV
> is going to be tough.

Not really.

- Marsh