Re: [TLS] One approach to rollback protection

[Eric Rescorla <[e-mail]>]

On Mon, Sep 26, 2011 at 5:48 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> Hmm... What's the advantage of something this complicated/expressive,
>> especially given that there is no way to currently express
>> "I speak TLS 1.2 but not 1.0"?
>
> I know that with "current TLS version negotiation" it is not possible
> to convey the exact protocol version that a clients supports or may
> want to talk.
>
> The issue with the original scheme is, that in order to offer TLSv1.2,
> you MUST (de facto) implement *ALL* prior protocol versions.
> But that currently means that you have to take all existing specs,
> put them side-by-side and work out the diffs yourself, because
> successors specs don't show the PDUs and semantics of previous
> protocol versions side-by-side.

I don't think I understand this: if you have a client which only wishes to
support TLS 1.2, what it currently does is to offer TLS 1.2 in the
ClientHello and then if the server selects a lower version in the
ServerHello, the client generates an error.

In an environment where the client could indicate any combination of
versions, the impact of implementing TLS 1.2 only would be that a
server which did not support TLS 1.2 would generate an error instead
of a ClientHello.

Since servers are supposed to select the highest common version, I'm
not sure I see serious difference between these two.


>> My objective here isn't to replace the TLS version negotiation mechanism
>> but merely to remove the downgrade attack problem. If we get that right,
>> and there is WG interest in revamping the version system, we can do that at
>> some other time.
>
> I don't think that revising the TLS version negotiation yet another
> time is a sensible idea.  If we do it at all, make it right this
> time.

I'm not sold that it's that lacking, other than the fact that people
have implemented
it wrong.

-Ekr