Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Kyle Hamilton <[e-mail]>]

The only way to prevent a reneg-naïve client from creating any
security risk to the server is to:
1) enforce the highest security that anything on that server requires
as a prerequisite to *all* connections to that server, and
2) use mutual authentication instead of only authenticating one side.

The requirement: An unauthenticated client that sends a command to the
server that requires it to have higher access credentials than the
connection has cannot cause the server to initiate a renegotiation.

Not meeting that requirement is what got us into the problem in the first place.

I join Marsh in dissenting to that "safely" message, as there is NO
way to safely renegotiate unless both sides are mutually authenticated
before the first bytes are received by the server process (as a client
of the TLS implementation, since the TLS implementation handles the
crypto part of the transaction).  Even then, that is only as far as
the identification doesn't change.

(Note: Firefox specifically disables HTTP pipelining over TLS
connections by default.)

-Kyle H

On Tue, Jan 12, 2010 at 11:55 AM, Marsh Ray <[e-mail]> wrote:
> Martin Rex wrote:
>>
>> There is a document, approved by the IESG, where both of you are
>> listed as document co-authors, and it says this:
>>
>> http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#section-4.3
>>
>>
>> 4.3. Server Considerations
>>
>> If the client does not offer the "renegotiation_info" extension or
>> the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the
>> client does not support secure renegotiation.  However, because the
>> above attack looks like two handshakes to the server, the server can
>> safely continue the connection as long as it does not allow the
>> client to renegotiate.
>>
>> I'm fine with that "the server can safely continue the connection as
>> long as it does not allow the client to renegotiate."
>
> I'm not, and I argued against the inclusion of that language repeatedly.
>
> The explanation I was given, IIRC, was that it was just referring to
> "the above attack" which was the one simplest case to explain. It was
> not supposed to be exhaustive of all attacks.
>
> I firmly believe that the language "the server can safely continue the
> connection as long as it does not allow the client to renegotiate" is in
> error.
>
> It was not worth continuing to argue about if it delays the
> implementation of the fix (which is the same in any case).
>
>> I don't want to continue discussing this issue.
>
> Agreed.
>
> I'll just have to make my point with working exploit code.
>
> - Marsh
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>