Re: Key updates

[Martin Thomson <[e-mail]>]

On Mon, Aug 6, 2018 at 7:44 PM Mikkel Fahnøe Jørgensen
<[e-mail]> wrote:
>
>> This is definitely an option I have considered. If you have a workable design, I would be interested. I couldn't reconcile the desired rates of updates. Connection IDs are needed in spikes, where the rate for key updates is more measured.
>
> I believe the current consensus is to have an ordered set of connections ID’s. If that were not the case, or if there were two sets, then some connection ID’s could be associated with a key update. If running out of key update ID’s, a new such ID would be requested. This is somewhat similar to the commit based option.

The current direction seems to be toward a bag of connection IDs,
without ordering.  I considered attaching an epoch to
NEW_CONNECTION_ID and having updates coupled to key changes, which
could work if you were willing to couple changes in that way.  The
problem there is twofold:  the provider of connection IDs is in
entirely control over when updates happen (you can't ever update
yourself unilaterally), and not all connections have a connection ID
in the relevant direction.  The former is annoying and probably
manageable, the latter is a real deal breaker.

>> ACK packets would increase in size by a couple of octets, which could be masked easily and cheaply if necessary.
>
> I’d challenge that, especially in the cases where it matters most: long running mobility applications. For example a car management system that uploads battery and other operational statistics, geofencing applications, or chat applications used by train commuters.

Are you suggesting that these applications have fixed size payloads
such that the change to a longer packet number would be noticeable.
That's might be true, but sending a TLS KeyUpdate message or
KEY_UPDATE frame would also change the size of packets in a fairly
obvious fashion if that were the case (many of these applications have
a predictable send rate) as well.  If there is an occasional increase
in rate, both in terms of number of packets and size, then yes, that
could reveal that a key update happened.  If that happens across a
change of path, then yes, there is a linkability exposure.  Given how
packet rates are low on these applications, it might be that key
updates could be disabled for those applications if this is a concern.
As it is, this is far better than a cleartext KEY_PHASE bit, which is
a great correlator.