Subject: [TLS] Followup on Update

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Feb 2015 16:44:22 -0800

Folks,

I'd like to get a sense of the WG on whether they want to pursue the Update
mechanism [0].

There are several possibilities here, including:

- Just do basic Update
- Move session ticket establishment to Update
- Mode client authentication to Update

My sense from the discussion in HNL was that people were generally
positive on basic Update and unsure on the other two. If that's right,
I'll buff up PR#94 for merge into the spec (pending chair approval).

Thanks,
-Ekr

[0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP
version of the basic mechanism.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 24 Feb 2015 20:43:49 -0500

> version of the basic mechanism.

The current proposal says:

"An implementation MAY send an UpdateRekey at any time after
the handshake completes."

Is there a particular reason to not just have an automatic rekey at semi-regular intervals? So, every N records or M minutes (or whichever comes first) an endpoint must send a rekey, and then after a similarly measured interval the other endpoint sends a rekey; repeat ad infinitum. This would also ensure entropy for rekeying comes from both endpoints equally over the course of the connection. I would expect it would be better to not rely on implementations all designing their own heuristics on when to send rekey updates, and also would avoid multiple updates being sent at the same time by each endpoint (and the possible pitfalls of doing so).

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Feb 2015 18:00:46 -0800

On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <[email-masked]>
wrote:

> Is there a particular reason to not just have an automatic rekey at
> semi-regular intervals? So, every N records or M minutes (or whichever
> comes first) an endpoint must send a rekey, and then after a similarly
> measured interval the other endpoint sends a rekey; repeat ad infinitum.

It's not entirely clear that we know how to design a good heuristic here,
especially one that covers the entire range of possible algorithms.

As a minor nit, it's kind of a pain to say every M minutes because
often TLS stacks are driven by the application and don't have internal
timers, but you could of course say "first record after M minutes"
which would (probably) be close enough.

> This would also ensure entropy for rekeying comes from both endpoints
> equally over the course of the connection.

Can you explain more about why that's an important consideration?

> I would expect it would be better to not rely on implementations all
> designing their own heuristics on when to send rekey updates, and also
> would avoid multiple updates being sent at the same time by each endpoint
> (and the possible pitfalls of doing so)

The algorithm in this document is intended to be safe in the case of both
simultaneous
and (I believe) pipelined updates. I'd be interested in knowing if it's not.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Feb 2015 16:45:05 +1300

> which would (probably) be close enough.

In addition to this, it seems like more of a policy decision that is
driven more by circumstance than any direct security requirement.

We might recommend that rekeying occur for long sessions, but it's
hard to pick a one-size-fits-all value to recommend.  As low as 10
minutes might be appropriate for high-value, high-volume data; whereas
an IoT device with low-value, low-volume data might be content with
rekeying only for the purposes of session extension (i.e., on a scale
of days or weeks).

As proposed, there is no significant security benefit to the Update
protocol other than to stave off key exhaustion.  I think that's a
fine thing on its own merits, but I don't think we need to place too
much weight on the mechanism.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 25 Feb 2015 00:09:08 -0500

> especially one that covers the entire range of possible algorithms.

That's sort of my point; this proposal requires implementations to do so.
I'm saying that picking one in the spec would be preferable to leaving it
up to the whims of whatever the many combinations of implementations
end up deciding. Even if some use-case needs to add rekeys, starting
from a conservative heuristic in the spec would ensure implementations
are provided with at least a general expectation of how to use this.

> which would (probably) be close enough.

I'm not suggesting a precise heuristic here; just some semi-regular interval
that would be more specific than "MAY ... at any time". With it left as vague
as proposed, you could get deployments that never rekey or ones that
decide to rekey stupidly frequently. (DoS risk if not implemented
efficiently?) Picking any arbitrary interval would make things simpler and
ensure that this feature is used sufficiently.

The simplest route is to just specify a number of records to rekey after.

> Can you explain more about why that's an important consideration?

It's just something that occurs to me with the current proposal. It allows
for one sided rekeys, whereas the handshake gets randomness in each
hello from each endpoint. It just strikes me as notably different to rely on
just the one source of entropy here (plus previous).

It's a "huh, interesting" thought not a "oh, that's horrible" thought.

> and (I believe) pipelined updates. I'd be interested in knowing if it's not.

Yes, I don't think it's a spec risk. An implementation risk is possible, though.

It's a new feature that could end up with a new setting for an admin to
fiddle with that probably doesn't need to be highly variable to do the job.
Or put another way, it's a feature that I'm overthinking about the possibility
of implementations overthinking how to use it. ;)

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Feb 2015 10:18:02 +0200

> There are several possibilities here, including:

This seems pretty okay to me.

If there is some cryptographic concerns (that I can't see, and would
really appeciate if those were pointed out[1]) of server sending data
with pending certificate request[2], could those be addressed by
having the client Update the connection after sending certificate
and its verification?

Regarding misuse potential of that, the client is unidentified at
the point, so it seems pretty hard to misuse.

Now, with some non-DHE key exchanges (mainly PAKE) you might have
identified but unauthenticated client. I think it is reasonable
for the TLS library to return error for attempts to obtain the
client identification before it is authenticated. The present
rule does not help here, since the authentication does not involve
a client certificate.

> - Move session ticket establishment to Update

How does client know when it can resume a session? It takes 1RTT
to get connection to state where it can transmit data, but 2RTT
to state where it can resume (since server needs to have received
client's second flight, or resume is not going to work right).

> - Mode client authentication to Update

This scares me. Not the crypto parts, but the misuse potential. Even
doing it once seems as bad to me as doing it N times.

If the protocol is something like imaps, submission(stmp) or ircs,
then sure it looks safe.

But try to use it e.g. with active HTTP/2 connection, and thing just
go badly wrong. This is because adding/dropping certificates with
multiplexed protocol needs substantial coordination at application
layer to do safely.

[1] And if there are such, I think SSH should carefully be analyzed,
because it does pretty much exactly this.

[2] Would be useful for e.g. protocol feature negotiation, since
ALPN does not scale. E.g. consider wanting to use HTTP/2 with
tokbind (ChannelID) + Websockets.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 25 Feb 2015 20:47:50 -0800

> I'll buff up PR#94 for merge into the spec (pending chair approval).

Between update and the changes to the state machine in the Server and
Client Hellos, the complexity of a combined TLS 1.2 and TLS 1.3
implementation will be considerable. I appreciate the issues with
removing renegotiation wholesale, but this seems to introduce a lot of
complexity for the usecases of long-lasting connections and TLS layer
client authentication, and I don't think we've solved all the issues
with the latter.

That said, basic auth doesn't seem too bad, and I think my client
authentication question has a lot more to do with semantics and how
those are exposed then with the mechanism in the PR.

Sincerely,
Watson Ladd

> _______________________________________________
> 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: Joseph Salowey <[email-masked]>
Date: Thu, 26 Feb 2015 08:53:53 -0800

> I'll buff up PR#94 for merge into the spec (pending chair approval).
[Joe] I think client authentication should be handled separately.  Unless
update invalidates a session ticket (which I do not think it should), I
think it would be better not to tie update and rekey to keep things simple.

It may make sense to tie a client auth and session ticket refresh together.