Re: KEYS_READY

[Martin Thomson <[e-mail]>]

On Wed, Feb 13, 2019, at 19:36, Mikkel Fahnøe Jørgensen wrote:
> I think the first option with anonymous KEY_READY has a problem with
> idempotency as well as tying state to retransmission logic. This means that
> naive retransmission of packet content in a new packet number is no longer
> valid, and likewise, naive processing of a frame that passes authentication
> is also no longer possible. That is a strong principle break and I don’t
> think the minor simplicity of a label-less KEY_READY frame can justify that
> (even if one ought no do such naive transmission).

I don't see this is a strong break with principle.  Like ACKs, KEYS_ACTIVE/KEYS_READY is tightly bound to the associated logic.  With ACK, it's packet receipt, here it's the keys you use for protecting/un-protecting packets.  In processing a KEYS_ACTIVE frame, you check what the most recent keys you have for reading and writing.  If they are the same, then you set the "can key update" flag on.  If the read keys are ahead of the write keys, then you have an error.  It doesn't require an active connection to the packet protection logic other than that.

> The text mentions that the updated key depends on the current traffic key
> with reference to TLS 1.3. From reading this naively, it sounds like
> forward secrecy is lost, which I am sure it is not.

This isn't relevant to this discussion, but I encourage you to read draft-irtf-cfrg-re-keying which goes through the various trade-offs of rekeying designs.  TLS 1.3 has text on this also, and QUIC shares that design.
 
> Finally, this is just a high level view. I find the overall text hard to
> understand, notably because it is not crystal clear whether the two
> endpoints update their transmission keys in sync with the ready keys, or if
> the (currently implicity) key phase counters can count independently.

If you have more specific comments (the one about read keys is a good one), I'll take those on the PR.
 
> That said, I like the idea of an explicit READY frame, and i probably would
> also like and explicit handshake ready frame, if it isn’t effectively the
> same thing, and if it is, perhaps formalise that.

We're working on that as the next step.