Subject: Key update review request

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Sep 2019 16:31:33 +1000

Hi All,

https://github.com/quicwg/base-drafts/pull/3050 rewrites most of the key update section of the TLS draft.  

Preview: https://quicwg.org/base-drafts/rework-key-update-2/draft-ietf-quic-tls.html#key-update

There is one technical change in here to address the issue (#2792) raised by Marten Seemann where our packet processing is not constant time.  The problem is that generating new keys was part of the logic for packet protection removal, and key generation would be very visible as a timing side channel.  This isn't that serious a problem in my opinion, because you could model key generation as application-layer activity, which we don't attempt to protect in this way.  However, it does leak a bit of data that we were hoping to protect (the Key Phase), so I figure that it's worth at least documenting the exposure.

The proposed change doesn't prohibit inline key generation, but it encourages an asynchronous method of key generation that should be harder to observe the effects of.  Specifically, implementations are told that they ought to [RFC6919] generate new keys 1PTO after performing a key update.

To go along with the recommendation to use a timer, it more strongly discourages key updates within 3PTO of each other.  The substance of the warning is that if you update too fast, you could experience "loss".

I'd like some more review of this PR.  Basically, I don't want to get to the interim to find that people "need more time to review this".  I've already gotten good feedback (thanks Kazuho, David), and I think that it's good to merge, but I want more eyeballs.

Cheers,
Martin

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 26 Sep 2019 23:53:24 -0700

As a general comment to the principle of hiding key updates:

I believe this is very useful because if a weakness is found in crypto, the
more data you can sample the more plausible the attack. If observed data
can be from multiple keys such attacks presumably become harder. We already
know there is an easily reachable data limit on AES-GCM beyond which
certain attacks become feasible.

On 27 September 2019 at 08.32.09, Martin Thomson ([email-masked]) wrote:

Hi All,

https://github.com/quicwg/base-drafts/pull/3050 rewrites most of the key
update section of the TLS draft.

Preview:
https://quicwg.org/base-drafts/rework-key-update-2/draft-ietf-quic-tls.html#key-update

There is one technical change in here to address the issue (#2792) raised
by Marten Seemann where our packet processing is not constant time. The
problem is that generating new keys was part of the logic for packet
protection removal, and key generation would be very visible as a timing
side channel. This isn't that serious a problem in my opinion, because you
could model key generation as application-layer activity, which we don't
attempt to protect in this way. However, it does leak a bit of data that we
were hoping to protect (the Key Phase), so I figure that it's worth at
least documenting the exposure.

The proposed change doesn't prohibit inline key generation, but it
encourages an asynchronous method of key generation that should be harder
to observe the effects of. Specifically, implementations are told that they
ought to [RFC6919] generate new keys 1PTO after performing a key update.

To go along with the recommendation to use a timer, it more strongly
discourages key updates within 3PTO of each other. The substance of the
warning is that if you update too fast, you could experience "loss".

I'd like some more review of this PR. Basically, I don't want to get to the
interim to find that people "need more time to review this". I've already
gotten good feedback (thanks Kazuho, David), and I think that it's good to
merge, but I want more eyeballs.

Cheers,
Martin

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Sep 2019 17:56:08 +1000

On Fri, Sep 27, 2019, at 16:53, Mikkel Fahnøe Jørgensen wrote:
> I believe this is very useful because if a weakness is found in crypto, 
> the more data you can sample the more plausible the attack. If observed 
> data can be from multiple keys such attacks presumably become harder. 

This is a discrete key, and the leak is limited to one set of leaks for each key update (as you are required to keep the new keys if you perform the calculation), such that the attacker can observe a key update (P=0.5, no further observations) or a non-key update (P=0.5, more observations permitted).  Note also that the timing side channel could be noisy; this assumes perfect observation of the side channel, which is difficult to do in practice even if it is a strong signal.

That's not a lot of leverage, but it is some.  And as you say, on principle, we should not be leaking this information, but I would rather have this leak than have people choose not to implement key updates.  If we don't get key updates, we are likely much worse off (for the reasons you note).