Subject: [TLS] Doing without renegotiation

From: Nico Williams <[email-masked]>
Date: Wed, 16 Apr 2014 22:50:13 -0500

Real, supposed, and proposed uses of renegotiation:

 - rekeying
 - authenticate the client when needed rather than always at handshake time
 - privacy protection for the client's identity
 - privacy protection for the server's identity
 - privacy protection for the server identity desired by the client

Supposing we ditch renegotiation we'll need replacements for these.

My proposals:

 - For rekeying just introduce a CCS-like record whose purpose is to
   indicate that the sender is changing to new keys on the send side.
   The new keys are derived from the same master secret as the preceding
   keys, in the same way, but with a counter appended to the "key
   expansion" salt.

   There's no need to synchronize, but DTLS requires retransmission of
   such messages else when dropped the recipient will not be able to
   decrypt any subsequent messages.

   For DTLS we'll need an ACK message (huh?!  DTLS doesn't have such a
   thing?  nope.  Weid!)

 - For authentication other than that provided by the initial handshake
   I propose application-specific solutions.

   Note that for authentication with public keys there's no need for
   extra round trips.

   For SASL applications we should define one or two SASL mechanisms to
   replace TLS' PKI-based client and server authentication.

   For HTTP see below.

   There are two patterns here:

    - server wants client to authenticate

      In a protocol like HTTP that'd be a 401 indicating what methods
      the client can choose from...  Standard stuff.  We'd add a public
      key / PKI method whereby the client sends a signature of the TLS
      channel binding, along with any cert chain, OCSP responses, ...

    - client wants server to authenticate

      E.g., the initial handshake selected an anon ECDHE ciphersuite.

      In a protocol like HTTP the client might assert its desire for the
      server to authenticate using a new request header.  The
      authentication -again a signature of the TLS connection's channel
      binding- would return in a response header.

      This replaces the SNI protection use of renegotiation.

Nico
--

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 17 Apr 2014 07:43:34 +0200

>     decrypt any subsequent messages.

This might be an option if the purpose of the renegotiation is just to 
reduce the risk of state collisions in the bulk encryption cipher, but 
it is no replacement for renegotiation of DHE/ECDHE sessions in order to 
refresh the perfect forward secrecy.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Apr 2014 10:47:52 +0300

> - authenticate the client when needed rather than always at handshake time

<snip />

>   I propose application-specific solutions.

<snip />

>      channel binding, along with any cert chain, OCSP responses, …

Do you mean something like Martin’s proposal ([1][2]) or doing the whole thing in HTTP as a new HTTP authentication method?

Yoav

[1] http://tools.ietf.org/html/draft-thomson-httpbis-catch-00
[2] http://tools.ietf.org/html/draft-thomson-tls-care-00

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Apr 2014 11:03:24 -0500

On Thu, Apr 17, 2014 at 12:43 AM, Henrick Hellström
<[email-masked]> wrote:
> reduce the risk of state collisions in the bulk encryption cipher, but it is

Yes, much like SSHv2 recommends rekeying after 2^L/4 packets, where L
is the cipher's block length (sadly no reference is given for this).

> no replacement for renegotiation of DHE/ECDHE sessions in order to refresh
> the perfect forward secrecy.

This could be done with a single round trip, no need for a full
handshake.  The payloads containing the ephemeral keys for rekeying
could be sent opportunistically when the application writes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Apr 2014 11:15:52 -0500

> Do you mean something like Martin’s proposal ([1][2]) or doing the whole thing in HTTP as a new HTTP authentication method?

The latter.  When using PK/PKI or PSK there's no need for more than
one round trip, so for HTTP it's pretty simple as there'd be no impact
on statelessness.

For SASL applications we'd need new SASL mechanisms (although ISTR
that there is a SASL mechanism for using PK/PKI).

That covers a large number of Internet applications that use TLS!

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 17 Apr 2014 09:33:30 -0700

> is the cipher's block length (sadly no reference is given for this).

Real or random security. If we instantiate CBC mode with a PRF instead
of a PRP the security declines quadratically as we might call the PRF
on the same block with birthday bound issues. The PRP->PRF replacement
is another quadratic factor. So we get a probability of distinguishing
that is quartic in the number of blocks. I don't know if this is an
upper bound as well, or if other proof techniques can increase this
bound.

For CTR mode the only loss is quadratic from PRP->PRF.

> could be sent opportunistically when the application writes.

This actually doesn't work as well as you think it does.

Suppose Alice is sending a long message to Bob and needs to rekey in
the middle of the message. Alice sends her half of the ephemeral key
exchange. Before Bob can read the rest of the long message, he needs
to send data to Alice. It's cleaner than renegotiation, but still has
the C problem.

However, what it does isn't worth doing.
PFS means that revelation of the long term keys doesn't compromise a
connection made before the revelation. This holds true even if the
connection lasts beyond the compromise. If you leak the long term keys
and the connection keys, it's game over. If you leak only the
connection keys, then we need to reestablish a connection using the
long term keys, and can't use the compromised keys for authentication.

I do see the issue with letting keys stay in memory that can decrypt
lots of communications, but I think a cleaner method is to do the
proposed rekeying in such a way that the state transformation is
irreversible.

Sincerely,
Watson Ladd

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 09:56:21 -0700

>    For DTLS we'll need an ACK message (huh?!  DTLS doesn't have such a

DTLS can probably just rely on retransmission and evidence that the
new keying material is in use.  A sequence number reset should
alleviate most of the need for trial decryption.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 09:56:56 -0700

> the perfect forward secrecy.

I think that a new connection is a better way to address that use case.