Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message
draft-weis-gdoi-rekey-ack-07

[Ballot discuss]
I have concerns about the interoperability of this mechanism as defined.

Section 6 indicates that GMs may introduce ack jitter of "a few seconds," and that the GCKS should wait "several seconds" for receipt. These are both very subjective terms, and it would be perfectly reasonable for a GM implementor to decide that "a few seconds" is up to, say 10; while a GCKS implementor might reasonably think that "several seconds" is as short as, say, five. The result is two compliant implementations that don't actually interop under most circumstances. Please define a hard maximum amount of jitter that GMs can be expected to introduce "e.g., several seconds, but no more than five"), and advise that the GCKS wait a specific slightly longer amount (e.g., six seconds, which is five plus more than enough to accommodate a reasonable RTT).

[Ballot comment]
I was going to make the same comment Ben did about "...does not intend to..." but he beat me to it.

The document uses 2119 language, but doesn't appear to do so reliably (see, e.g., the "must" in section 3.1, and many instances of "may" throughout the document that appear to be normative). I suggest a pass through the document to ensure the use of 2119 terms is as intended.

Section 3.2, in describing the format of "L" in the ack_key derivation, needs to indicate byte order (I suspect you mean to say something like: "...as two octets in network order (that is, most significant byte first).").

I would also suggest that the guidance around detecting that a GM has left the group require that the GCKS receive at least one Ack from the GM before it uses the absence of an Ack to indicate that it has left; as the document notes, there are a number of reasons that the GCKS may not receive the Acks.

[Ballot comment]
I was going to make the same comment Ben did about "...does not intend to..." but he beat me to it.

The document uses 2119 language, but doesn't appear to do so reliably (see, e.g., the "must" in section 3.1, and many instances of "may" throughout the document that appear to be normative). I suggest a pass through the document to ensure the use of 2119 terms is as intended.

Section 3.2, in describing the format of "L" in the ack_key derivation, should indicate byte order (I suspect you mean to say something like: "...as two octets in network order (that is, most significant byte first).").

Section 6 indicates that GMs may introduce ack jitter of "a few seconds," and that the GCKS should wait "several seconds" for receipt. These are both very subjective terms, and it would be perfectly reasonable for a GM implementor to decide that "a few seconds" is up to, say 10; while a GCKS implementor might think that "several seconds" is as short as, say, five. The result is two compliant implementations that don't actually interop under most circumstances. Please define a hard maximum amount of jitter that GMs can be expected to introduce "e.g., several seconds, but no more than five"), and advise that the GCKS wait a specific slightly longer amount (e.g., six seconds, which is five plus more than enough to accommodate a reasonable RTT).

I would also suggest that the guidance around detecting that a GM has left the group require that the GCKS receive at least one Ack from the GM before it uses the absence of an Ack to indicate that it has left; as the document notes, there are a number of reasons that the GCKS may not receive the Acks.

[Ballot comment]
- 4: "If a GM does not intend to respond with Acknowledgements,..."

The previous paragraph said a GM that recognizes the ack request MUST return an acknowlegement. I assume this sentence refers to GMs that do not recognize the request, but it seems to allow any GM to just decide not to respond.

[Ballot comment]
- Thanks for addressing the very good gen-art review comments (And thanks Roni!)

- I guess the GM could indicate at registration time that it is able and willing to support ACKs. While this information is maybe not super helpful, it could potentially be used to detect network problem, e.g. that ACKs are dropped. Was this considered?

- sec 6: „A GM MAY introduce a jitter to the timing of its Acknowledgement message“
    -> I guess the server could also send out the push messages with jitter while the GM replies immediately. In this case there is less uncertainty when the ACK will be sent and how long the server has to wait for it. Was this considered?

- sec 7.1: „ Therefore, there is no direct value that the attacker derives from the knowledge of the sequence number.“
    -> Doesn’t knowing part of the encrypted text in clear potentially help to break the encryption? Should this be considered?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-weis-gdoi-rekey-ack-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the SA KEK Payload Values - KEK Attributes registry, located on the Group Domain of Interpretation (GDOI) Payloads registry page located at:

https://www.iana.org/assignments/gdoi-payloads/

a new registration is to be made as follows:

Value: [ TBD-at-registration ]
ID Class: KEK_ACK_REQUESTED
Type: B
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the KEK_ACK_REQUESTED Values registry. This will be a registry located on the Group Domain of Interpretation (GDOI) Payloads registry page located at:

https://www.iana.org/assignments/gdoi-payloads/

The new registry will be managed via Specification Required as defined in RFC 5226. There are new registrations in the new registry as follows:

Value Type Reference
------- --------------- -------------
0 Reserved [ RFC-to-be ]
1 REKEY_ACK_KEK [ RFC-to-be ]
2 REKEY_ACK_LKH [ RFC-to-be ]
3-128 Unassigned [ RFC-to-be ]
129-255 Private Use [ RFC-to-be ]

Third, a new subregistry is to be created called the GDOI DOI Exchange Types registry. This will be a subregistry of the GDOI ID Payload Type Values registry located on the Group Domain of Interpretation (GDOI) Payloads registry page located at:

https://www.iana.org/assignments/gdoi-payloads/

The new registry will be managed via Specification Required as defined in RFC 5226. There are new registrations in the new registry as follows:

Value Phase Reference
---- ----- -------------
GROUPKEY-PULL 32 [ RFC 6407 ]
GROUPKEY-PUSH 33 [ RFC 6407 ]
Reserved 34
GROUPKEY-PUSH-ACK 35 [ RFC-to-be ]
Unassigned 36-239

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-weis-gdoi-rekey-ack@ietf.org, Kathleen.Moriarty.ietf@gmail.com, adrian@olddog.co.uk
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (GDOI GROUPKEY-PUSH Acknowledgement Message) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'GDOI GROUPKEY-PUSH Acknowledgement Message'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Group Domain of Interpretation (GDOI) includes the ability for a
  Group Controller/Key Server (GCKS) to provide a set of current Group
  Member (GM) devices with additional security associations (e.g., to
  rekey expiring security associations).  This memo adds the ability of
  a GCKS to request the GM devices to return an acknowledgement of
  receipt of its rekey message, and specifies the acknowledgement
  method.

This draft references RFC2408 as GDOI continued its use of this RFC
when it was obsoleted by RFC5996 and subsequently RFC7296. This is an
intentional reference as explained in the shepherd report.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2217/