Re: Key update review request

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 ([e-mail]) 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