Re: KEYS_READY

[Ian Swett <[e-mail]>]

I'm happy with the approach you outline here and wrote up in the PR, but I
did find the PR a bit confusing, partially because it's based on an
existing PR that's gone through a lot of revisions.

I don't think tying transmission of this to an encryption level will be
overly complex, because since it's only a single byte, I might just put it
in every ack-eliciting packet until it's no longer necessary and not use
the standard retransmission logic.

I'd rather not burn another bit in the first byte for this.

On Wed, Feb 13, 2019 at 8:00 AM Marten Seemann <[e-mail]>
wrote:

> I went through a few key update scenarios under different packet loss
> patterns, and I have to admit that I found the KEY_READY frame surprisingly
> difficult to reason about. The problem seems to be that we're replacing
> what is in reality a contiguous state (it is permitted to update the keys)
> with a one-time signal, which has to be retransmitted (taking care to
> either block further key updates until this frame has been acknowledged, or
> canceling the retransmission when performing another key update). The
> reason we decided to create an explicit signal instead of consulting the
> loss recovery state, was that we wanted to avoid a tight coupling between
> the loss recovery and the key management. I have the impression that we're
> now just trading one tight coupling for a slightly different one.
>
> I agree with Kazuho that using a bit in the first byte seems to capture
> the update logic we're looking for better. There's no need to retransmit
> any information, since the bit is set on every subsequent packet.
>
>
>
> On Wed, Feb 13, 2019 at 4:36 PM Mikkel Fahnøe Jørgensen <
> [e-mail]> wrote:
>
>> 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
>>
>>