Subject: [TLS] Updated draft

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Dec 2009 13:32:02 -0800

I've just submitted a new draft that is intended to enact most of
Pasi's message as well as the noncontroversial editorial comments
people have raised. Here is what I know still needs work:

- The final resolution to what's sent in the legacy renegotiation
  case (see Pasi's message and the text I sent earlier).
- New text for the identity section in Security considerations.
  (Pending closure on the list).
- Make a pass through for clarity for implementors. 
  (Also, I have some text here that Pasi contributed that I
  need to work in).

If you think you made a comment which is noncontroversial
that didn't make it in and/or I screwed up incorporating your
comment, please let me know and I'll try to fix.

For some reason, the submission tool is forcing manual 
submission. In the interim you can find it at:
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt

Thanks,
-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 17 Dec 2009 10:09:11 -0800

s/signalling/signaling/g

In section 4 it says:

    Because the SCSV is equivalent to an empty "renegotiation_info"
    extension, any ClientHello used for secure renegotiation MUST include
    the "renegotiation_info" extension and not the SCSV.

I would rather see the text say that "an RI extension takes precedence
over the SCSV" than to say that you must not send SCSV when you send RI.
It is easier for a client to simply include SCSV in every ClientHello.
It is also trivial for a server to handle this, as I pointed out in my
last message.

Mike

---

From: "Robert Dugal" <[email-masked]>
Date: Fri, 18 Dec 2009 07:10:29 -0500

I would also like to see that change in the draft. 

To increase interoperability with existing servers I would like the option to send SCSV 
in the initial ClientHello and only send the TLS extension in renegotiation handshakes.
This will make it easier for applications as they won't have to make a decision as to 
whether the server is TLS extension intolerant.

-- 
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 Michael D'Errico
Sent: Thursday, December 17, 2009 1:09 PM
To: TLS Mailing List
Subject: Re: [TLS] Updated draft

s/signalling/signaling/g

In section 4 it says:

Mike

> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-ietf-tls-renegotiate.txt
_______________________________________________
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: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 08:42:08 -0600

> in the initial ClientHello and only send the TLS extension in renegotiation handshakes.

Isn't that how it's worded now?

> whether the server is TLS extension intolerant.

If I were writing a new app that wasn't intended to be the most widely
used web browser in the world, I wouldn't bother with the SCSV at all.

Otherwise, just send it every time instead of an empty RI extension.

- Marsh

---

From: "Robert Dugal" <[email-masked]>
Date: Fri, 18 Dec 2009 10:08:40 -0500

Oops, you're right. I misstated what I'd like the draft to allow.
What I'd like is the option to always send the SCSV in the ClientHello and on renegotiation requests send the SCSV + RI extension in the ClientHello.

-----Original Message-----
From: Marsh Ray [mailto:[email-masked]] 
Sent: Friday, December 18, 2009 9:42 AM
To: Robert Dugal
Cc: TLS Mailing List
Subject: Re: [TLS] Updated draft

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Dec 2009 07:31:53 -0800

At Thu, 17 Dec 2009 10:09:11 -0800,
> It is also trivial for a server to handle this, as I pointed out in my

This implements the following point from Pasi's message.

  - There was some discussion on whether to add the magic cipher suite
  to patched renegotiation ClientHellos (in addition to the extension),
  too. I believe rough consensus is not to do this.

It's of course possible I misunderstood.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 16:48:47 +0100 (MET)

> It's of course possible I misunderstood.

I believe that Pasi mainly tried to summarize what he found in
the discussion, and that discussion was huge and pretty fragmented.
A lot of things were discussed with a number of different semantics.

Personllay, I find it difficult to assess consensus on some topics
of the severely fragmented discussions.

I would like to read Pasi's summary as a suggestion to the Working
Group how to resolve the discussed issues, and it is up to the working
group to decide whether the individual items are actually the outcome
with the most support.

Certainly we do not want to re-open each and every issue again.

What Mike and Robert are writing looks like implementers experience
to me, they tried to add the current changes in the spec and are
requesting changes that would make their implementation simpler.

I would appreciate if the spec would be more careful about
MUST NOTs, because we exhibit a tendency to be overly strict
in our specs.  (I had a servere MUST NOT infection in
my first draft, and removing all except those that are actually
required made my document more comprehensible).

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 10:37:00 -0600

Robert Dugal wrote:
> What I'd like is the option to always send the SCSV in the
> ClientHello and on renegotiation requests send the SCSV + RI
> extension in the ClientHello.

That certainly sounds like a reasonably minor change to make...but it isn't.

I don't recall seeing anyone propose wording changes that would allow
such behavior, except in the context of the other proposals which are
fundamentally different in that they modify the inputs to the PRF. It's
possible that some concrete wording was suggested and is in one of the
1340 emails in my TLS folder.

Currently, the SCSV achieves its primary objective with a very simple
definition. It has "exactly the same semantics as an empty
'renegotiation_info' extension".

IMHO, proponents of other semantics for SCSV should be able to produce
an equally straightforward description of what they are, or show
something truly magical to justify complicating the description. Saving
an 'if' statement somewhere, partially fixing a multiply-broken
scenario, or avoiding extensions handling in some non-general case don't
sound like they justify the extra complexity.

Personally, I'd prefer that we don't propose (and re-propose) design
features at this point. We have to ship a fix for this open security
vulnerability, and I think the current design is squarely in the "good
enough" department. I.e. it fixes the problem and doesn't make anything
else significantly worse.

If anyone sees a security flaw or attack against a correct
implementation of draft-ietf-tls-renegotiation-02, please please speak up.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 18:13:50 +0100 (MET)

Marsh Ray wrote:
> That certainly sounds like a reasonably minor change to make.

Full agreement.

> such behavior,

I can help you solve that problem:

   http://www.imc.org/ietf-tls/mail-archive/msg11082.html
   http://www.ietf.org/mail-archive/web/tls/current/msg05305.html

I know how you feel, I'm having analogus problem with my memory,
I can not remember anyone making a technical argument for this particular
MUST NOT here.  I already asked Pasi:

   http://www.ietf.org/mail-archive/web/tls/current/msg05401.html

but he doesn't seem to recall anything either.

> 'renegotiation_info' extension".

That seems to be a fairly simple copy&paste error, and can easily
be fixed by simple wordsmithing.

It is fairly common that an initially beautiful wording turns
out to add unnecessary implementation complexity when the first
implementors get at the code.

That usually isn't a problem, since the IETF favours running code
over wording in the spec.  Implementors feedback is extremely
valuable.

> features at this point.

We're discussing a simple implementation detail, it does not touch
the design of the underlying architecture.

> implementation of draft-ietf-tls-renegotiation-02, please please speak up.

If anyone sees a security flaw or technical problem with dropping
this MUST NOT, then please speak up.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 18 Dec 2009 09:18:48 -0800

I disagree with Pasi and with the current wording in the draft.  That
was the reason I sent the message.  I'd like to see this changed.  I
have implemented the spec, and see that it creates a MUST NOT that is
unnecessary.

The current draft suggests that if a server sees SCSV in cipher suites
and then sees RI in the ClientHello.extensions, it must abort the
handshake!  That is not necessary at all.  The RI simply overrides the
SCSV if it contains any data.  It is trivial for a server to handle
receiving both:

    - if SCSV is encountered, set a flag
    - if RI is encountered, set the same flag and extract the data

These happily coexist with no special cases, so requiring an abort is
not a good idea; it just adds complexity.

The problem appears to be the statement that SCSV is equivalent to an
empty RI, and thus would be a conflict if there was also an RI with
data.  This can be fixed by saying that SCSV is to be ignored when an
RI is also received.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 18 Dec 2009 17:23:04 +0000

Please Martin, the level of argument here is declining
badly.

> That certainly sounds like a reasonably minor change to make...but it
isn't.

Which is totally different.

For me, such tactics, and frequent exaggeration, badly damage
whatever it is you're trying to say in the many many long posts
you've sent on this topic. I think its past time to stop all
that.

Stephen.

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 18:30:12 +0100 (MET)

> Which is totally different.

Marsh made two statements:
 (1) it sounds like a reasonably minor change
 (2) Marsh thinks it is not a reasonably minor change

I fully agree with the first.

-Martin

PS: could we please take discussions about style off-list?

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 18:45:25 +0100 (MET)

> 'renegotiation_info' extension".

How about

TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the
server to perform a secure handshake and confirm this by sending
TLS extension RI in ServerHello.

This will also fix the awkward disconnect between the symbolic name of
the SCSV and the current description of its semantics.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 12:09:41 -0600

>  (2) Marsh thinks it is not a reasonably minor change

Yes, except that I said it wasn't a reasonably minor change to make
which is slightly different than (2).

> PS: could we please take discussions about style off-list?

It's more correctness than style. I think it's quite on-topic
considering that this WG is about a protocol for communications which
must be perfect.

Chopping up quotes below the level of whole sentences is not real
helpful for productive discussions. It's like some sort of fragmentation
attack.

This whole discussion could be some sort of meta-recapitulation of the
discussions we've had about the semantics of SCSV. Perhaps it
foreshadows something positive?

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 18:30:12 +0100 (MET)

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 18 Dec 2009 11:25:49 -0800

A limousine pulls up in front of a busy nightclub in LA.  A well-dressed
couple emerge and approach the entrance.  The bouncer greets them with a
smile and says, "you two arrived in a Swanky Comfortable Stretch Vehicle;
you must be very important, so please go right on in."

Later, a beat-up Buick with one headlight out pulls up in front of the
club.  After tipping the valet, the driver approaches the entrance to the
bar.  The bouncer puffs his chest and stops the man from entering.  "Where
do you think you're going?" he asks.  The man pulls something out of his
pocket and shows it to the bouncer.  "Oh, you have an invitation to the
party; you must be Really Important, my apologies."

Soon another limousine arrives and a Hollywood starlet gets out.  When she
reaches the bouncer, she hands him her invitation to the party.  "Here you
are, darling -- my invitation."  "I'm sorry, but I can't let you in,"
replies the bouncer, "you are apparently Really Important, but you arrived
in a Swanky Comfortable Stretch Vehicle, so I can't let you in."  "Of all
the.... I demand to speak to your manager, what is your name?"  "My name
is Xor, madam.  May I suggest you ditch the limo and come back in a less-
fancy car?  We'll reconnect then, and I'll let you in."

Mike

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 13:31:13 -0600

> TLS extension RI in ServerHello.

But what does that mean? What is "a secure handshake" if you're not
sending the RI extension? To the extent that this document is describing
how to perform a secure handshake, that definition is circular.

So there are three cases with the SCSV:

A. SCSV without RI extension.
B. SCSV with empty RI extension.
C. SCSV with non-empty RI extension.

The current draft-ietf-tls-renegotiation-02 defines A as semantically
equivalent to an empty RI extension. That appeals to me greatly, but it
is certainly not the only way to look at it.

Cases B and C are currently undefined AFAICT. We should fix this.

Case B looks redundant under the current wording. RFC 3546 does not seem
to say anything about multiple extensions of the same type.

Case C looks like it's self-conflicting.

So if I understand the current discussion correctly, it is about whether
or not cases B and C are explicitly forbidden or explicitly allowed?

== (I) Here's some proposed wording to fix the issue with in the favor
of forbidding cases B and C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. Clients MUST NOT send the SCSV in the same
> Client Hello message as any RI extension, not even an empty one.
>
> A server receiving a Client Hello containing multiple RI extensions
> or the SCSV and one or more RI extensions MUST generate a fatal
> "decode_error" alert and terminate the connection.

== (II) Wording (which explicitly allows case B but forbids C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. A client MAY specify the SCSV in the same
> Client Hello message as an empty RI extension, but MUST NOT specify
> the SCSV in the same Hello as a non-empty RI.
>
> A server receiving a Client Hello containing multiple RI extensions
> or the SCSV and one or more non-empty RI extensions MUST generate
> a fatal "decode_error" alert and terminate the connection.

We'll have to fix the conflict with the current:
> 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.

to something like:
> This SCSV is not a true cipher suite and cannot be negotiated, it
> has similar semantics as an empty "renegotiation_info" extension.

== (III) Wording which explicitly allows both cases B and C:

> Clients MUST NOT put multiple occurrences of an RI extension in the
> same Client Hello message. A client MAY specify the SCSV in the same
> Client Hello message as an RI extension (the SCSV will be effectively
> ignored).
>
> A server receiving a Client Hello containing multiple RI extensions
> MUST generate a fatal "decode_error" alert and terminate the
> connection. A server receiving a Client Hello containing the SCSV
> and an RI extension is to interpret the RI as usual and ignore the
> SCSV.

We'll have to fix the conflict with the current:
> 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.

to something like:
> This SCSV is not a true cipher suite and cannot be negotiated, it
> has similar semantics as an empty "renegotiation_info" extension.

== Relative benefits.

Clearly the current wording needs to be improved just a bit.

My vote is for (I) because:
* It allows a definition of the meaning of SCSV.
* It involves the least wording change.
* Fewer allowed combinations generally makes security easier to analyze.

Cons of (I):
* Implementers will have to set the SCSV pro programmatically.
* Servers are required to be extra strict in what they accept.

Pros of (II):
* SCSV and empty RI together appear harmlessly redundant.

Cons of (II):
* Clients have flexibility which may surprise servers that weren't
tested in all cases.
* No good definition of what SCSV actually means.

Pros of (III):
* SCSV and empty RI together appear harmlessly redundant.
* Clients can set-and-forget SCSV in all cases.

Cons of (III):
* Clients have flexibility which may surprise servers that weren't
tested in all cases.
* No good definition of what SCSV actually means.

==

> the SCSV and the current description of its semantics.

I feel consistent names are important too, but have avoided questioning
that choice of names.

Now

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 20:44:21 +0100 (MET)

> how to perform a secure handshake, that definition is circular.

"A secure handshake" is one where client and server will check
whether the contents of the TLS renegotiation RI match the
verify_data from the Finished messages from the enclosing TLS session
and TLS peers should abort the handshake if the conveyed information
does not match.  The presence of an empty TLS extension RI in ClientHello
is obviated by presence of SCSV in this ClientHello handshake message.

Do not try to describe scenarios.  That is completely unecessary,
very confusing and you may easily get the description of one of
the cases wrong and cause confusion among implementors.

The implementer's feedback was:
In order to implement this MUST NOT I have to add two extra conditionals
to the code, and I have to build test cases to check whether that doesn't
break anything and whether I am compliant -- but in reality these
two conditionals are completely useless, they do not add any value
to the protocol and neither to the security.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Dec 2009 21:37:23 +0100 (MET)

Dear Marsh, Pasi, Eric, Joe, Nelson and several others,

I want to apologize to you

for having been a mean and offending a*****e at various times
during the discussion on this list over the last 6 weeks.

I really did not mean to slander on anyone's qualification as a
software engineer, and I really envy everyone working for a
smaller company than I do, for not having to wrangle with so
many software logisitics processes as I'm facing in my work.

I'm really only interested in the technology and want to provide
value to my customers based on the technology developed in this
forum, and since many of our customers are running pretty big
intranet installations or our software that is connected to
a lot of hardware controls (materials management, supply chain
management, logistics) with a plethoria of devices I have
never seen myself, I'm concerned about changes to this
technology that may have an impact on the installed base
of our customers.

I assume that those long-standing key contributors to the TLS WG
who were asked to join Project Mogul to help produce a solution
to this serious vulnerability in the TLS protocol had to sign an NDA,
and did not deliberately exclude the rest of us from the discussion.
I could imagine that they felt quite uneasy about this situation.

It is definitely not my intention to get in the way of providing
a solution, I only want to help getting off some rough edges
in the solution so that the likelyhood of casualties and severity
of the damage out in field will be small.

Some of the commercial providers have a lot of experience with
the presence of TLS extensions in the products they ship, because
they have been testing these capabilities over the course of
several years.  Evidently, it hasn't been easy for them either,
visible from the availabilty of re-connect fallbacks to extension-less
Hellos in pretty much all current apps that use TLS implementation
capable of TLS extensions.

For some of the mainstream consumers of this technology, and that
includes us, sending out TLS extensions is a first.  The third-party
OEM SSL library that we acquired 10 years ago has never before sent
out any TLS extensions, and none of our applications on top of
it therefore has any re-connect fallback provisions that could
be used if suddenly sending a TLS extension results in an interop
problem.

In difference to many other software vendors, we support our
software for around 12 years (2 years of that is development,
10 years usage) on a platform, which is what our customers demand
from us and for which they pay a non-negligible amount of maintenance
fees.  This time of active usage is often longer than the maintenance
provided by the vendor of the underlying platform.

It around 40 different hardware platforms and os-releases
(32-bit and 64-bit where available) and includes fairly
exotic platforms such as IBM OS/390 aka z/OS (an EBCDIC-platform,
where our oldest supported OS-release still in use at our customers
is OS/390 10.00), which was dropped out of vendor-support maybe 5 years ago.
More mainstream platforms may be RedHat 6.1, OSF/1 4.0, Solaris 2.6.

It's difficult to find an OEM who covers such a huge variety of platforms
and for such a long time, long exceeding the maintenance of the
OS vendors.

Simply switching from one supplier to another is not an option,
because the is much more to TLS than the wire-protocol.  There are
APIs, API-semantics, and most of all credentials and trust-anchor
management and UIs around that.  Dealing with the PKI-configuration
and policy parts of the software is much more difficult and
time-consuming that dealing with the TLS communication part.

I would really apprececiate if we could get back to work and
treat each other like professional engineers.

Sincerely,
-Martin Rex

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 18:40:56 +0100

Eric

Some possible clarifications in s.2 (perhaps obvious to those who
have read the previous 2,000 posts, but perhaps not to those
coming to this afresh)

initial intercepted connection
initial intercepted TLS connection request (or ClientHello?)

    He then allows the client's TLS handshake
    The attacker then allows the client's TLS handshake

The handshake is in the clear to the attacker
>From the client to the attacker, the handshake is in the clear

encrypted over the attacker's TLS connection to the server.
encrypted over the attacker's TLS connection to the server,
using the security parameters that the attacker has negotiated

the client communicates with the server over the newly established
the client communicates directly with the server over the newly established

the date used in the
the data used in the

channel binding facility."
"channel binding facility".

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 18:41:34 +0100

I find the reference to
      immediately previous handshake
in s.3 unclear.

Thinking of session resumption, as identified in RFC5246, there are three cases
namely
  "The session identifier MAY be from an earlier connection,
   this connection, or from another currently active connection."

Which connection should the immediately previous handshake come from
given that there may be one session and multiple connections
(each of which may be independently re-negotiating) in each of these three
cases?

My grasp of TLS session and TLS connection may not be as crystal clear
as it might be; I see session as defined by a common session
identifier but connection being the construct whose protocol is changed by
this I-D.

Tom Petch

---

From: Marsh Ray <[email-masked]>
Date: Thu, 24 Dec 2009 14:00:45 -0600

>       immediately previous handshake

The complete wording from
http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt :
>    o  For ClientHellos which are renegotiating, this field contains the
>       verify_data from the Finished message sent by the client on the
>       immediately previous handshake.  For current versions of TLS, this
>       will be a 12-byte value.
>    o  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.  For
>       current versions of TLS, this will be a 24-byte value.

> Thinking of session resumption, as identified in RFC5246,

Please don't. :-)

This draft is about renegotiation, session resumption has nothing to do
with it.

I, too, used to conflate renegotiation and resumption but they are
completely unrelated.

The term "resumption" only appears in the document twice, both times
like "even when TLS session resumption is used".

> there are three cases

The term "session identifier" appears nowhere in the draft. Session
identifiers do not play a part in this fix for renegotiation.

> Which connection should the immediately previous handshake come from

The connection that is renegotiating.

Renegotiation is a change in the session state of a single connection.

> (each of which may be independently re-negotiating) in each of these three

Sessions don't relate directly to the fix either. The best term I can
find for the things that are renegotiated between is "connection state".

> as it might be;

This is extremely common, I know it took me weeks to figure it out. Now
that I think I understand it, it's no longer obvious to me how why it's
so difficult.

Improvements in the TLS RFCs might help. Renegotiation is only discussed
minimally because it's simple to describe, whereas resumption takes more
words.

> I see session as defined by a common session

Looks good to me.

Just keep in mind the many-to-many relationship between sessions and
connections. A connection may handle multiple sessions (generally at
different times) and a session may be on multiple connections
(simultaneously or separated in time). An instance of a session on a
connection is referred to as a "connection state".

- Marsh

---

From: "tom.petch" <[email-masked]>
Date: Tue, 29 Dec 2009 17:10:43 +0100

----- Original Message -----
From: "Marsh Ray" <[email-masked]>
Sent: Thursday, December 24, 2009 9:00 PM

> identifiers do not play a part in this fix for renegotiation.

Marsh

This quote is from the base document for which this I-D is a corrigendum,
so unless the I-D amends it, the quote still applies.

This I-D should make clear the interaction of 'immediately previous handshake'
with respect to sessions and connections and at present, I don't think it does
so.
It is unfortunate that neither sessions nor connections nor renegotiation (nor
things:-) are clearly defined so I will see what emerges from the parallel
thread
on things and then most likely raise this again

Tom Petch.