Subject: [TLS] Next steps for draft-ietf-tls-renegotiation

From: <[email-masked]>
Date: Fri, 27 Nov 2009 23:26:34 +0100

<wearing Area Director hat>

I have asked the secretariat to start IETF Last Call for
draft-rescorla-tls-renegotiation-01.

I've gone through the list archives for the past month, and it seems a
large majority of the WG members support the overall approach in this
draft (with a small, but very vocal, minority preferring a totally
extension-less approach to signalling).

I think the users of TLS at this point are served better by a timely
solution that works and is "good enough", rather than continuing the
tweaking. Especially since a large majority of the WG is OK with the
signalling approach in the current draft, it looks like continuing to
tweak the non-signalling parts is not going to provide any significant
additional benefits to the users of TLS.

The exact text in the -01 draft is still a bit rough (a number of
places could probably benefit from clarifications, and perhaps some
implementation advice, too), and I hope we can continue improving it
during the last call (for example, Martin's draft has lot of
well-written text we should probably consider including here). 

Best regards,
Pasi
IETF Security Area Director

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 28 Nov 2009 00:46:57 +0100

> draft-rescorla-tls-renegotiation-01.

No, you haven't -- or so I hope: You must have asked about draft-ietf- 
tls-renegotiation-01.

Bodo

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 28 Nov 2009 01:06:33 +0100

Pasi,

For the record I just need to say that I strongly disagree with this
decision.

We have two solutions on the table and the essence of them has been
concluded during the very last few days. I would say that the support for
either of the two approaches has been quite even lately. It surprises me
that we don't even have time to seriously ask the WG members what approach
they prefer.

I can just hope this in the end will turn out to be of service to the
community and that all implementers get this right. I would really hate for
us to conclude that we patched one vulnerable security design with another
due to implementer shortcomings, or that a large part of the community
turned off a useful TLS feature.

It was interesting to have the discussion.

/Stefan

On 09-11-27 11:26 PM, "[email-masked]" <[email-masked]> wrote:

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

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 28 Nov 2009 01:45:11 +0000

> draft-rescorla-tls-renegotiation-01.

I believe that's premature. We are getting very close to a practical
approach that has both security and interoperability advantages over
draft-rescorla-tls-renegotiation-01. Starting Last Call now does not,
IMHO, represent the concensus of the list.

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

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 14:53:58 +0100

Pasi,

> extension-less approach to signalling).

I made a count through all people that has raised their voice on this list
and included all e-mail that was sent the past week. I don't think it is
fair to include any statements older than that.

This is my count:

Support an alternative solution: 6 people
Open for an alternative solution: 3 people
Neutral: 4 People
Support the current tls draft: 7 people
Conditional support for the current draft: 2 people

Looks fairly even to me.

/Stefan

---

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

> Conditional support for the current draft: 2 people

Please put me down in support of draft-ietf-tls-renegotiation-01

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 30 Nov 2009 08:58:18 -0800

One thing that you may have missed is that on a renegotiation
handshake, the client and server need to pack the extension with
the old verify data and extract what they received from their
peer.  This is unchanged from the original draft-rescorla-...

That is a heavyweight use of extensions for any code that currently
does not use them.  I do not support forcing this complex change on
a body of maintenance programmers who don't know much about TLS.

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Nov 2009 11:07:45 -0600

> extension-less approach to signalling).

I don't think that's a fair nor complete characterization of the current
differences of opinion.  A more complete and correct characterization
might be:

 - The RI proposal has a fail-unsafe requirement that peers check the
   contents of the extensions sent.

   NOTE: A fix for this wouldn't require an extension-less signalling
         solution.

   [IMO: This is serious objection that goes beyond protocol design
         aesthetics or ease of retrofitting for SSLv3.  I think we can
	 live without a fix for this problem, but I'd much rather have a
	 fail-safe solution.]

 - There seems to be a desire, among some, for a signalling solution
   that is somehow easier to retrofit for SSLv3 implementations.  This
   couldn't be an extension-less scheme, since some bits are needed to
   signal the use of the fix in the client's initial hello, but it might
   avoid the use of server hello extensions.

   [IMO: This is a concern that we can safely ignore.]

Nico
--

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 18:55:26 +0100

Nico,

I think your characterization is very good.
And I would also much rather have a fail-safe solution.

As you say, no approach today is totally extension less, so the big
difference remaining IMO is:

1) The fail-unsafe approach based on sending verify_data in extensions.

2) The Fail-safe approach based on injecting varify_data into the handshake
hash calculation, but not sending them over the wire. (This approach uses
extensions for signaling but with absent data)

Everything else is more or less the same.

I think we have demonstrated that the fail-safe alternative can be designed
in a secure manner.

/Stefan

---

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

> peer.  This is unchanged from the original draft-rescorla-...

Yeah, I realize that. My thinking has personally been back and forth
several times in the last few months. Now that I feel like I understand
the issues involved a bit better, I have weighed them and feel that
draft-ietf-renego-01 is the least disruptive and will be fastest to deploy.

Although we would have all done it differently knowing what we know now,
at this stage touching anything involving the hash calculations
themselves brings along all sorts of baggage. It might trigger a formal
cryptographic review in a lot of deployments. Comparing two hash values
for equality is as lightweight a bugfix change as anyone's going to get.

> a body of maintenance programmers who don't know much about TLS.

A) I mean, come on people, if you can't implement that loop in software
you're in the wrong business.

>       Thus, the entire encoding of the
>       extension is:  ff 01 00 01 00.  The first two octets represent the
>       extension type, the third and fourth octet the length of the
>       extension itself, and the final octet the zero length byte for the
>       "renegotiated_connection" field.

This should not require adding general support for extensions to a
public API.

B) Everyone knows that this is a critical infrastructure component and
companies will have skilled developers involved in all changes and lots
of testing and review. Don't knock "maintenance programmers", they know
better what can go wrong than the original implementors.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Nov 2009 19:47:39 +0100 (MET)

> 	 live without a fix for this problem, but I'd much rather have a

What makes me feel somewhat uncomfortable is the situation when the
client is doing an initial handshake and the server is doing a
renegotiation handshake:

The client will send an emtpy extension.  The server should abort.

But if the server is a little sloppy, and sends back an empty
extension in ServerHello (matching the empty extension received
in ClientHello), then the handshake will succeed.

In that case, the renegotiation vulnerability will be still present,
but this will not be obvious in the regular interop-testing and the
client has no way to detect that the server is goofing his job.

The problem is, that it is so extremely easy for the server to
goof his job.  If we add the verify_data to the renegotiation
and something small but different to the initial handshakes
between updated server and updated client, then it will be
extremely difficult to get it wrong and still interoperate
-- it will be _much_ easier to interoperate hand have it correct.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Nov 2009 12:30:50 -0600

> I think your characterization is very good.

Thanks.

> [...]

Agreed.

> I think we have demonstrated that the fail-safe alternative can be designed

Agreed.

The question is: how to reach consensus on whether to modify the RI
proposal to fail safe?

We're all very tired following a lengthy DDoS by the TLS WG[0]; we don't
need to have a repeat on the IETF list.  Sadly, I think we'll almost
certainly have a repeat.  Thus I'm voicing my opinion early and bailing
out immediately:

IMO fail-safe mechanisms are a good thing, but not something necessarily
a hard requirement.  I'd support a fail-safe modification to the RI
proposal[1], but given that implementors are ready to deploy the RI
proposal as-is, I also support the RI proposal as-is in the interest of
getting a fix done sooner rather than later.

[0]  Jeff Hodges' very funny coinage.

[1]  The simplest such change would be have the peers send zeros in the
     extensions but modify the hellos to insert the CB data prior to
     hashing the hellos as part of the verify_data computation.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Mon, 30 Nov 2009 13:02:40 -0600

Agreed.

We'd all have done it differently from the beginning, but we have to
ship a fix.

No compromise on actual protocol security of course, but no time to
delay for aesthetics either.

>      hashing the hellos as part of the verify_data computation.

Changing inputs to the hash function theoretically introduces new
possibilities for attack (verify_data which looks like a valid handshake
message prefix for example).

I fear that any change to the way the hashing inputs are done will
trigger a formal crypto review in some important deployments.

We had hoped the hello extension mechanism would have been already an
accepted way to extend the handshake such that it didn't violate any
assumptions on which previous cryptographic analysis of the protocol had
been built.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Nov 2009 13:12:55 -0600

> delay for aesthetics either.

To be clear: the fail-safe/unsafe issue is not a matter of aesthetics.

> message prefix for example).

I don't agree, but, more than anything I don't want to debate the merits
of alternative designs, mine or anyone else's -- that way another DDoS
lies.  I should not have included that footnote; I am sorry that I did.

IMO what we should do is first work on consensus as to whether to fix
the fail-unsafe issue in the RI proposal as that's the main issue right
now.

Nico
--

---

From: <[email-masked]>
Date: Mon, 30 Nov 2009 20:33:38 +0100

Yes, you're right; my mistake (fortunately the tool
for actually requesting last call makes such typos
much harder, and the actual IETF Last Call message
had the correct draft name).

Best regards,
Pasi

> -----Original Message-----
> From: ext Bodo Moeller [mailto:[email-masked]]
> Sent: 28 November, 2009 01:47
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 21:18:26 +0100

Nico,

> lies.  I should not have included that footnote; I am sorry that I did.

I don't want to start a new discussion about this either, but for the record
I agree with you. The attack described by David-Sarah (injecting messages to
make a the client primary handshake appear as renegotiation) does not work
on the approach you describe.

We can just conclude that there are many ways through which once could
design a fail-safe approach. The question is whether it is worth the effort.

I believe that it is worth it if we can agree on one shortly (during the
ietf last call). If we can't then we'd better get the fix out rather than
dragging this on forever.

/Stefan

---

From: Steve Dispensa <[email-masked]>
Date: Mon, 30 Nov 2009 14:30:03 -0600

> Please put me down in support of draft-ietf-tls-renegotiation-01

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

 -Steve

---

From: <[email-masked]>
Date: Mon, 30 Nov 2009 21:38:02 +0100

Stefan Santesson wrote:

> > I've gone through the list archives for the past month, and it
> > seems a large majority of the WG members support the overall
> > approach in this draft (with a small, but very vocal, minority
> > preferring a totally extension-less approach to signalling).
> 
> I made a count through all people that has raised their voice on
> this list and included all e-mail that was sent the past week. I
> don't think it is fair to include any statements older than that.
> 
> This is my count:
> 

I think this depends very much on what you mean by the "alternative
solution" -- it seems you're not referring to, for example,
draft-mrex-tls-secure-renegotiation-01.

In my quoted text above, the "large majority" referred mostly to
people who've said using TLS extensions (in one way or another) is OK,
and the "small minority" was objecting to proposals involving TLS
extensions in any way. (In this question, I do not think ignoring
opinions expressed more than 7 days ago is a reasonable way to judge
the situation.)

However, in your later email (on Monday) you seemed to say that we
have settled this issue already:

> 2) The Fail-safe approach based on injecting varify_data into the
> handshake hash calculation, but not sending them over the
> wire. (This approach uses extensions for signaling but with absent
> data)
>

This surprised me a bit (but possibly the surprise is a positive one).
I would be interested in hearing from folks who've earlier opposed the
use of extensions whether this reflects their current views, too.

If it does, I think we've made a lot of progress, and can still tweak
the final difference (whether to send verify_data over-the-wire or not) 
based on discussion during the IETF last call.

I do not claim that a large majority currently strongly prefers
sending the old verify_data over-the-wire in the extension data. Much
smaller number of people (compared to the signalling issue) have
expressed any opinions about this, and also, I would expect that a
smaller number of people care very strongly either way.

And BTW, in this question I agree that counting opinions expressed
much more than a week ago probably isn't that good. So if someone
(any reader of this message) cares very strongly either way, 
I would suggest saying so on the list (if you haven't done so
already recently).

Best regards, 
Pasi

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 21:46:24 +0100

Please.... I'm not keeping score :)

I did a one off count coming up with this estimate to get a feeling for
where we are. I do not intend to update this score and It was not an attempt
to do a rouge straw-poll.

It is up to the IESG and WG chairs to ask for and determine consensus.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 21:56:43 +0100

Pasi,

Thanks for a good and clarifying mail.

Yes, all proposals are currently using extensions for the server to client
signaling and all proposals are currently using the magic CipherSuite only
for client to server signaling on initial handshakes.

This will also be reflected in the new alternative draft to be posted,
hopefully within 24 hours from now.

In this sense the two approaches are a lot closer now.

The major difference now is that one proposal includes the data in the
extensions and is fail-unsafe, while the alternative feeds that data
directly into the handshake hash calculation and is fail-safe.

There are minor differences also in the signaling on renegotiations, but I
regard that as minor.

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Nov 2009 13:05:54 -0800

At Mon, 30 Nov 2009 11:07:45 -0600,
> 	 live without a fix for this problem, but I'd much rather have a

I don't really agree that this is a serious objection. As I said
earlier, the security of TLS requires that the peer behave correctly
in a variety of unobservable ways. If it doesn't, we have far
more serious security problems than this (in particular, in order
for the failure you're concerned about to occur, this failure
requires *both* sides to be incorrectly implemented, whereas there
are plenty of issues that can be created by merely one side being
incorrect).

Moreover, there *are* implementation errors where the various proposed
alternative signalling mechanisms can go wrong as well, as our discussion
over the past few days indicates. So I can't even agree with the
characterization of this issue as "fail-safe" versus "fail-unsafe".
Rather, each solution is subject to different kinds of implementation
screwups. I don't find the argument that the screwups you can
make with RI are somehow easier to be particularly convincing.

Moreover, if you're really concerned about TLS being safe in the face
of implementation errors, you should worry about designing mechanisms
that are safe in the face of PRNG failure, seeing as we've seen at
least two such errors in live TLS stacks.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Nov 2009 22:13:25 +0100

Pasi,

> use of extensions whether this reflects their current views, too.

Some sources of relevance concerning this issue:

http://www.ietf.org/mail-archive/web/tls/current/msg04742.html  ,and
http://www.ietf.org/mail-archive/web/tls/current/msg04789.html

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 01 Dec 2009 00:06:48 +0100

Eric,

> are plenty of issues that can be created by merely one side being

Yes, the current draft is doing a good job at keeping possible one sided
failures to the minimum.

I think the most severe one side failure would be if a client, signaling
initial handshake, would somehow trick the server to reply with an empty RI
extension, even though it is doing a renegotiation.

> over the past few days indicates.

I think those were all resolved though.

> So I can't even agree with the

I have re-evaluated my position. I still think the characterization is
correct, but agree that the risk for failing following the current draft is
not significant.

However, I remains my belief that the implicit approach has better security
properties by design.

> least two such errors in live TLS stacks.

The fact that there are many ways to do implementation errors, is not a
reason to not select the best possible design.

I find it much more convincing if the general opinion is that the "implicit"
design requires too intrusive changes to the core TLS design, alternatively
is to hard to implement.

But if it is easier to implement in legacy implementations (e.g. by not
requiring clients or servers to extract and insert data in TLS extensions),
then it might actually be worth it.

/Stefan

---

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

>    [IMO: This is a concern that we can safely ignore.]

I agree completely with both your characterization of the situation,
and statements of opinion.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Nov 2009 17:30:45 -0600

> and statements of opinion.

Thanks.  You and I do disagree, however, as to whether it was premature
to start an IETF LC.  I believe there's only one matter to resolve, and
that it is appropriate to resolve it during an IETF LC.

Note to fail-safe proponents: IMO the RI proposal is the default outcome
of this LC.  A single, unified proposal has to be put on the table if
we're to find consensus for fail-safe, and, too, I think support from
major implementors is needed.  If such a proposal and support fail to
materialize then I'd expect the conclusion to be that the RI proposal is
it.  I'm a proponent of fail-safe, but not neither a TLS implementor nor
sufficiently energetic to make it happen.  One (or more) of you will
have to organize an off-list agreement in order to make this happen.
Attempting to design and finalize an alternative on this LC is a bad
idea.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Dec 2009 01:21:55 +0100 (MET)

Eric Rescorla wrote:
> in particular, in order for the failure you're concerned about to occur,
> this failure requires *both* sides to be incorrectly implemented.

As I previously described, this assumption is incorrect.
It is sufficient when one side is incorrectly implemented.

Scenario:  MitM proxies the initial handshake of a client into
the renegotiation of a server.  Client will send empty TLS extension RI.
If the server implementor has implemented the signaling in the fashion
"receiving empty RI" -> "sending empty RI", then the handshake will
succeed.  Server goofed it, and the client has no chance to detect
it and no chance to prevent it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Dec 2009 03:05:28 +0100 (MET)

> trigger a formal crypto review in some important deployments.

That seems a little far fetched, given that MitM attackers have
no restrictions of any kind to feed whatever they like into the
handshake message hash.

Quoting from rfc5246 7.4.1.4 Hello Extensions:

      Often the fact that the extension fields are included in the
      inputs to the Finished message hashes will be sufficient, but
      extreme care is needed when the extension changes the meaning of
      messages sent in the handshake phase.  Designers and implementors
      should be aware of the fact that until the handshake has been
      authenticated, active attackers can modify messages and insert,
      remove, or replace extensions.

The problem that David-Sarah Hopwood noticed in my initial approach
was that my change only inserted data in the renegotiation, it did
_not_ insert different data on the initial handshake.  So there
was a theoretical attack that the attacker might be able to insert
what one side added into the message stream for the other--which
had not added for an initial handshake, provided there was an
accidental collision with a de-facto no-op handshake message.
The attack is fairly theoretical, because the verify_data
is not predictable (for TLS sessions where the attacker controls
only one side) and the protocol itself does not define any
no-op handshake messages (but implementations could have bugs
to this effect).

The obvious fix is to add reliably distinct data in both initial and
renegotiation handshake.  The handshake message protection comes
from the fact that an attacker may only insert data into the message
streams (and get them added to the handshake message hashes this way),
but not remove any of the data previously added by either side.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Nov 2009 19:11:43 -0800

At Tue, 1 Dec 2009 01:21:55 +0100 (MET),
> it and no chance to prevent it.

As far as I can tell, exactly the same thing can happen with an
implicit proposals, if, for instance, the server always inserts 
empty verify_data. Sure, that could be caught in testing, but
so could the error you propose with RI. 

As a distinguishing factor, this seems pretty marginal at best.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 30 Nov 2009 19:43:53 -0800

> that it is appropriate to resolve it during an IETF LC.

There is something that you may have overlooked.  With the RI proposal,
SSLv3 and TLS clients that don't currently support extensions will only
be able to make initial connections to servers using the special cipher
suite.  If they ever need to renegotiate, they need to add full support
for extensions since RI requires the verify_data be sent and received in
renegotiation handshakes.

You know my position is that this is entirely unnecessary baggage that
should not be forced on implementers that don't have extensions in
their code already.  Add to that the fail-safe/unsafe issue, and it
seems to be a no-brainer to choose the alternative (which Martin should
be releasing tomorrow).

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 1 Dec 2009 05:54:41 +0100 (MET)

> so could the error you propose with RI. 

There is a huge difference.  With the implementations where there
verify_data is added directly into the handshake messsage hash,
the error will be pretty obvious in each and every regular
interop test due to a complete lack of interoperability.

With TLS extension RI, you will notice the problem only
when you perform real penetration tests or source code review.

It would be a significant additional amount of work to implement
it incorrectly and still interoperate, so it's fairly unlikely
someone will do this rather than the much easier correct
and interoperable solution.

-Martin