Re: KEYS_READY

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

I can see arguments for having the frame defined as ACK-eliciting,


It cannot not be ACK-eliciting, otherwise a lost packet could mean that no
new key updates would be possible.



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

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