Skip to main content

Transport Layer Security (TLS) Renegotiation Indication Extension
draft-ietf-tls-renegotiation-03

Revision differences

Document history

Date Rev. By Action
2010-01-08
03 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2010-01-07
03 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-01-07
03 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-01-07
03 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-01-07
03 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-01-07
03 (System) IANA Action state changed to In Progress
2010-01-07
03 Cindy Morgan IESG state changed to Approved-announcement sent
2010-01-07
03 Cindy Morgan IESG has approved the document
2010-01-07
03 Cindy Morgan Closed "Approve" ballot
2010-01-05
03 (System) New version available: draft-ietf-tls-renegotiation-03.txt
2009-12-18
03 (System) Removed from agenda for telechat - 2009-12-17
2009-12-17
03 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::Revised ID Needed by Amy Vezza
2009-12-17
03 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss by Alexey Melnikov
2009-12-17
03 Alexey Melnikov
[Ballot comment]
Updated as per revision -02:

Sorry about flipping back and forth between YES and DISCUSS. But I think the following text is a …
[Ballot comment]
Updated as per revision -02:

Sorry about flipping back and forth between YES and DISCUSS. But I think the following text is a bit confusing. (I am happy to clear if I misunderstood something):

4. Renegotiation Protection Request Signalling Cipher Suite Value

  In order to enhance compatibility with such
  servers, this document defines a second signalling mechanism via a
  special signalling cipher suite value (SCSV)
  "TLS_RENEGO_PROTECTION_REQUEST", with code point 0xNN, 0xMM.  This
  SCSV is not a true cipher suite and cannot be negotiated.  It merely
  has exactly the same semantics as an empty "renegotiation_info"
  extension.

and then later on in the same section:

  Note that a minimal client which does not support renegotiation at
  all can simply use the SCSV in all initial handshakes.  Any compliant
  server MUST generate a fatal "handshake_failure" alert and terminate
  the connection when it sees any (apparent) attempt at renegotiation
  by such a client.  Clients which do support renegotiation MUST
  implement Section 3 as well.

Does this mean that any use of SCSV means that the client doesn't support renegotiation? And does this mean that the use of the new TLS extension and the use of SCSV are not the same thing?


3.  Extension Definition

  This requirement to
  validate any received RI extension still applies even after previous

The acronym RI should be explained on first use.

  handshakes on the same the connection or session did not negotiate
  the use of RI.  Every handshake must be treated independently in this
  respect because the attacker may attempt to make an initial handshake
  appear as a renegotiation handshake or vice-versa.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-17
03 Alexey Melnikov [Ballot discuss]
2009-12-17
03 Alexey Melnikov
[Ballot comment]
3.  Extension Definition

  This requirement to
  validate any received RI extension still applies even after previous

The acronym RI should be …
[Ballot comment]
3.  Extension Definition

  This requirement to
  validate any received RI extension still applies even after previous

The acronym RI should be explained on first use.

  handshakes on the same the connection or session did not negotiate
  the use of RI.  Every handshake must be treated independently in this
  respect because the attacker may attempt to make an initial handshake
  appear as a renegotiation handshake or vice-versa.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-17
03 Alexey Melnikov
[Ballot discuss]
Updated as per revision -02:

Sorry about flipping back and forth between YES and DISCUSS. But I think the following text is a …
[Ballot discuss]
Updated as per revision -02:

Sorry about flipping back and forth between YES and DISCUSS. But I think the following text is a bit confusing. (I am happy to clear if I misunderstood something):

4. Renegotiation Protection Request Signalling Cipher Suite Value

  In order to enhance compatibility with such
  servers, this document defines a second signalling mechanism via a
  special signalling cipher suite value (SCSV)
  "TLS_RENEGO_PROTECTION_REQUEST", with code point 0xNN, 0xMM.  This
  SCSV is not a true cipher suite and cannot be negotiated.  It merely
  has exactly the same semantics as an empty "renegotiation_info"
  extension.

and then later on in the same section:

  Note that a minimal client which does not support renegotiation at
  all can simply use the SCSV in all initial handshakes.  Any compliant
  server MUST generate a fatal "handshake_failure" alert and terminate
  the connection when it sees any (apparent) attempt at renegotiation
  by such a client.  Clients which do support renegotiation MUST
  implement Section 3 as well.

Does this mean that any use of SCSV means that the client doesn't support renegotiation? And does this mean that the use of the new TLS extension and the use of SCSV are not the same thing?
2009-12-17
03 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-12-17
03 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes by Alexey Melnikov
2009-12-17
03 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-12-17
03 Alexey Melnikov
[Ballot comment]
3.  Extension Definition

  This requirement to
  validate any received RI extension still applies even after previous

The acronym RI should be …
[Ballot comment]
3.  Extension Definition

  This requirement to
  validate any received RI extension still applies even after previous

The acronym RI should be explained on first use.

  handshakes on the same the connection or session did not negotiate
  the use of RI.  Every handshake must be treated independently in this
  respect because the attacker may attempt to make an initial handshake
  appear as a renegotiation handshake or vice-versa.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-17
03 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2009-12-17
03 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss by Alexey Melnikov
2009-12-17
03 Alexey Melnikov
[Ballot comment]
1.  Introduction

[...]

  If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated …
[Ballot comment]
1.  Introduction

[...]

  If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated
  client identity.  Even without certificate-based authentication, a
  variety of attacks may be possible in which the attacker convinces
  the server to accept data from it as data from the client.  For
  instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the

[REF] is not defined in References.

  attacker may be able to generate a request of his choice validated by
  the client's cookie.


4.  Renegotiation Protection Request Cipher Suite

  Because this cipher suite is equivalent to an empty
  "renegotiation_info" extension, only renegotiation_info" may be used

nit: missing <"> before the second renegotiation_info and missing "for" at the end of this line.

  rehandshakes.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-17
03 Alexey Melnikov [Ballot discuss]
2009-12-17
03 Pasi Eronen State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Pasi Eronen
2009-12-17
03 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-12-16
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-12-16
02 (System) New version available: draft-ietf-tls-renegotiation-02.txt
2009-12-16
03 Alexey Melnikov
[Ballot comment]
1.  Introduction

[...]

  If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated …
[Ballot comment]
1.  Introduction

[...]

  If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated
  client identity.  Even without certificate-based authentication, a
  variety of attacks may be possible in which the attacker convinces
  the server to accept data from it as data from the client.  For
  instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the

[REF] is not defined in References.

  attacker may be able to generate a request of his choice validated by
  the client's cookie.


4.  Renegotiation Protection Request Cipher Suite

  Because this cipher suite is equivalent to an empty
  "renegotiation_info" extension, only renegotiation_info" may be used

nit: missing <"> before the second renegotiation_info and missing "for" at the end of this line.

  rehandshakes.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-16
03 Alexey Melnikov
[Ballot discuss]
I will be moving to Yes after discussing this issue.

I believe due to seriousness of this issue the document needs to include: …
[Ballot discuss]
I will be moving to Yes after discussing this issue.

I believe due to seriousness of this issue the document needs to include:

Updates: 5246, 4366, 4346, 2246

Also, I would like to get a response to the following question:

1.  Introduction

  To start the attack, the attacker forms a TLS connection to the
  server (perhaps in response to an initial intercepted connection from
  the client).  He then sends any traffic of his choice to the server.
  This may involve multiple requests and responses at the application
  layer, or may simply be a partial application layer request intended
  to prefix the client's data.  This traffic is shown with == to
  indicate it is encrypted.  He then allows the client's TLS handshake
  to proceed with the server.  The handshake is in the clear to the
  attacker but encrypted over the attacker's channel to the server.
  Once the handshake has completed, the client communicates with the
  server over the new channel.  The attacker cannot read this traffic,
  but the server believes that the initial traffic to and from the
  attacker is the same as that to and from the client.

Please correct me if I am wrong, but my understanding is that
the server would believes that the initial traffic sent by the
attacker is coming from the client not because this is a problem with how
TLS itself works, but this is actually a problem with how existing TLS APIs work. If that is the case, it would be helpful to say this here.
2009-12-16
03 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Objection by Alexey Melnikov
2009-12-16
03 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-12-16
03 Pasi Eronen State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Pasi Eronen
2009-12-16
03 Pasi Eronen Note field has been cleared by Pasi Eronen
2009-12-16
03 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-12-15
03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-12-15
03 Adrian Farrel
[Ballot comment]
I have some sympathy with Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need …
[Ballot comment]
I have some sympathy with Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need the renegotiation feature.
2009-12-15
03 Adrian Farrel
[Ballot comment]
I have some sympathy witrh Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need …
[Ballot comment]
I have some sympathy witrh Russ's Comment, and my initial reaction having read the problem statement was to ask whether we actually need the renegotiation feature.
2009-12-15
03 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-12-15
03 Tim Polk
[Ballot comment]
I am satisfied that this solution is workable and resolves the problem at hand.  I understand that
other solutions exist and have been …
[Ballot comment]
I am satisfied that this solution is workable and resolves the problem at hand.  I understand that
other solutions exist and have been discussed within the working group, but I am less concerned
about the details of the solution than getting a solution completed in a timely fashion.

Let's approve this one now.
2009-12-14
03 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-12-14
03 Alexey Melnikov
[Ballot comment]
1.  Introduction

  To start the attack, the attacker forms a TLS connection to the
  server (perhaps in response to an initial …
[Ballot comment]
1.  Introduction

  To start the attack, the attacker forms a TLS connection to the
  server (perhaps in response to an initial intercepted connection from
  the client).  He then sends any traffic of his choice to the server.
  This may involve multiple requests and responses at the application
  layer, or may simply be a partial application layer request intended
  to prefix the client's data.  This traffic is shown with == to
  indicate it is encrypted.  He then allows the client's TLS handshake
  to proceed with the server.  The handshake is in the clear to the
  attacker but encrypted over the attacker's channel to the server.
  Once the handshake has completed, the client communicates with the
  server over the new channel.  The attacker cannot read this traffic,
  but the server believes that the initial traffic to and from the
  attacker is the same as that to and from the client.

Please correct me if I am wrong, but my understanding is that
the server would believes that the initial traffic sent by the
attacker is coming from the client not because this is a problem with how
TLS itself works, but this is actually a problem with how existing TLS APIs work. If that is the case, it would be helpful to say this here.

[...]

  If certificate-based client authentication is used, the server will
  believe that the initial traffic corresponds to the authenticated
  client identity.  Even without certificate-based authentication, a
  variety of attacks may be possible in which the attacker convinces
  the server to accept data from it as data from the client.  For
  instance, if HTTPS [RFC2818] is in use with HTTP cookies [REF], the

[REF] is not defined in References.

  attacker may be able to generate a request of his choice validated by
  the client's cookie.


4.  Renegotiation Protection Request Cipher Suite

  Because this cipher suite is equivalent to an empty
  "renegotiation_info" extension, only renegotiation_info" may be used

nit: missing <"> before the second renegotiation_info and missing "for" at the end of this line.

  rehandshakes.

7.  Security Considerations

[...]

  By default, TLS implementations conforming to this document MUST
  verify that once the peer has been identified and authenticated
  within the TLS handshake, the identity does not change on subsequent
  renegotiations.  For certificate based cipher suites, this means
  bitwise equality of the end-entity certificate.  If the other end
  attempts to authenticate with a different identity, the renegotiation
  MUST fail.  If the server_name extension is used, it MUST NOT change
  when doing renegotiation.

I found the "by default" part to be confusing until I read the following paragraph. May I suggest that for clarify you make them a single paragraph?

  A TLS library MAY provide a means for the application to allow
  identity and/or server_name changes across renegotiations, in which
  case the application is responsible for tracking the identity
  associated with data it is processing.  This may require additional
  API facilities in the TLS library.
2009-12-14
03 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-12-14
03 Russ Housley
[Ballot comment]
As a protocol climbs the IETF standards-track maturity ladder, we
  sometimes drop features.  I would rather see renegotiation dropped
  from TLS …
[Ballot 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.
2009-12-14
03 Russ Housley [Ballot Position Update] New position, Abstain, has been recorded by Russ Housley
2009-12-14
03 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-12-14
03 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-12-11
03 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded by Cullen Jennings
2009-12-09
03 Amanda Baber
IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "ExtensionType Values" registry at
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Value Extension name …
IANA comments:

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "ExtensionType Values" registry at
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Value Extension name Reference
---------- --------------- ---------
TBD(0xff01) renegotiation_info [RFC-tls-renegotiation-01]


Action 2:

Upon approval of this document, IANA will make the following assignment
in the "TLS Cipher Suite Registry" at
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Value Description Reference
----- ----------- ---------
TBD TLS_RENEGO_PROTECTION_REQUEST [RFC-tls-renegotiation-01]


We understand the above to be the only IANA Actions for this document.
2009-12-08
03 Pasi Eronen [Ballot Position Update] New position, Yes, has been recorded for Pasi Eronen
2009-12-08
03 Pasi Eronen Ballot has been issued by Pasi Eronen
2009-12-08
03 Pasi Eronen Created "Approve" ballot
2009-12-08
03 Pasi Eronen Placed on agenda for telechat - 2009-12-17 by Pasi Eronen
2009-11-30
03 Amy Vezza Last call sent
2009-11-30
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-11-28
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2009-11-28
03 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Hartman
2009-11-27
03 Pasi Eronen Last Call was requested by Pasi Eronen
2009-11-27
03 Pasi Eronen State Changes to Last Call Requested from Publication Requested by Pasi Eronen
2009-11-27
03 (System) Ballot writeup text was added
2009-11-27
03 (System) Last call text was added
2009-11-27
03 (System) Ballot approval text was added
2009-11-27
03 Pasi Eronen State Changes to Publication Requested from AD is watching by Pasi Eronen
2009-11-27
03 Pasi Eronen Draft Added by Pasi Eronen in state AD is watching
2009-11-26
01 (System) New version available: draft-ietf-tls-renegotiation-01.txt
2009-11-19
00 (System) New version available: draft-ietf-tls-renegotiation-00.txt