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 |