Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 30 Nov 2009 07:37:34 -0800 (PST)

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
   <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-12-14. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rfc_flag=0

---

From: Marsh Ray <[email-masked]>
Date: Mon, 30 Nov 2009 10:31:35 -0600

A few little suggestions, mostly wording.

>    <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard

http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01

[Page 3]
>    renegotiation handshakes to the enclosing TLS channel, thus allowing
>    the server to differentiate renegotiation from initial negotiation,
>    as well as preventing renegotiations from being spliced in between
>    connections.  

"spliced in between sessions."

[Page 5]
>    o  For ClientHellos which are renegotiating, this field contains the

"the renegotiated_connection field contains"

[Page 6]
>    Both the SSLv3 and TLS 1.0/TLS1.1 specifications require
>    implementations to ignore data following the ClientHello (i.e.,
>    extensions) if they do not understand it.  However, some SSLv3 and
>    TLS 1.0 implementations incorrectly fail the handshake in such case.
>    This means that clients which offer "renegotiation_info" may find
>    handshake failures.  In order to enhance compatibility with such
>    servers, this document defines a second signalling mechanism via a
>    special TLS cipher suite "TLS_RENEGO_PROTECTION_REQUEST", with code
>    point 0xNN, 0xMM.  This cipher suite has exactly the same semantics
>    as an empty "renegotiation_info" extension.  Because servers
>    ordinarily ignore unknown cipher suites, this cipher suite can be
>    added safely on any initial handshake, including SSLv2 backward
>    compatibility handshakes.
> 
>    Servers MUST treat receipt of TLS_RENEGO_PROTECTION_REQUEST exactly
>    as if the client had sent an empty "renegotiation_info" extension and
>    respond with their own "renegotiation_info" extension.  This is an
>    explicit exception to the RFC 5246 Section 7.4.1.4 prohibition on the
>    server sending unsolicited extensions and is only allowed because the
>    client is signaling its willingness to receive the extension via the
>    the TLS_RENEGO_PROTECTION_REQUEST cipher suite.  TLS implementations
>    MUST continue to comply with 7.4.1.4 for all other extensions.
>    Servers MUST NOT select this cipher suite in any handshake, as it
>    does not correspond to any valid set of algorithms.
> 
>    Because this cipher suite is equivalent to an empty
>    "renegotiation_info" extension, only renegotiation_info" may be used
>    rehandshakes.
> 
>    Note that a minimal client which does not support renegotiation at
>    all can simply use this cipher suite in all initial handshakes.  Any
>    compliant server will reject any (apparent) attempt at renegotiation
>    by such a client.  Clients which do support renegotiation MUST
>    implement Section 3 as well.

I suggest we replace all uses of "cipher suite" in this section with the
term "cipher suite value", and we add explicit wording "The
TLS_RENEGO_PROTECTION_REQUEST cipher suite value is just a flag, it does
not actually a refer to a set of cryptographic algorithms that could
ever be used for data transmission."

This might seem obvious to all of us, but this wording change could
conceivably speed review and fend off questions by some review board.

>    TLS clients which support this draft MUST generate either the
> 
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    cipher suite with every ClientHello.

Can they generate both?

If not, what does the server do if he receives both?

>    Existing implementations which do not support this extension are
>    widely deployed and in general must interoperate with newer
>    implementations which do support it.  This section describes

s/must/need to/ to avoid confusion with MUST.

>    If a client offers the "renegotiation_info" extension or the
>    TLS_RENEGO_PROTECTION_REQUEST cipher suite and the server does not
>    reply with "renegotiation_info" in the ServerHello, then this
>    indicates that the server either does not support secure
>    renegotiation or is unwilling to use it.

Is it allowed for a patched server to be "unwilling"?

If not, drop the "or is unwilling to use it" lest it give the impression
that such behavior is condoned.

>    If the client does not offer the "renegotiation_info" extension or
>    the TLS_RENEGO_PROTECTION_REQUEST cipher suite then this indicates
>    that the client does not support secure renegotiation or is unwilling
>    to use it.  However, because the above attack looks like two

Again, is it allowed for a client to be conformant to this spec and
still not send either the extension or magic cipher suite value?

- Marsh

---

From: "Robert Dugal" <[email-masked]>
Date: Mon, 30 Nov 2009 12:15:38 -0500

I support draft-ietf-tls-renegotiation-01.txt. 

-- 
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 The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: [email-masked]
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard

_______________________________________________
TLS mailing list
[email-masked]
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.

---

From: "Rob P Williams" <[email-masked]>
Date: Mon, 30 Nov 2009 13:12:59 -0500

I support this draft.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: [email-masked]
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport
LayerSecurity (TLS) Renegotiation Indication Extension) toProposed
Standard

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
19412&rfc_flag=0

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 30 Nov 2009 10:19:45 -0800

What I'm seeing here:

An implementation continues to be conformant to TLS even if the RI
isn't sent.  If a client doesn't send the RI (either cipher suite flag
or extension), the server can't send the RI extension back (as it's a
violation of TLS 1.2 for a server to send an unsolicited extension).
If a client does send the RI cipherflag or extension, the server may
send back the RI reply, or (if its security policy prohibits
renegotiation -- to reduce the possible impact of large numbers of
reneg's overwhelming any crypto implementation, or because it's known
that client certificates are never going to be solicited by the
server, to name a couple of possible reasons) it may choose not to
reply with the extension.

In the event that the RI client doesn't receive the extension that it
solicited back from the server, it treats it as a non-RI server and
proceeds according to its own security policy.

(It goes without saying that the peers' security policies must have
some compatibility -- FIPS 140-2 validated TLS implementations already
can't talk to implementations that don't have any FIPS-approved
algorithms, so there's no reason to worry about this.)

> If not, what does the server do if he receives both?

I suggest the wording 'MUST generate either or both of the RI
extension or the TLS_RENEGO_PROTECTION_REQUEST cipher suite flag with
every ClientHello.  If the client requests renegotiation, it must do
so with the same mechanism(s) that it used during the initial
ClientHello -- e.g. if the client uses the RI extension without the
cipher suite flag, then ClientHello handshake messages used for
renegotiation must not contain the cipher suite flag.'

> s/must/need to/ to avoid confusion with MUST.

Agreed.

> that such behavior is condoned.

Above, I've suggested a couple of potential reasons why a server
(which knows about the renegotiation security hole) might simply
disable renegotiation entirely.

> still not send either the extension or magic cipher suite value?

A client may be conformant to this specification without sending
either the RI ext or the cipher suite flag, if it knows that it will
not perform or accept any requests to perform any renegotiations.  If
it does not, the server will believe that it is an unpatched client
and expect/accept only one negotiation.  Why indicate your willingness
to do something that you're not willing to do later anyway?

I'd suggest adding wording to this effect, suggesting that
implementations SHOULD offer this extension only if they're willing to
accept renegotiations.  (Local security policies may include "all
traffic that goes over the internet must appear as though it's coming
from servers that will renegotiate" -- if only as a prophylactic
against someone doing deep packet scanning and seeing a potentially
insecure server for later attack attempts.)

-Kyle H

---

From: Marsh Ray <[email-masked]>
Date: Mon, 30 Nov 2009 12:47:28 -0600

Kyle Hamilton wrote:
> isn't sent.

Sure, but is it compliant with draft-ietf-tls-renegotiation?

I suggest that it shouldn't be.

> If a client doesn't send the RI (either cipher suite flag

What is the benefit to anyone of a patched server not replying with the
extension when it was specifically requested by the client?

Allowing that just adds (or multiplies) in another valid combination
that has to be regression tested.

> proceeds according to its own security policy.

Which a year from now ought to be "don't connect to servers who's admins
don't care enough to apply security patches in a year".

> every ClientHello.

Agreed.

> If the client requests renegotiation, it must do

Why?

What if the client used the MCS flag for the initial handshake? How can
he send the verify_data if there's no RI in the second handshake?

If it must be restricted, I'd prefer that the MCS flag be allowed only
on initial hello and banned on renegotation handshakes.

> disable renegotiation entirely.

Sure, but that's not a reason to not reply with RI when requested. It's
not a reason for the server to not tell the client that it is, in fact,
patched.

> not perform or accept any requests to perform any renegotiations.

The client doesn't necessarily see the renegotiation, so it can't know
that it's not taking part in one.

> If
> and expect/accept only one negotiation.

If it's been patched and configured such that it talks to insecure clients.

> Why indicate your willingness
> accept renegotiations.

Why should the client advertise that he's willing or not willing to
renegotiate? What if the API and existing application code defers that
decision until later?

A client app that is willing renegotiate only just after submitting an
HTTP request and if the user could possibly approve the client cert
request. Client certs could become enabled at any time and shouldn't
cause existing connections to break!

IMHO a patched client should always send the magic cipher suite so the
server can prevent MitM. That way you don't have to force the server
into making the difficult decision as to whether or not to join in on a
possibly-compromised connection.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 30 Nov 2009 22:10:02 +0100

On Nov 30, 2009, at 4:37 PM, The IESG wrote:

> [email-masked] mailing lists by 2009-12-14.

I support the move, contingent to two clean-ups to specified behavior:

1. Section 3 specifies "For ClientHellos which are renegotiating, this  
field contains the verify_data from the Finished message sent by the  
client on the immediately previous handshake", and "For ServerHellos  
which are renegotiating, this field contains the concatenation of the  
verify_data values sent by the client and the server (in that order)  
on the immediately previous handshake."

There is no good reason for this asymmetry of having just the client's  
verify_data in the client's message, but both the client's and the  
server's verify_data in the server's message -- the latter is pure  
overhead, both in the specification and in the on-the-wire protocol.   
To remove the overhead from both, the second sentence should be  
saying, "For ServerHellos which are renegotiating, this field contains  
the verify_data sent by the server on the immediately previous  
handshake" (according changes to dependent parts of the specification  
then should be made).

For earlier Internet Drafts in the series preceding draft-ietf-tls- 
renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.),  
a reason to keep the current text would have been to maintain  
compatibility with early implementations of those Internet Drafts.   
However, draft-ietf-tls-renegotiation-01 has a newer  
TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks  
compatibility with those early implementations anyway.

(This means that now, changing the ServerHello extension definition as  
suggested above gives the beneficial side-effect of exposing premature  
implementations, besides merely avoiding overhead.  Those incomplete  
implementations will be more obviously incompatible because they'd  
still be using the protocol variant with overhead, instead of just  
differing subtly in the behavior if faced with  
TLS_RENEGO_PROTECTION_REQUEST.)

2. The Security Considerations section of draft-ietf-tls- 
renegotiation-01.txt (section 7) includes language that unnecessarily  
restricts the flexibility that the TLS protocol specifically provides  
for, regulating areas that the TLS standard intentionally does not  
specify (RFC 5246 section 1) -- the current Internet Draft says:

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

There is no security reason for this restriction.  This sounds like a  
bad and incomplete workaround for certain problems with TLS that the  
updated protocol does not need a workaround for at all, because the  
protocol update is all about properly *solving* those problems.

Keeping this language in the specification would have the weird  
implication that applications that *need* the flexibility provided by  
the TLS protocol (e.g., to allow renegotiation handshakes to switch to  
a different ciphersuite, which may require a different certificate)  
would have to to *skip* implementing the protocol update, and thus  
stay vulnerable.

The new restriction that draft-ietf-tls-renegotiation-01.txt tries to  
sneak in thus seems harmful both for interoperability and for  
security.  I haven't seen any signs of working group consensus on  
including this new restriction.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Mon, 30 Nov 2009 15:52:44 -0600

Bodo Moeller wrote:
> overhead, both in the specification and in the on-the-wire protocol.  To
> remove the overhead from both, the second sentence should be saying,
> "For ServerHellos which are renegotiating, this field contains the
> verify_data sent by the server on the immediately previous handshake"
> (according changes to dependent parts of the specification then should
> be made).

Good point.

> For earlier Internet Drafts in the series preceding
> draft-ietf-tls-renegotiation-01.txt
> (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the
> current text would have been to maintain compatibility with early
> implementations of those Internet Drafts.  However,
> draft-ietf-tls-renegotiation-01 has a newer
> TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility
> with those early implementations anyway.
> 
> implementations will be more obviously incompatible because they'd still
> be using the protocol variant with overhead, instead of just differing
> subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.)

I don't think any of those implementations have shipped, and I don't
think anyone has advertised that code as anything but experimental.

It might not hurt for the IANA to assign a different number to the
extension than what was used for testing.

> 2. The Security Considerations section of
> draft-ietf-tls-renegotiation-01.txt (section 7) includes language that
> unnecessarily restricts the flexibility that the TLS protocol
> specifically provides for, regulating areas that the TLS standard
> intentionally does not specify (RFC 5246 section 1) -- the current
> Internet Draft says:
> 
> "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."
> 
> There is no security reason for this restriction.

+1 Agree

> This sounds like a
> the TLS protocol (e.g., to allow renegotiation handshakes to switch to a
> different ciphersuite, which may require a different certificate) would
> have to to *skip* implementing the protocol update, and thus stay
> vulnerable.

Excellent point.

Although the sentence after the one you quoted seems to say that
implementations are allowed to do it anyway if they choose. Which raises
the question as to what this language actually means for the wire
protocol, anyway.

> sneak in thus seems harmful both for interoperability and for security. 
> I haven't seen any signs of working group consensus on including this
> new restriction.

Details about which certificates endpoints should be allowed or
forbidden to negotiate is outside the scope of this bugfix.

We should remove it.

- Marsh

---

From: Nasko Oskov <[email-masked]>
Date: Mon, 30 Nov 2009 21:58:05 +0000

Bodo Moeller wrote:
>> final comments on this action.  Please send substantive comments to 
>> the [email-masked] mailing lists by 2009-12-14.
>

I support the 01 version of the draft, assuming we address this point:

>restricts the flexibility that the TLS protocol specifically provides for,
>regulating areas that the TLS standard intentionally does not specify (RFC
>5246 section 1) -- the current Internet Draft says:
>
>handshake, the identity does not change on subsequent renegotiations. For
>certificate based cipher suites, this means bitwise equality of the
>There is no security reason for this restriction.  This sounds like a bad
>and incomplete workaround for certain problems with TLS that the updated
>protocol does not need a workaround for at all, because the protocol update
>is all about properly *solving* those problems.

I agree that this restriction is not necessary for solving the current
problem. If the section should stay, I would vote for making it a SHOULD and
definitely not a MUST.

>Keeping this language in the specification would have the weird implication
>that applications that *need* the flexibility provided by the TLS protocol
>(e.g., to allow renegotiation handshakes to switch to a different
>ciphersuite, which may require a different certificate) would have to to
>*skip* implementing the protocol update, and thus stay vulnerable.

What about certificate renewal? Once a cert is renewed, it is different when
it comes to bitwise comparison, yet it is the same identity. I do not think
doing bitwise comparisons and dealing with identity at the TLS layer should
be part of this draft.

Nasko

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 30 Nov 2009 23:19:40 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt

I believe the decision to take this draft to Last Call was premature, and
that further discussion in the WG is necessary before deciding whether to
adopt draft-ietf-tls-renegotiation or an alternative.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 30 Nov 2009 20:51:28 -0800

Paragraph 3 of section 4 says:

Leaving aside the incorrect punctuation, this doesn't make any sense to me.

In section 5, suggest replacing all occurrences of the word "draft" with the
word "specification".

In section 6.2, s/NOT allow clients who do not offer the
"renegotiation_info" extension/NOT allow clients which do not offer the
"renegotiation_info" extension/.