Re: [TLS] simplistic renego protection

["Robert Dugal" <[e-mail]>]

I noticed you said this in the jabber log http://www.ietf.org/jabber/logs/tls/2009-11-12.txt 

[06:31:06] <EKR> It occurred to me the other day that there is a special case where hte server does not need to refuse renegotiation: when the client has sent no data yet.
[06:31:20] <EKR> This would allow step-up/SGC to continue to work 9assuming we cared it)

Our products do support step-up/SGC and some customers may still be using it, or at least have servers with SGC certificates.
Since there is no vulnerability is this special case, should some note be added to the draft? 

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[e-mail]
direct        905.501.3848
fax             905.507.4230
www.certicom.com


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Tuesday, November 17, 2009 12:50 PM
To: Stephen Farrell
Cc: Chris Newman; [e-mail]
Subject: Re: [TLS] simplistic renego protection

At Tue, 17 Nov 2009 13:09:24 +0000,
Stephen Farrell wrote:
> Having watched the recent list traffic I find the above convincing.
> I'd love to see a -01 of the above containing the changes EKR has
> mentioned already, and then a WGLC on that.

I just submitted an -01 version of the draft. This includes the
following changes:

1. Clarification of the encoding of the extension per the issue
   by Eric Young and Nelson Bolyard.
2. A bunch of discussion of fallback and the downgrade issue.
3. A SHOULD level requirement that implementations which simply
   reject negotiation still provide an empty extension when
   requested by the client, thus signalling that they have
   been updated.
4. A new section 4.3.1 that describes a magic cipher suite
   to be used to prevent downgrade attack on implementations
   which fall back to no extensions on handshake failure.
   
I've left point (4) as an OPEN ISSUE because it wasn't clear to me
what the WG feeling was. My general feeling is that it's not necesary:
SSLv3 servers which upgrade to fix this issue by refusing
renegotiation can easily arrange to simply ignore the extension, at
which point no downgrade attack is possible. Servers which don't do
even this can be presumed to be vulnerable and it doesn't seem that
bad to simply fail in this small number of cases. That said, I don't
have a problem with this feature f the WG wants to since it's not
being used by negotiation but merely as a failsafe, and I thought
it was important to get a concrete proposal for this mechanism
on the table.

-Ekr


_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.