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

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2009 11:19:57 -0800 (PST)

Comment:

  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.

---

From: Steven Bellovin <[email-masked]>
Date: Mon, 14 Dec 2009 14:44:23 -0500

>  from TLS than see this complexity added to TLS protocol.

Works for me.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Dec 2009 13:44:32 -0600

>   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
--

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2009 14:52:14 -0500

This message was sent by the Datatracker when I entered an ABSTAIN 
ballot position on this document.  I am not blocking the approval or 
the progression of this document.  However, I cannot support it 
either.  I am simply documenting the reason for the ABSTAIN ballot position.

Russ

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Dec 2009 13:36:39 -0700

> feature does seem like a better option than fixing it.

Even if the WG decided not to drop renegotiation, I do think it would be
helpful to document why the feature is important and useful in the first
place. As far as I can see, both draft-ietf-tls-renegotiation and
draft-mrex-tls-secure-renegotiation assume that renegotiation is a good
thing, and RFC 5246 contains only this assertion:

      While renegotiation is an optional feature, supporting it is
      highly recommended.

A more detailed justification might be helpful.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 14 Dec 2009 16:01:06 -0500

One use of renegotiation is to obscure endpoint identities, as supported
in IPsec by protecting IKE_AUTH messages under keys established in an
IKE_SA_INIT exchange.

If identity protection were required in TLS (I'm not claiming that it
is) and renegotiation is not allowed, the obvious choice is to tunnel
authenticated TLS inside an anonymous TLS session.  Are there
alternatives to renegotiation or tunneling?  The overhead of maintaining
two record layers over the lifetime of a connection seems high, and I'm
not aware of a standard mechanism for establishing a tunnel in the first
place, or for tearing down the outer layer after the inner handshake has
completed.

Could a special-purpose identity protection handshake be defined in a
manner that is both simpler and safer than full renegotiation?

Just want to fully consider the consequences before discarding a
feature.  In practice it doesn't matter, since the market will decide if
a Draft Standard TLS with patched renegotiation will still be supported
after Full Standard TLS is defined.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Russ Housley
Sent: Monday, December 14, 2009 2:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TLS] COMMENT: draft-ietf-tls-renegotiation

Comment:

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

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Dec 2009 10:14:31 +1300

>re-keying nowadays: with the advent of 128-bit block block ciphers

+1.  I've never supported renegotiation in my code because I saw it as mostly 
a source of trouble due to the complexity involved in implementing it.  In 

>feature does seem like a better option than fixing it.

... in 10+ years of providing SSL/TLS support I've never had anyone request 
it, or ask about privacy protection for client credentials.  Admittedly there 
could have been millions of potential users who silently turned away because 
this facility was missing, but somehow I doubt it.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 15 Dec 2009 02:37:01 +0100

The fact that it is used for legitimate purposes makes me worried about the
consequences of just abandoning it without fixing it.

Perhaps a middle way is to not fix it and not to remove it, but simply
clarify it's security properties. I'm still not convinced you can't use
unpatched renegotiation securely if applications simply don't accept
messages sent before completed renegotiation as being delivered under the
context of the renegotiated connection. Other's have suggested the same.

/Stefan

---

From: <[email-masked]>
Date: Tue, 15 Dec 2009 10:40:16 +0100

David P. Kemp wrote:
> Could a special-purpose identity protection handshake be defined in
> a manner that is both simpler and safer than full renegotiation?

A couple of years ago, there was a proposal to specify new cipher
suites that build identity protection into the handshake
(draft-hajjeh-tls-identity-protection), and a proposal that used
extensions (draft-urien-badra-eap-tls-identity-protection).

But these don't solve what's AFAIK the main use case for 
renegotiation today: a HTTPS server that doesn't know whether it 
needs client authentication or not until it sees the URL.

Of course, it is not impossible to solve this without renegotiation:
one obvious way would be HTTP 401 response + a new HTTP header that
means "please retry with TLS client authentication". (I haven't
really thought about this, so I'm not saying this would necessarily
be a good idea.)

Best regards,
Pasi
(not wearing any hats)

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Dec 2009 10:43:25 +0000

>  from TLS than see this complexity added to TLS protocol.

That would break any website that does per-directory client
certificates. Which may not be many, but its far more than zero.

---

From: "Robert Dugal" <[email-masked]>
Date: Tue, 15 Dec 2009 06:46:05 -0500

The server based gaming specs require renegotiation periodically in order to refresh TLS session keys. 
A lot of the requirements in the gaming specs are to meet legislatorial requirements.
I'm not sure where the renegotiation requirements come from but it's in the spec and I suspect they are going to be resistant to dropping it.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Monday, December 14, 2009 2:45 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

Nico

---------------------------------------------------------------------
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.

---

From: Badra <[email-masked]>
Date: Tue, 15 Dec 2009 16:00:46 +0400

> 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:
> 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.

---

From: "Robert Dugal" <[email-masked]>
Date: Tue, 15 Dec 2009 07:29:13 -0500

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.

-- 

[email-masked] <mailto:[email-masked]> 

direct        905.501.3848

fax             905.507.4230

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Badra
Sent: Tuesday, December 15, 2009 7:01 AM
To: Robert Dugal
Cc: [email-masked]
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

On Tue, Dec 15, 2009 at 3:46 PM, Robert Dugal <[email-masked]>
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

	>   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

---------------------------------------------------------------------
	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.

---

From: Steve Dispensa <[email-masked]>
Date: Tue, 15 Dec 2009 09:11:32 -0600

> certificates. Which may not be many, but its far more than zero.
Also, it breaks support for varying crypto strength requirements (e.g., some
docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't specify
a new system this way, but I'm sure there are existing systems that do this.

 -Steve

---

From: Ran Canetti <[email-masked]>
Date: Mon, 14 Dec 2009 21:26:11 +0200

Indeed.

Or, at least, a strong case should be made why renegotiation (within the 
same session, from the point of view of the application) is an important 
feature to preserve.

Ran

---

From: Marsh Ray <[email-masked]>
Date: Tue, 15 Dec 2009 10:31:27 -0600

> same session, from the point of view of the application) is an important

A large number of systems are currently using it. We don't know exactly,
but this might give you an idea:

http://www.google.com/search?q=microsoft+iis+client+certificate

Do they really need it? Probably some do, some don't. Some installations
could rearrange their sites to not need it, and some have more IIS web
servers than they could begin to count.

Why should we keep renegotiation?

Because any spec which "drops" it is just going to be ignored, with the
side effect of the industry dropping the IETF rather than the IETF
dropping renegotiation.

Removing support for (i.e., not fixing) a fundamental and widely-used
protocol feature like renegotiation is not an option.

- Marsh

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Dec 2009 10:24:23 -0700

> side effect of the industry dropping the IETF rather than the IETF

Given that the TLS WG list is full of discussion about remaining
backward-compatible with SSLv3, it's not clear if the industry is paying
attention to the IETF anyway.

> protocol feature like renegotiation is not an option.

I think the question Russ raised is: just how fundamental is TLS
renegotiation? And the answer so far seems to be: some deployments seem
to use it, but it might not be fundamental.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Dec 2009 18:47:26 +0100 (MET)

>   from TLS than see this complexity added to TLS protocol.
 
The message that I'm receiving here is that Russ thinks the
solution that is currently described in draft-ietf-tls-renegotiation-01
is too complex to be a good solution for this problem.

It is up to Russ to distinguish whether he doesn't think the problem
is worth solving at all, or whether it is _just_ the solution
TLS extension RI that he considers too complex to be an
adequate solution to the TLS renegotiation vulnerability.

Personally, I do not like the complexity of TLS extension RI
either, and as previously indicated would prefer a solution of
minimal complexity such as draft-mrex-tls-secure-renegotiation-03

-Martin

---

From: Nelson Bolyard <[email-masked]>
Date: Tue, 15 Dec 2009 15:16:15 -0800

> attention to the IETF anyway.

There is a small number of individuals in this list who are generating a
very high volume of traffic arguing that it is necessary to preserve
backward compatibility with servers that are not only SSL 3.0 but a subset
thereof that is intolerant of any hello extensions and of client hellos
that bear any higher version than 3.0, being unable to successfully
negotiate an SSL 3.0 handshake in the presence of either.

If one judges purely by the volume of traffic in the list, one might conclude
that the industry as a whole is behind that position.  But I believe that
conclusion would not be supported by an actual poll of vendors of SSL 3.x
(including TLS 1.x) server products.  I think we are merely hearing from a
very vociferous minority who hopes to defeat the current draft by filibuster.

> to use it, but it might not be fundamental.

I believe it is very heavily used in business-to-business https transactions
including so-called intranet transactions, where parts of a web site require
different authentication than the rest.

Several alternatives have been proposed to achieve those same ends without
renegotiation, such as using separate logical servers on separate ports
each with its own authentication requirements that are enforced on the
initial handshake, rather than during renegotiation.  These proposals all
present numerous challenges, any of which is orders of magnitude greater
for the many shops that would need to implement them than merely deploying
a "safe" version of renegotiation.  Numerous server vendors have expressed
that they believe their customers would rather live with the vulnerability
than be faced with completely refactoring all their https web sites, and/or
multiplying the number of deployed reverse proxies.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Dec 2009 17:32:09 -0600

> different authentication than the rest.

Oddly enough, I found out today that an important OpenSolaris component
depends on it: the subscription-based software repository known as the
"extra" repo.  (The OpenSolaris IPS packaging system is layered above
HTTP.  The extra repo requires user authentication with certs in order
to obtain the contents of packages in that repository.

Not surprisingly this affects my stance on the issue.  Not because the
affected technology is my employers (or important to me) as much as
because it is a good example of how such applications might arise,
therefore an indicator that there may be many more like it.  It is
clearly simpler (well, for most TLS libraries, given their APIs) to fix
re-negotiation than to fix all such applications.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 01:57:57 +0100 (MET)

> > attention to the IETF anyway.

more than 90% of the world are on TLSv1.0 + SSLv3 combined.

> negotiate an SSL 3.0 handshake in the presence of either.

This misrepresents facts.

What I am arguing for is that a solution does not need to unnecessarily
create interoperability problems that can be easily and reliably avoided.

If this solution should be patched into the installed base, then it
should address the issues of the installed base!

If you think the installed base doesn't matter, then you should
rather propose to defer the solution to TLSv1.3.

> 
> If one judges purely by the volume of traffic in the list, one might
> conclude that the industry as a whole is behind that position.
> But I believe that conclusion would not be supported by an actual
> poll of vendors of SSL 3.x (including TLS 1.x) server products.
> I think we are merely hearing from a very vociferous minority
> who hopes to defeat the current draft by filibuster.

The open IETF standards process is about discussing technical
issues and providing solutions to technical issues.

A few valid technical issues that have been raised against
TLS extension RI, and not yet been addressed with sufficient
clarity.

Some issues were of the type
"I can not do this-and-this to my installed base".

And some answers have been
"Tough luck.  My installed base doesn't have that problem and
 I don't care about yours."

This would be OK if we were discussing about optional features of
a new protocol.  But we are actually discussing about a strongly
recommended, backwards-incompatible change to the entire installed
base that becomes as mandatory as it can get for protocols that
were finalized many many years ago.

A broken or incomplete patch that is widely distributed will
create much more damage than not shipping a patch at all,
and ultimately, a conforming patch based on a broken or
incomplete spec will create even worse problems.

The TLS renegotiation vulnerability itself is compliant implementations
of a vague and defective specification for the renegotiation, and we
currently see how painful it is to fix that.

No, I do not want to have the IETF ship a solution that is superficially
evaluated at best.  The fact that so many implementers completely
missed the TLS renegotiation vulnerability for over 14 years
worries me somewhat.  

A few implementors who have actually tried to implement both
proposed solutions for secure TLS renegotiation have shared
their results here.  So far their results were very similar.

If the original SSLv3 specification had described the
TLS renegotiation algorithm in full detail, then the vulnerability
would have been obvious from the beginning.

It's not very different for the interop problems with the extension
data in ClientHello and the protocol versions.  Instead of just
vaguely mentioning extensibility here or there, a specification
will need to spell out its expectations by example in order
for implementors to not create tomorrows interop problems today.

OpenSSL (in the days of 0.9.4) had nursing problems with the
TLSv1.0 protocol version, because the protocol version comparisons
were hardwired for major and minor version.
Today, OpenSSL is forwards compatible on the minor_version,
but the major_version is still hardwired.
Netscape 6 had problems sending correct protocol versions according
to the workarounds in OpenSSL, and Microsoft had a protocol version
problem in renegotiation handshakes.

To me, the effectively usable protocol version negotiation in TLS
(as inherited from SSLv3) for the installed base is a mess.
If they had used a set (like its done with the cipher_suites and
compression_methods), then the nursing problems would probably
be gone by now.  Another drawback from the exitisting version
negotiation is that implementations de-facto have to implement
all protocol versions, and given budget constraints of todays
world, TLSv1.0 is likely the protocol with the highest
return-of-investment.

Due to a complete lack of guidance about protocol version evolvement,
implementers made arbitrary choices which values they considered
valid and this is what resulted interop problems we currently face.
As a side-effect, the original "version rollback protection" no
longer works as expected for clients with re-connect fallbacks
and conservative clients.

> different authentication than the rest.

The issue is more, that those environments where renegotiation was
offered to applications and got used, now have a vital dependency
on that functionality being available.  

And while _our_ own installed base has no such dependency on TLS
renegotiation, *I* do care for the installed base of others,
and would be willing to bear the effort and burden to ship
an update for the entire installed base, provided that the
operational risk such a backwards-incompatible change means
for an installed base of largely unknown usage scenarios
is designed to be sufficiently small, and the spec on which
this change is based is sufficiently clear as to not create
new interoperability problems.

There are probably less than 10% of the implementers of SSLv3
and TLS implementations participating the IETF.  So any spec
we come up with should be sufficiently clear and sufficiently
simple that implementors around the world can come up with
independent interoperable implementations when all what they
have is the RFC document that we publish.

While we can not fix all of the problems (like unexpected identity
changes) universally at the TLS level, we can fix the most serious
problems with a relatively modest change in a central location
of the software stack and with a much better prerequisites for
applying a consistent fix throughout the entire infrastructure
than any approach that all of the affected applications would
have to individually pursue.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Dec 2009 04:37:27 +0100 (MET)

> world, TLSv1.0 is likely the protocol with the highest

Actually, that is likely incorrect
SSLv3 is probably still the protocol with the higest return-of-investment.

Up to this day, SSLv3 is the _only_ protocol version that will
provide almost universal interoperability.

There are several hundred million SSL clients out there, which,
although capable of extension-less TLSv1.0, have this disabled.

That platform is known as Windows XP, and it was sold well into
2009 with brand new hardware of the Netbook type (160 GB disk, 1GB Ram),
and that was actually the fastest growing PC market segment.

But it isn't any different for Windows 2003 / Windows XP 64-bit,

>From the 5 PCs I use (2 at work, 3 at home), 4 are WindowsXPsp3
and one is WindowsXPpro 64-bit.

And I use the original MSIE for Online Banking with active
content (javascript) enabled, while I use Firefox with active
content disabled for web browsing.  My family still uses MSIE only.

Businesses simply can not afford to _not_ support SSLv3 today.
Maybe in a few years.  But not now.  

-Martin

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 16 Dec 2009 13:57:08 -0500

> a new system this way, but I'm sure there are existing systems that do this.
I'm hard-put to justify a protocol feature for that scenario.  It's not just improbable, it's probably bad application design -- the performance differences in the different algorithms are just too small to justify it, and we don't have to support it just to deal with this niche case.  Ben's scenario is more compelling and bears further thought.

---

From: Steve Dispensa <[email-masked]>
Date: Wed, 16 Dec 2009 13:47:41 -0600

On 12/16/09 12:57 PM, "Steven Bellovin" <[email-masked]> wrote:

> I'm hard-put to justify a protocol feature for that scenario.  It's not just
> improbable, it's probably bad application design -- the performance
> differences in the different algorithms are just too small to justify it, and
> we don't have to support it just to deal with this niche case.  Ben's scenario
> is more compelling and bears further thought.

First off, I agree that Ben's scenario is more compelling; what I said is
significantly less important in my opinion.

That said, I wouldn't think only in terms of "application design." There are
other use cases that are considerably more complex from a network
infrastructure standpoint that do bear consideration. Think about
intercepting load balancers (with a variety of different servers behind
them), or about shared hosting accounts (e.g. .htaccess files in public_html
directories), or about servers that are hosting different off-the-shelf "web
applications" that check the configuration checkboxes differently, and so
on. I think this is one of those cases where real-world deployments are
messier than we'd like.

And, as Marsh has said on other threads, to remove a widely used feature is
tantamount to forking the protocol.

 -Steve