Re: [TLS] TLS renegotiation issue

[Eric Rescorla <ekr at rtfm.com>]

On Thu, Nov 5, 2009 at 10:48 AM, Martin Rex <mrex at sap.com> wrote:
> Eric Rescorla wrote:
>>
>> I now have a draft extension up
>
> Thanks Eric.
>
>  Page 5:
>
>  The contents of this extension are specified as follows.
>   [...]
>  The above rules apply even when TLS resumption is used.
>
>
> I read this as meaning that the client and server should add
> two elements client.verify_data and server.verify_data
> to their SecurityParameters for the connection state suggested
> by RFC5246 6.1. and update this data on EVERY TLS handshake,
> even TLS session resume.

Yes. That's what it means.


>  4.1  Client Considerations
>
> I can understand what it says, but I _really_ dislike it.
>
> The root of the problem is servers that perform (or at least allow)
> TLS renegotiations and make flawed assumptions about what a
> successful TLS renegotiation means for the data previously received.
>
> What you're essentially asking for, is that a client should no longer
> talk TLS to _any_ Server that doesn't support the new extension.
> Not even to the good ones that neither offer nor support renegotiation.
>
> This is discriminating against servers that have been playing safe!
>
> Essentially we are going to hold TLS clients and the installed
> base of good Servers responsible for the broken Servers out there.
> That feels very wrong.

I'm not recommending that clients do that. What I'm trying to say is that
*if* a client wants to be totally sure then all it can do is require
the extension.
I agree it's impractical (and probably unwise) to suggest that they actually
behave that way.

Do you agree that the characterization above is correct? If so, how can I
update the draft to make that clearer?

-Ekr