Re: [TLS] Non-browser clients.

[Nelson B Bolyard <[e-mail]>]

On 2009-11-22 04:50 PST, Dr Stephen Henson wrote:
> Nelson B Bolyard wrote:
>> On 2009-11-21 05:24 PST, Dr Stephen Henson wrote:
>> 
>>> Just to add a point to this which hasn't really been mentioned.
>>> 
>>> The discussion of connection logic has largely been browser centric, 
>>> non-browser clients often work in a different way and the current 
>>> proposal (draft-ietf-tls-renegotiation-01.txt) can cause them
>>> significant problems.
>> 
>> Where is this draft?  It's not on rfc-editor.org nor on ietf.org. Are
>> you referring to draft-RESCORLA-tls-renegotiation-01.txt?
>> 
> 
> Yes I meant the 01 version at: 
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

That draft has been superseded.  There has been a succession of 3 drafts:

draft-RESCORLA-tls-renegotiation-00.txt
draft-RESCORLA-tls-renegotiation-01.txt
    draft-IETF-tls-renegotiation-00.txt

each of which superseded the previous.

> Fallbacks aren't explicitly mentioned in the 00 draft. The whole issue of
> how one can support secure renegotiation (if the server supports it) but
> still connect to an unpatched SSLv3 or unpatched extension intolerant TLS
> server isn't covered.

Isn't it outside of scope?

The draft named IETF (which I support with some minor clarifications) seems
to address this quite directly.  It says that secure renegotiation cannot
be done with SSLv3.  It talks about clients who want to take the risk may
do it anyway.  But clearly, doing so is outside of the scope and intent of
this draft, which intent is to do things securely.

> The 01 draft resolves this issue but requires fallbacks.
> 
> It has been mentioned elsewhere that the obvious fallback techniques
> using the 00 draft are vulnerable to downgrade attacks. If anyone has a
> reference to a fallback technique that isn't vulnerable and complies to
> the 00 draft I'd be interested to hear it.

I believe that it is the intent of EKR's succession of drafts to NOT attempt
to create an invulnerable form of SSLv3.  Others in this list want to try to
do that with alternative proposals.

> Steve.