Re: [core] I-D Action: draft-ietf-core-oscore-groupcomm-10.txt

[Marco Tiloca <[e-mail]>]

Hi Christian,

Thanks a lot for this review and the discussion around the raised 
points, it was really useful!

We have taken your comments into account in the latest version -11. 
Please, check whether they are all properly addressed.

See also below detailed inline replies to your comments.

Best,
/Marco

On 2020-11-10 18:15, Christian Amsüss wrote:
> Hello OSCORE-groupcomm authors,
>
> thanks for incorporating my earlier comments.
>
> While reading -10 for the purpose of implementing it, a few more points
> came up (in linear order of the document):
>
> * "Furthermore, sufficiently large replay windows should be
>    considered,": This paragraph reads as if a server receiving a high
>    sequence number gets completely out of sync (to the point where it
>    needs to recover), when actually the only ill-effect of a, say, a jump
>    from 1000 to 1100 with a 32bit replay window is that a delayed message
>    with sequence number 1002 will be rejected. The next message at 1101
>    will still be accepted.
>
>    Recovery *will* be necessary if the server has, in the mean time,
>    evicted the client's replay window out of its list of available
>    windows. So maybe the recommendation should rather be to not have
>    overly long replay windows (or to suggest the replay windows may be
>    truncated when unused), as that'd allow the server to keep more
>    clients' replay windows around.
>
>    (Or I just misread the paragraph).

==>MT
Section 6.1 "Update of Replay Window" now treats the possible jumping 
forward of the Sender Sequence Number as something that the server has 
to simply be fine to handle, just as in OSCORE.

The recovery, including the case of overloading of Recipient Contexts, 
is also mentioned here in Section 6.1, but now separately discussed in 
Section 2.4.1.2 "Overflow of Recipient Contexts".
<==

>
> * It felt like there are different ways for the sender sequence number
>    to go back to 0. (Search for " to 0", first three occurrences). What's
>    really the case is that the first two *trigger* the third, but the
>    repetition around there made them read like separate things.

==>MT
The text has been restructured to clarify cause-effect relations in a 
more linear way.

That is, Section 2.4.1 "Loss of Mutable Security Context" and Section 
2.4.2 "Exhaustion of Sender Sequence Number" are both possible causes 
that trigger what described in Section 2.4.3 "Retrieving New Security 
Context Parameters".

The resulting actions are getting a new Sender ID (Section 2.4.3.1) 
and/or participating to a group rekeying (Section 2.4.3.2). In either 
case, the involved client resets its Sender Sequence Number to 0.
==>

>
> * "and SHOULD preserve the current value of the Sender ID of each group
>    member.": Why bother? It's not like anything can be reused after the
>    master secret changed.
>
>    ("bother", because the GM may want to hand out KIDs sequentially
>    rather than tracking a bitfield).
>
>    * Oh, I see -- later on it says that KIDs can never be reused, even
>      when master parameters change. Doesn't that lead to irrecoverably
>      large KIDs over time? (Ie. they're shiny short first, but after a
>      few joinings, group leaves, device restarts and other fluctuation,
>      they wind up in the >=4-byte range).
>
>      This also reads a bit controversially -- it says "Even if Gid and
>      Master Secret are renewed as described in this section, the Group
>      Manager MUST NOT reassign", which sounds like "never ever", but
>      misses the master salt from the line above. And it refers to
>      2.4.3.1, where it only talks about KID reuse ~"if none of the master
>      parameters change". 3.2 item 5 reads like "never ever" again, so
>      this needs clarification first and then editing.

==>MT
Following also more discussions, we went for the following updates.

Within an OSCORE group, the Group Manager must assign a Sender ID that 
has never been assigned before in the group under the current Gid value 
(see Section 2.4.3.1 and Section 3.2).

Within an OSCORE group, the Group Manager must assign a Gid that has 
never been assigned ever before in the group (see Section 2.4.3.1 and 
Section 3.2).
<==

>
> * "The value of the 'kid' parameter in the 'unprotected' field of
>     response messages MUST be set to the Sender ID of the endpoint
>     transmitting the message."
>
>    Is this the case even when requests were made in pairwise mode?
>
>    (For comparison, the section above (4.1) is explicitly "for group mode
>    only", and 4.3 says "in group and pairwise mode".)

==>MT
We have updated Section 4.2 "The COSE Object" to mandate 'kid' in 
responses only if sent as reply to a request protected in group mode.

The examples in Section 5.1.2 are also updated accordingly.
<==

>
>    * Does it make sense to use the 4.3 extended parameters (with the new
>      algorithm data and the added group ID) in pairwise mode?
>
>      After all, everything else in there (including the group mode bit)
>      is really just vanilla OSCORE. Or are observations in
>      pairwise-pairwise mode supposed to survive rekeying? (If that's the
>      case, the question may arise whether anyone might be tempted to use
>      pairwise-pairwise in a 1:1 setting just to use that property).

==>MT
Yes, observations are intended to continue after a group rekeying, 
regardless the mode used to protect messages.

Some information in the two external_aad is not relevant in pairwise mode.

As discussed at IETF 109, we ended up converging to a single 
external_aad structure, used in both modes of operations and for both 
encrypting and signing (see Section 4.3).
<==

>
> * external_aad: Why is countersign_key_type_capab in there twice?

==>MT
As part of the external_aad restructuring (see previous comment), the 
new single format in Section 4.3 does not repeat the key type 
capabilities anymore.
<==

>
> * "The new element 'request_kid_context' contains the value of" could
>    use some explaining why this now is in here.
>
>    AFAIR, it is to allow observations to extend over rekeyings.

==>MT
We have added a bullet point in Section 4.3 to explain why the new 
parameter is there.
<==

>    (Shouldn't also, due to this, KIDs be reusable once the KID-Context is
>    changed?)

==>MT
Yes, that's also been addressed (see previous comment on allowed 
recyclying of Sender IDs under different GIDs).
<==

>
>    Same for the OSCORE_option being present in the signature
>    external_aad. (A forward reference to 10.6.2 may do).

==>MT
We have added a bullet point in Section 4.3 to explain why the new 
parameter is there.

This also includes a forward pointer to Section 10.6, which describes an 
attack that the OSCORE_option parameter makes infeasible to perform when 
the group mode is used.
<==

>
> * Examples in Group Mode: I think it's easier to grasp if rather than
>    using the value "COUNTERSIGN", a signature value a la "de 9e ... f1" /
>    0xde9e...f1 (depending on the representation) were used; the
>    COUNTERSIGN value reads too much like a constant in the
>    before-compression COSE object ("What's that, a numeric, a tagged
>    value?").

==>MT
Done. See examples in Section 5.1.1.
<==

>
> * "Note that, if the Group Flag is set to 0, and the recipient endpoint
>     retrieves a Security Context which is valid to process the message
>     but is not associated to an OSCORE group,"
>
>    I don't have a fleshed-out proposal here, but we may manage to use the
>    same bit for other purposes in non-group-OSCORE messages.
>
>    As the introduction to that section states, the receiver MUST be able
>    to distinguish from the KID context and KID whether it's from a Group
>    OSCORE or a different context. For Group OSCORE, that bit
>    distinguishes between group and pairwise. For other, that other may
>    use that bit.
>
>    (I know that this is contradicting the previous suggestion that led to
>    this bit being flipped in -09; recent discussions about flag bit usage
>    indicate to me that other ways of getting OSCORE keys may have
>    different varieties as well, and this would align well then).

==>MT
We have updated the text so that a Security Context is retrieved first, 
before checking the Group Flag bit.

See especially Section 7 (second bullet point) and the rephrasing for 
the IANA registration in Section 11.1.
<==

>
> * "For each ongoing observation, the server MUST include in the first
>    notification": This may get sucked up by a proxy that doesn't forward
>    until a following notification arrives.
>
>    Moreover, it may be unnecessary if the rekeying fits snugly between
>    notifications.
>
>    Suggested alternative:
>
>    The server can help the client synchronize by sending the Gid as the
>    ID Context for notifcations following a rekeying. If there is a known
>    upper limit to the duration of a full rekeying, it SHOULD set the Gid
>    during that time. Otherwise, it SHOULD set it until the Max-Age of the
>    last notification before the rekeying has expired.

==>MT
Thanks, we have accordingly updated the last two paragraphs in Section 
8.3.1.
<==

>
> * "Senders MUST NOT use the pairwise mode to protect a message intended
>    for multiple recipients.": That's a factual and not an
>    interoperability statement. It can not.
>
>    If that's meant to rule out a pairwise request to the broadcast
>    address (hoping that the right node will answer), it should say
>    "protect a message sent to multiple recipients".
>
>    (But probably that's not what's meant, given 9.1 proposes an address
>    discovery resource, and for accessing that by a single KID the
>    pairwise mode would make a good choice).

==>MT
Thanks for this good input. It should be captured now in the sixth and 
seventh paragraphs of Section 9.
<==

>
> * Sections 9.2ff are described as a delta to 8.1ff.
>
>    Given the external_aad and key choices are already in the section 9
>    header, would there be any per-step delta left to explain at all if
>    they were instead relative to RFC8613 Section 8? That'd make Section 9
>    a lot slimmer.

==>MT
Sections 9.2-9.6 have been rewritten as a delta from RFC 8613.
<==

>
> * I'm still not fully sold on why the Object-Security option needs to be
>    in the external_aad -- but having two versions of the external_aad
>    seems extraneous to me. If the option needs to be in there, I think
>    it'd be easier to have it in the external_aad for all purposes right
>    away.

==>MT
This is now explained in the last bullet point of Section 4.3, together 
with a forward pointer to Section 10.6 where the addressed attack is 
discussed.

This is also part of the broader update to the external_aad, now having 
a single format for both modes of operation, and for both signing and 
encrypting.
<==

>
>    Also, was treating the OSCORE option as Class I considered? That
>    doesn't solve the problem of having many different external_aad
>    constructions, but it'd be using existing mechanism. (Although
>    implementors may curse if they didn't do Class I yet).
>
>    I'll come back to that once I've actually implemented it.

==>MT
Having the OSCORE option of class I was once considered but just 
dismissed to not bother implementers :-) That's when relying on the 
external_aad was considered instead.
<==

>
> * "Unless exchanges in a group rely only on unicast messages": I think
>    that's only understandable for readers that have an active memory of
>    Section 7.4 of RFC8613; it'd need either more context or slimming
>    down, maybe like this?
>
>    "As multicast usually involves unreliable transports, the
>    simplification of the replay window to a size of 1 that's suggested in
>    RFC8613 Section 7.4 is not viable with Group OSCORE."

==>MT
Based on your input, we updated Section 10.10 with the current third 
paragraph.
<==

>
> * Summarizing the KID-reuse questions, I think a diagram of the
>    componetns may help, like:
>
>                          ←--→ KID
>    Secret ←--→ Group ID  ←--→ KID
>                          ←--→ KID
>            ↑
>    Change in             ↑  ↑-- Group ID changes allow old KIDs to be reused
>    lockstep              |      (but KIDs usually stay the same for efficient rollout)
>                          --- KID changes don't necessitate a Group ID change
>
>    (are there any other components that can chagnge?)
>
>    In that context: Can an ancient group ID be reused?

==>MT
Done. See Figure 2 in Section 3.1.
<==

>
> * E.1 and E.2 Best Effort Synchronization / Baseline Synchronization
>
>    A server doing any of these needs to use own Partial IVs all the time.
>    It may be acceptable in a scenario to eat the replays, but it's almost
>    certainly not acceptable to commit nonce reuse (which *can* happen
>    with Best Effort Synchronization).

==>MT
Right, *that* whiteboard discussion at the IETF 109 Hackathon! :-)

This has resulted in the following updates:

* Section 2.2 (last paragraph) explains the need to limit the number of 
Recipient Contexts for an endpoint, and the possibility of an overflow.

* A clearer distinction between anti-replay and freshness. Changes 
affect the following Sections:

--- 2.2 "Security Context and Recipient Context"
--- 2.4 "Update of Security Context"
--- 2.4.1 "Loss of Mutable Security Context"
--- 2.4.1.1 "Reboot and Total Loss"
--- 2.4.1.2 "Overflow of Recipient Contexts"
--- 6.1 "Update of Replay Window"
--- 6.2 "Message Freshness"
--- 10.10 "Replay Protection" (Security considerations)
--- 10.11 "Message Freshness" (Security considerations)
--- Appendix E (was E.3) "Challenge-Response Synchronization"

* Removed the old Appendix E.1 and Appendix E.2, as non relevant 
synchronization approaches.
<==

>
> * E.3 Challenge-Response Synchronization:
>
>    "The server MUST NOT set the Echo Option to a value which is both
>    predictable and reusable." While this is technically correct, it's
>    hard to evaluate as a reader. How about "The Echo option value SHOULD
>    not be reused, and when it is MUST be highly unlikely to have been
>    used with this client recently."?

==>MT
Done, see the second paragraph of current Appendix E.
<==

>
>    * "sends a request as a unicast message addressed to the same server":
>
>      That should indicate pairwise mode.
>
>      There's later paragraphs on this where 10.7 is mentioned, but given
>      how widely this open things up, pairwise mode should be mandatory on
>      Echo recovery.

==>MT
Done, see the fifth paragraph of current Appendix E.
<==

>
>    * "The server either delivers the request to the application if it is
>      an actual retransmission of the original one, or discards it
>      otherwise": For that the server would need to remember. Ther *is*
>      somethign to take care of, though: Only the first time the Echo
>      request arrives it can be processed, otherwise it may reset an
>      already good replay window.
>
>      Suggesting to replace the paragraph with:
>
>      "If the verification is successful and the replay window has not
>      been set yet, the server updates its Replay Window to mark the
>      current sequence number as seen (but all newer ones as new), and
>      forwards the message as fresh to the application.
>
>      Otherwise, it discards the verification result and treats the
>      message as fresh or replay according to the existing replay window."

==>MT
Done, see the second paragraph after the bullet list, in current Appendix E.
<==

>
>      "(believed to be) lost"
>
>      How is that not a binary thing? (May relate to the first question).
>      Either there is a replay window, in which case it can be used (and
>      it does get fast-forwarded in need be), or not and it needs to be
>      recovered.
>
>      The following paragraphs elaborate on what a loss would mean, but
>      don't explain why it would be relevant. Something like this would be
>      applicable if we only ever transported the last bits of the sequence
>      numbers in a sliding-window fashion, but that's not what happens in
>      OSCORE.

==>MT
Done.

Thanks a lot again for your input and comments!

Best,
/Marco
<==

>
> KR
> Christian
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcore&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cc21e90c15f74443ad3e008d8859c67df%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637406254091815430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SC37JAoObx0rWMO%2FVKg89UqH54lmO3ObPSqcDBRPdtc%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se