Re: KEYS_READY

[Kazuho Oku <[e-mail]>]

2019年2月14日(木) 0:03 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 tend to agree, because to me it the same as having a variable length
packet header that, when being extended by one byte, indicates that
the next key is ready. Though it seems a bit flexible.

OTOH, I think it's interesting to discuss if the KEY_READY frame is
ack-eliciting. My understanding is that per the current PR it is,
because the list of non-ack-eliciting frames has not changed.

I can see arguments for having the frame defined as ACK-eliciting,
because it encourages endpoints to retire old keys soon. If we think
that to be a good property, I think that might be an argument for
using a frame (because calling a header bit ACK-eliciting would be
strange).

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


-- 
Kazuho Oku