Re: KEYS_READY

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

Thanks for pointing out the second alternative, although reluctantly.

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).

You could state that the KEY_PHASE bit is the lower bit the key counter
which increments by one on each key update, starting at 0 or 1.
Then, a KEY_READY with a future count is a PROTOCOL_VIOLATION and an old
count is ignored. The key phase or the packet protection of the packet
containing the KEY_READY frame is of no significance.

I also suspect that the alternatively two-bit proposal might have a problem
with idempotency, but I think it sorts itself by failing packet protection.

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.

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.

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.

Mikkel

On 13 February 2019 at 06.55.57, Kazuho Oku ([e-mail]) wrote:

Hi, Martin

Thank you for writing the PR. My comments inline.

2019年2月13日(水) 10:46 Martin Thomson <[e-mail]>:
>
> https://github.com/quicwg/base-drafts/pull/2237 has been updated to
include the discussed new frame.
>
> This allows us to remove the implicit-ish acknowledgment of Initial
packets, fix the problem Marten identified with discarding Handshake keys,
and the problem Kazuho found with multiple and simultaneous key updates.
>
> There were two designs that were valid here, and I want to ensure that
people think about the choice:
>
> The one I chose to write up uses a design like ACK. The keys used to
protect the packet determine how the frame is interpreted. That is,
KEYS_READY in a packet implies that the corresponding keys are in use. The
cost here is that you have to purge any potential retransmissions of
KEYS_READY when you update keys or you risk creating a false signal.
>
> The alternative involves more explicit signaling, and requires us to
label each set of keys unambiguously.

My weak preference goes to burning a bit in the first byte (we have
reserved bits in all the necessary packet types) due to the
exceptional retransmission rule that we would have for the frame, but
I'm not sure how much I care.

> For that we could borrow the DTLS epoch convention, though that is
inconveniently out of phase with the Key Phase we use; not a major issue,
but a little hard to reason about. This doesn't have a retransmission
problem, but in addition to the need to document the counting system, we
would need to decide whether a mismatch between frame and packet is OK, or
something that can produce a connection error.
>
> Obviously, I have a preference for the former, but if people feel
differently, this is a good place to register your reasons.
>
> Editorial concerns should be directed toward the pull request.
>


-- 
Kazuho Oku