Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

The GSA spec supports resumption but also requires renegotiation.  

The spec requires mutual authentication and I believe that the
certificates  have fairly short lifetimes, definitely far shorter than
those used in typical web servers. 

The spec requires SCEP and there are requirements that when a new
certificate is issued it must use a different public key.

So on renegotiation there may be new certificates exchanged. 

And the implementers that I have talked to are establishing all their
TLS connections once at startup and not closing them unless they
absolutely have to.

Maybe GSA would be willing to drop renegotiation  requirements, forcing
implementers to close and re-establish their connections.  I cannot
answer that question.

But on the other hand adding the RI extension doesn't seems that complex
to me.  The GSA spec requires TLS 1.0 so implementations should be TLS
extension compliant already.

I will implement whatever the TLS group feels is the most appropriate
action for the renegotiation vulnerability. 

But we need to be careful about dropping features that may be used in
applications/specifications outside of the WEB server/browser world.

-- 

Robert Dugal                        Senior Software Developer

Certicom Corp.                    A Subsidiary of Research In Motion 

rdugal@certicom.com <mailto:rdugal@certicom.com> 

direct        905.501.3848

fax             905.507.4230

www.certicom.com <http://www.certicom.com> 

From: mbadra@gmail.com [mailto:mbadra@gmail.com] On Behalf Of Badra
Sent: Tuesday, December 15, 2009 7:01 AM
To: Robert Dugal
Cc: tls@ietf.org
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal <rdugal@certicom.com>
wrote:

The server based gaming specs require renegotiation periodically in
order to refresh TLS session keys.

What about resumed handshake? you don't need a new handshake to refresh
your keys

Best regards

Badra

	On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote:
	>   As a protocol climbs the IETF standards-track maturity
ladder, we
	>   sometimes drop features.  I would rather see renegotiation
dropped
	>   from TLS than see this complexity added to TLS protocol.

	I would like to agree.  There's no real-world need to
re-negotiate for
	re-keying nowadays: with the advent of 128-bit block block
ciphers
	there's little need.

	But re-negotiation remains useful for other purposes.  Probably
the most
	obvious ones are optional authentication and privacy protection
for
	client credentials.  I'm not sure those are sufficiently useful
or
	important to warrant keeping the feature, but if not then
dropping the
	feature does seem like a better option than fixing it.

	Nico
	--
	_______________________________________________
	TLS mailing list
	TLS@ietf.org
	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.

	_______________________________________________
	TLS mailing list
	TLS@ietf.org
	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.