Re: [TLS] simplistic renego protection

[David-Sarah Hopwood <[e-mail]>]

Eric Rescorla wrote:
> At Wed, 18 Nov 2009 15:36:42 +0100 (MET),
> Martin Rex wrote:
>> Michael D'Errico wrote:
>>> You forgot to mention:
>>>
>>> 4.3.  SSLv3
>>>
>>>     SSLv3 does not support extensions and thus it is not possible to
>>>     securely renegotiate with SSLv3.  Deployments wishing to renegotiate
>>>     securely will need to upgrade to at least TLS 1.0.
>>>
>>> Is there some secret agenda to kill off SSLv3?  What is the point
>>> of that?  SSLv3 accounts for more than one-in-five connections as
>>> reported to this list.  There is an alternate proposal that does not
>>> have this limitation, and is better in many other respects.  Why do
>>> you keep pushing this one?
>>
>> This statement about SSLv3 actually reverts history.
>>
>> The fact is, that SSLv3 has THE EXACT SAME provisions for
>> TLS extensions as TLSv1.0.
>>
>> But TLS extensions seems to exclude _itself_ from being used with SSLv3
>> -- which looks like a pretty bad idea, given that the extensibility
>> of TLSv1.0 and SSLv3 is verbatim the same.
> 
> Well, I'm not taking any responsibility for that. I didn't write
> the original TLS extensions doc. That said, I suspect the feeling
> was that the IETF didn't have any control of SSLv3, and so couldn't
> mandate anything about it.

Actually, the main argument in the WG at the time was about whether
extensions should be delayed until TLS 1.1, or supported for TLS 1.0:

<http://www.imc.org/ietf-tls/mail-archive/msg02053.html>
<http://www.imc.org/ietf-tls/mail-archive/msg02058.html>
<http://www.imc.org/ietf-tls/mail-archive/msg02082.html>

(The 'Thread Index' links in each article are busted.
The archive by thread is currently at
<http://www.imc.org/ietf-tls/mail-archive/thrd17.html>,
although that link will become incorrect because older index
pages are renamed when the current page becomes full.)

I was arguing for extensions to be supported for SSLv3:

# Also note that the dns_name attribute is useful for SSL v3.0 as
# well, and there's no particular reason to exclude it from being
# used in that case (i.e. as a minimal change to servers to allow
# them to support virtual hosting without having to implement TLS).

but another author of the draft responded with

# Re: SSLv3.0, I never intended the dns_name extension to be excluded
# from there.  However, since this is the TLS working group and since
# there is no living specification of SSLv3.0 the point seems moot
# and/or out of scope.

and there was no dissent to that position.

(Note that the "criticality flag" mentioned in that thread was
dropped. I think RI would have been the first extension to be
"critical" in that sense, when used by strict clients.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com