Subject: [TLS] CCS and key reset and renegotiation

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Jun 2014 11:09:30 -0400

Have folks seen this yet?
  http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html

I think it adds weight to my concern about using ChangeCipherSpec to do key reset.  I still prefer the trade-offs of having a "slow the TLS but keep the TCP layer open" and starting over.  Much simpler to prove it's correct.

                /r$

--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]<mailto:[email-masked]>; Twitter: RichSalz

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 15:21:37 +0000

On Thu, Jun 05, 2014 at 11:09:30AM -0400, Salz, Rich wrote:

> I think it adds weight to my concern about using ChangeCipherSpec
> to do key reset.  I still prefer the trade-offs of having a "slow
> the TLS but keep the TCP layer open" and starting over.  Much
> simpler to prove it's correct.

A STOPTLS feature could also be useful in the Postfix (TCP) connection
cache.  Because cached TCP connections move between processes
through file descriptor passing, but serializing the SSL state of
an active SSL connection is difficult, we currently can't cache
TLS-protected TCP connections.  If we could STOP TLS before moving
connections into the cache, and resume with a handshake over
cleartext (using a cached TLS session, session ticket, ...) that
would make it possible to cache TLS connections (that negotiate
TLS 1.3 if STOPTLS is a required or negotiated peer feature in
1.3).

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Jun 2014 08:25:26 -0700

>
>
>
> I think it adds weight to my concern about using ChangeCipherSpec to do
key reset.  I still prefer the trade-offs of having a “slow the TLS but
keep the TCP layer open” and starting over.  Much simpler to prove it’s
correct.

What can change when that happens? Furthermore, rekeying is a matter of
getting more PRF output: how does that introduce security concerns.

I don't see why the incompetence of implementors should govern our
decisions. If something cannot be implemented correctly it must be
removed,  but why is rekeying such a thing?
> IM: [email-masked]; Twitter: RichSalz
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Jun 2014 10:40:29 -0500

On Thu, Jun 5, 2014 at 10:09 AM, Salz, Rich <[email-masked]> wrote:
> I think it adds weight to my concern about using ChangeCipherSpec to do key
> reset.  I still prefer the trade-offs of having a “slow the TLS but keep the
> TCP layer open” and starting over.  Much simpler to prove it’s correct.

The good news is these bugs are getting found, and that this and
Heartbleed aren't protocol bugs -- sure, the protocol made it easier
for programmers without automatic bounds checking and so on to screw
up, but, the problem is the lack of bounds checking and so on.  And,
frankly, this bug is just the result of failure to keep one bit of
state: if there's no key, then CCS should cause a protocol failure --
the sort of bug that the protocol can't be blamed for, like the goto
fail bug.  I know the discoverer thinks that the description of CCS is
to blame, but I don't.  I think it's just this one bit of state, not
kept or not checked where it matters.

The bad news is that there's no plan to replace OpenSSL with something
better; there is nothing better with sufficiently friendly licensing
terms.  What other serious bugs lurk unknown to the public?  There's
no light yet at the end of this tunnel.

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Jun 2014 11:41:28 -0400

> I don't see why the incompetence of implementors should govern our decisions. If something cannot be implemented correctly it must be removed,  but why is rekeying such a thing?

Because the line between “often get it wrong” and “cannot be implemented” is often a very thin one and it’s better to be cautious and safe, then pedantically correct and usually broken.

/r$

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jun 2014 08:53:52 -0700

On 5 June 2014 08:41, Salz, Rich <[email-masked]> wrote:
>> decisions. If something cannot be implemented correctly it must be removed,
>> but why is rekeying such a thing?
>
> Because the line between “often get it wrong” and “cannot be implemented” is
> often a very thin one and it’s better to be cautious and safe, then
> pedantically correct and usually broken.

I tend to agree with Watson here.  This is a problem that happens
during the initial handshake only.  Maybe we can design the handshake
to ensure that CCS cannot be abused for TLS 1.3.  But I don't see how
this vulnerability extends to subsequent handshakes or rekeying
exchanges.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Jun 2014 09:01:41 -0700

> >> decisions. If something cannot be implemented correctly it must be
removed,
> this vulnerability extends to subsequent handshakes or rekeying

We did design that part of the handshake correctly provided you read the
example handshake as dictating the possible flows: that's why only OpenSSL
is vulnerable.

The spec needs a state machine.

---

From: Nico Williams <[email-masked]>
Date: Thu, 5 Jun 2014 11:27:18 -0500

> this vulnerability extends to subsequent handshakes or rekeying

A single bit of state was not kept or checked.  How do we prevent that
sort of implementation bug with protocol design?  How could we prevent
the goto fail bug with protocol design?  (Well, DANE helps, to be
sure, by cutting out the PKIX.  But really, even then there will be
plenty of opportunities to commit bugs of these types.)

At some point using silly implementation bugs as a justification for
protocol design decisions... will probably lead to bad protocol design
decisions.

There are cases where I think that protocol design decisions do impact
implementation quality.  For example, using ASN.1 w/ BER/DER/CER in
new protocols is asking for trouble because a) cheap tooling is still
not widely available, b) BER is very redundant, and redundancy doesn't
help programmers get it right.  ASN.1 w/ PER, or XDR -- these are
superior to BER.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 16:42:42 +0000

On Thu, Jun 05, 2014 at 08:25:26AM -0700, Watson Ladd wrote:

> > key reset.  I still prefer the trade-offs of having a ?slow the TLS but
> > keep the TCP layer open? and starting over.  Much simpler to prove it?s
> > correct.
> 

Whether or not rekeying is easier to implement with a STOPTLS, or
by switching directly from one keyset to another, without an
intermediate transition to cleartext, a STOPTLS feature has additional
upside.  I don't recall whether this idea got dropped, or whether
STOPTLS might yet happen in TLS 1.3.  Anyone care to bring me up
to speed?

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jun 2014 20:23:46 +0300

> STOPTLS might yet happen in TLS 1.3.  Anyone care to bring me up

Sure. 

StopTLS is just an idea I threw around ([1]) in response to some other idea that someone said in the room (no idea who and don’t remember what) in pretty much the last minute of the Interim meeting. I think it was a response to some other suggestions to get rid of renegotiation for rekeying, such as requiring everyone to start a new connection (StopTLS saves a round-trip), or various kinds of abbreviated handshake (StopTLS is simpler). 

StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex prefix injection attack.

It’s not currently a part of any plan for any version of TLS.

Yoav

[1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html  at time 19:40:04

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jun 2014 17:43:12 +0000

On Thu, Jun 05, 2014 at 08:23:46PM +0300, Yoav Nir wrote:

> > I don't recall whether this idea got dropped, or whether

Thanks.

> StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex

Would it suffice to ban application-data messages after STOPTLS
before a new handshake completes, and to require a subsequent
handshake to be a resumption of the previous session (or a new
session handshake in cleartext, but channel-bound to the previous
session).

The purpose of STOPTLS would not be a downgrade to cleartext data
tranfer, but rather a transition from one key-set to another via
a cleartext handshake that can happen with minimal crypto-state
transfer (saved session object or some opaque shared secret
sufficient).

> It's not currently a part of any plan for any version of TLS.

If it does come back, I can put it to good use.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jun 2014 21:59:12 +0300

> session handshake in cleartext, but channel-bound to the previous

The Ray/Dispensa/Rex attack would be a MitM starting a TLS connection, sending to the server “GET /form.html?Button=Shutdown HTTP/1.0\nx-fake-header: “ and then sending a StopTLS and forwarding the client’s real ClientHello. The server would see this:

GET /form.html?Button=Shutdown HTTP/1.0
x-fake-header: GET /form.html?Button=Status HTTP/1.1
Cookie: authorization=wxvr7Z7hL8GXSQLqaIU6Cg==

And the client’s cookie would authorize the attacker’s request and the device would shut down. Yes, this was a real application, and yes, the attack worked.

As you say, binding the new handshake to the old handshake should suffice, whether it’s done through the channel binding or through the resumption cache. On a more philosophical level we might want to consider whether providing the application with a single, steady stream regardless of rekeying/renegotiation/new state is the right thing. In other words, it’s not clear to me that these events should not be reflected to the application so that application context does not flow from one TLS context to another.

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 5 Jun 2014 17:51:57 -0400

On Thu, Jun 5, 2014 at 11:25 AM, Watson Ladd <[email-masked]> wrote:
>> key reset.  I still prefer the trade-offs of having a “slow the TLS but keep
>> the TCP layer open” and starting over.  Much simpler to prove it’s correct.
>

I'm reading two points in that last statement: first, some
implementers are incompetent; and second, the TLS WG does not make bad
decisions.

For the first point, I think its too easy to blame an implementer.
Perhaps there's a gap that needs to be addressed for implementers. Has
the TLS WG considered providing a comprehensive test framework to
ensure their designs are realized in an implementation?

The working group is in a unique position to offer the best and most
complete set of tests. They are in that position because they
understand what they want, they know why they want it, and they know
what they rejected. So a testing framework with positive and negative
self tests would probably be very helpful to implementers. And that's
all implementers, and not just the ones that are labeled incompetent.

Plus, the implementers should *NOT* be asked to create their own test
cases. That's simply bad engineering, and the problem has been known
for years. Gutmann and Anderson talk about in their respective books
on security and engineering. Those books are 10 or 15 years old, so
its not bleeding edge knowledge.

For the second point, Authenticate-then-Encrypt has proven to be
problematic for years. I would not blame the implementers or call them
incompetent for subtle problems in the construction. Especially when
it took a formal analysis by practicing cryptographers to uncover and
present the problems [0].

The problems with Authenticate-then-Encrypt have been known since at
least 2000 [0]. I question why the folks responsible for the standard
did not acknowledge the problem and provide safer or better
alternatives more expediaently. Nearly ten [1] or fifteen years [2] to
address the [re-occuring] problem seems a bit excessive to me.

The folks responsible for the standard are collectively smarter people
than the folks implementing the standard and using the standard. We
(the dumb users) need the group to act expediently when gaps are
uncovered.

For completeness, CompSci 101 mistakes are an implementers problem.

-----

[0] H. Krawczyk. The Order of Encryption and Authentication for
Protecting Communications,
http://www.iacr.org/archive/crypto2001/21390309.pdf
[1] J. Salowey, et al. AES Galois Counter Mode (GCM) Cipher Suites for
TLS, http://tools.ietf.org/html/rfc5288
[2] P. Gutmann. Encrypt-then-MAC for TLS,
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00