Subject: DRAFT minutes from the Tokyo interim

From: Mark Nottingham <[email-masked]>
Date: Mon, 4 Feb 2019 11:26:15 +1100

... are up at:
  https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md

They still need some cleanup, but as always suggestions / corrections welcome (ideally as a pull request, but e-mail also acceptable).

Special thanks again to our scribes: Ted, Alex, Eric and Sean.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 5 Feb 2019 01:50:39 +0900

At Tokyo Interim, we concluded that reciprocal CID change was unnecessary [1].

However, during the discussion, I think we might have missed one
important use-case of the feature; that is, enforce the peer to retire
CIDs that were generated by an older generation of CID encryption key.

We expect servers to rotate the CID encryption key periodically, or
when the number space of CID gets exhausted. For a server to be able
to rotate, it needs to be capable of either closing all the
connections that use CIDs generated using an older generation of CID
encryption key, or to ask the peer to start using a different CID that
is generated using a newer generation of CID encryption key.

By removing the feature that allows the server to request the peer to
update the CID, the only capable way of a server retiring an CID
encryption key would be to close the connections that either uses or
might use CIDs generated by the older key.

We might be fine with that, considering the fact that our target
application is HTTP which has GOAWAY, a feature that can be used to
gracefully shutdown a connection.

However, I think we might consider otherwise, hence asking if we are
fine with the decision we made in Tokyo.

[1] https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minutes.md#dont-change-cid-on-peer-cid-change

2019年2月4日(月) 9:26 Mark Nottingham <[email-masked]>:
> .... are up at:

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Mon, 4 Feb 2019 22:51:38 +0000

Bearing in mind that:

  *   this rotation will hopefully be infrequent
  *   one or more CID bits can be reserved to indicate the key generation used
  *   connections only need to be killed when they use something from the oldest generation which is now being replaced

Servers can manage this by keeping two keys (one bit), or four (two bits).  That should make it relatively infrequent that a connection is still holding on to a CID from the oldest generation after they’ve all been replaced.

Worst case, this might be a use case for the PLEASE_RETIRE_CID extension we also talked about.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Kazuho Oku
Sent: Monday, February 4, 2019 8:51 AM
Cc: IETF QUIC WG <[email-masked]>
Subject: "Don't change CID on peer CID change" Re: DRAFT minutes from the Tokyo interim

However, during the discussion, I think we might have missed one important use-case of the feature; that is, enforce the peer to retire CIDs that were generated by an older generation of CID encryption key.

We expect servers to rotate the CID encryption key periodically, or when the number space of CID gets exhausted. For a server to be able to rotate, it needs to be capable of either closing all the connections that use CIDs generated using an older generation of CID encryption key, or to ask the peer to start using a different CID that is generated using a newer generation of CID encryption key.

By removing the feature that allows the server to request the peer to update the CID, the only capable way of a server retiring an CID encryption key would be to close the connections that either uses or might use CIDs generated by the older key.

We might be fine with that, considering the fact that our target application is HTTP which has GOAWAY, a feature that can be used to gracefully shutdown a connection.

However, I think we might consider otherwise, hence asking if we are fine with the decision we made in Tokyo.

2019年2月4日(月) 9:26 Mark Nottingham <[email-masked]<mailto:[email-masked]>>:

> https://github.com/quicwg/wg-materials/blob/master/interim-19-01/minut

> es.md

--

Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 11:18:06 +1100

On Tue, Feb 5, 2019, at 09:51, Mike Bishop wrote:
>   *   connections only need to be killed when they use something from 
> the oldest generation which is now being replaced
> 
> Servers can manage this by keeping two keys (one bit), or four (two 
> bits).  That should make it relatively infrequent that a connection is 
> still holding on to a CID from the oldest generation after they’ve all 
> been replaced.
> 

Mike's analysis is correct.  I would prefer not to do anything about this case.

For now, that means that if servers rotate keys, that will set an upper bound on the lifetime of a connection.  I think that's tolerable.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 5 Feb 2019 10:30:08 +0900

Mike, Martin,

Thank you for the responses.

Because CID encryption key is a master key, I think it's beneficial to
rotate it rather frequently. The precedent that the servers have is
the TLS session ticket encryption key (STEK). My understanding is that
people generally try to generate a new STEK every day or so [1].
Considering the fact that the maximum permitted lifetime of a TLS
session ticket is 7 days, generating a new STEK once a day is fine,
because by retaining 8 keys it would be possible decrypt TLS session
ticket that was issued 7 days earlier.

My preference would be to reuse the synchronization mechanism of STEKs
for sharing the CID encryption key among the server cluster. That
would mean that typically you would not be able to sustain a QUIC
connection for mere than a week.

That would be fine for HTTP/3, but maybe not for things like remote
shell over QUIC.

Having that said, I do agree that we can introduce a QUIC extension if
the concern becomes real. Considering that, I think I share the view
that we do not need to fix the issue now.

[1] https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html

-- 
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Feb 2019 16:52:11 +0530

I'm in agreement.

FWIW, I don't think that a remote shell session should need to keep the
transport connection around for as long as the session is around, but
that's not a discussion we need to have yet.

On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <[email-masked]> wrote:

> [1]
> https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html
>
> > > Worst case, this might be a use case for the PLEASE_RETIRE_CID
> extension
> > > we also talked about.
> >
> > For now, that means that if servers rotate keys, that will set an upper
> bound on the lifetime of a connection.  I think that's tolerable.
> >
>
>
> --
> Kazuho Oku
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 5 Feb 2019 04:29:02 -0800

Well, I do. If you tunnel data, you cannot just switch to a new connection
without a lot of disruption. Why create this problem in the first place?
We (eventually) got varint stream ID’s that made it feasible to have long
lived connections. I’d be sad to see that go down on connection ID
rotations. Especially if these are only done for the single reason of
avoiding linkability. My only (other) concern is loss of packet number
space, but I hope that changes with multi-path v2, and 62 bit is still
something.

I do agree that opt-in security does not work, but for a lot of cases it
really isn’t the key concern. And for other cases, linkability is so easy
to achieve anyway via  other techniques, that I don’t think it can compare
to the problem of TLS tokens. If the concern is cracking SHA256 via master
key, well, I think there are bigger issues to consider, including why a
master key is not rotated.

Another concern though, is the ability to track users via tokens, but that
is a cross connection concern, since clearly and endpoint can track the
peer for as the connection is open and the longer it is open, the easier it
is to track for external observers. An endpoint can and should close a
connection if long-lived tracking is a concern. It just should be imposed
on innocent shell pipes.

Mikkel

On 5 February 2019 at 12.22.38, Jana Iyengar ([email-masked]) wrote:

I'm in agreement.

On Tue, Feb 5, 2019 at 7:00 AM Kazuho Oku <[email-masked]> wrote:

> bound on the lifetime of a connection.  I think that's tolerable..
> >
>
>
> --
> Kazuho Oku
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Feb 2019 19:12:30 +0530

We're going to be well out of scope here quickly, so I'm not going to
design for a hypothetical use case that we don't yet understand well. I
definitely don't want to make a design decision now based on such a use
case.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 5 Feb 2019 05:51:20 -0800

It’s not really hypothetical. For long lived peer to peer server
connections, every time a connection goes down you can have a database
query transaction rollback, which could have been running for hours on end,
or loose a multiple gigabytes of data transfer if you use a simpler
approach of error handling.

On 5 February 2019 at 14.42.42, Jana Iyengar ([email-masked]) wrote:

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 5 Feb 2019 05:57:38 -0800

Put in another way.

If connections starts dropping randomly just because of a perceived
linkability issue, it would take me not very long to go non-standard and
create my own QUIC version. While I could do connection failover without
loosing a session, it is a lot simpler to fix QUIC in this regard.

On 5 February 2019 at 14.51.20, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Feb 2019 09:45:57 +1100

We're talking about an endpoint that refuses to use new connection IDs for an extended period.  The solution is to occasionally (say once per day) shift to a new connection ID.  That gives you infinite connection lifetime, assuming that you also keep up with key updates.

But Jana's original point was a stronger one: don't stack so much state on something as fragile and ephemeral as a network connection.  That's something I agree with, though I acknowledge that some applications don't work that way (yet).

---

From: Ian Swett <[email-masked]>
Date: Wed, 6 Feb 2019 04:28:26 -0500

I'm happy to do nothing here, for the reasons Mike and others cited above.

On Tue, Feb 5, 2019 at 5:46 PM Martin Thomson <[email-masked]> wrote:

> We're talking about an endpoint that refuses to use new connection IDs for
> an extended period.  The solution is to occasionally (say once per day)
> shift to a new connection ID.  That gives you infinite connection lifetime,
> assuming that you also keep up with key updates.
>
> But Jana's original point was a stronger one: don't stack so much state on
> something as fragile and ephemeral as a network connection.  That's
> something I agree with, though I acknowledge that some applications don't
> work that way (yet).
>