Re: [core] Review of draft-ietf-core-oscore-groupcomm-02

Marco Tiloca <> Wed, 24 October 2018 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37AB512785F; Wed, 24 Oct 2018 06:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 94JmK3x0aLLo; Wed, 24 Oct 2018 06:53:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 376F0130E8D; Wed, 24 Oct 2018 06:52:59 -0700 (PDT)
Received: from 1gFJai-000Upn-U7 by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gFJai-000UrI-Vb; Wed, 24 Oct 2018 06:52:56 -0700
Received: by emcmailer; Wed, 24 Oct 2018 06:52:56 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gFJai-000Upn-U7; Wed, 24 Oct 2018 06:52:56 -0700
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 15:52:56 +0200
To: Jim Schaad <>, <>
CC: 'core' <>
References: <042401d43f3d$46e429e0$d4ac7da0$>
From: Marco Tiloca <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= xsBNBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAHNJ01hcmNvIFRpbG9jYSA8bWFyY28udGlsb2NhODRAZ21haWwuY29tPsLAewQTAQIAJQIb AwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSNerkCGQEACgkQ7iZktA5Y2kMiuwgAt/bV ZKqD92JNWDTX6h1MUsgejwj4RXs6UYqFdWW/4nw4mFHzYS+gBjOQAWCBhzVZLOk6gKcRZ/s8 6ncVygiDUh9fbSDTcuzOp2qgu9nsc8sEsYp1hwmiIEbI6FHPtyeQQNilsfU8+VHX2C9yQtMK /OXlf5qNkJMj9k55u+e1ELQ2sjUXkMB4MxMhmi/3P3hMz9PDcB66BtQcDFYkx5PIaz/izCST 0o28AJq0dionJpPsQ+hFOIAkJi6aCAt3xQf0KnXlAczWxCD3J3XTFK4MES/b3n3oc2GJY8I+ tsfT5jpNsWhfWGBkMaQSKZ939D4oFAhAq3gnNRgZszJeTvsMvc7ATQRUjXkVAQgAlpqfpOi5 GOP3su3gO7pmFXNtoslagBF5ssA2MxI3sGMEXI06x/zcdRKsIyA7lvgQRKDC0WThwoJo6Oh0 ZliLrXGFQrfYnqJLpbZKK/QQaEFT4iPk6edTqdNon5BnKxEDWYu6t35jrYRWcGejSZ1GwNm8 nGimfKApbwwkI+gIxMnQT50u91GhKA7KrBlY2cAoXzjIOTshZvdEI6SMPJtLg1XAsyin8at0 /8+7ckYLnCFHvOBMwbriQREhIyv4RdJ0diw4dUoQ9vRVqxWUjVVQlbtVGGSwGsn/KCihx6TP sIX4xGDuF7A6VeM0NeQPg9eR0Yh0egHX+Dw7TzNQwsIIIwARAQABwsBfBBgBAgAJBQJUjXkV AhsMAAoJEO4mZLQOWNpDxhMH/1jY08t8++Ly5h8nFbBV16EPFtfvOfJkcgHdGvCWM2N8Qewl baiNx8vPeEHMOB+hu/fQNTi/QdRHgPGI92js9DW1Mn+RlvoqLa94fPiiAjmGd+PwUGji83bw zZkaBh5/jXk84Re3knojyoto3sfjVaHYYzlRl8PBIWBpHmS78pxxG6IizOE28j21UfR7HVai hlUw8SkhN52pqN5L7WOrMkRSIlM+VsyX2ALqm7ept08QxG/LAPac2i7oZn5yUXNdh+TVWRGZ hPxJCRU5ZD+MJ2cjkn/69v1XdIh2rgcL+e3KWOhxRTHu67yuLOzBOc3LThJcuQujQrtWWjbX VLqg0jw=
Message-ID: <>
Date: Wed, 24 Oct 2018 15:52:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <042401d43f3d$46e429e0$d4ac7da0$>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="69jUUsz86CigHkDYrljQPn0zXjUaZBY4v"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <>
Subject: Re: [core] Review of draft-ietf-core-oscore-groupcomm-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Oct 2018 13:53:28 -0000

Hello Jim,

Thank you very much for your comments!

We took them into account for the latest version -03.

Please, find our answers in line.


On 8/29/18 4:09 AM, Jim Schaad wrote:
> Introduction - The use of DTLS will not work for the multicast send.  This
> should be noted

MT: Now we mention it in the last paragraph of the introduction.

> * Text on counter signature algorithm seems to be internally inconsistent.
> If a single algorithm is to be used, then it is dictated by the GM and as
> such there is not a list of algorithms which is part of the policy.  I am
> unsure if there is really a requirement for a single algorithm to be used
> here.  How much of a requirement on endpoints to maintain multiple signature
> algorithms during roll over al algorithms does this impose?

MT: We have clarified this point in Section 2, when discussing the
Common Security Context. A group member uses a single signature
algorithm, as dictated by the GM. Also, we now indicate ed25519 as
mandatory to implement.

> * Discuss the implications of rotating a new key over wrt message which
> might still be in transit or sent before the other EP learns of the key roll
> over.  How long do you keep the old context?

MT: This is discussed in the new Section 8.4 under the Security
Considerations. It is up to the application to define the maximum amount
of time an old context is possibly retained.

> * I don't want the size of q to be implicit - place make it explicit.  My
> code is decoding the header before I know what the context is and therefore
> what |q| is and don't want to parse it.

MT: We moved the countersignature away from the OSCORE Option. The
countersignature is now appended to the encrypted payload of the OSCORE

MT: So doing: i) the message header can be parsed entirely; ii) the
OSCORE security context is retrieved; iii) the signature algorithm in
the Security Context indicates the size of the countersignature at the
end of the OSCORE message.

> * Not sure that I would want to use it, but what is the length of a hash
> based signature.

MT: they can be quite large in size, see also

MT: since we moved the countersignature to the end of the OSCORE message
as per the comment above, there is no need to explicitly indicate its
size in the OSCORE option as before.

> * Section 4 - may be worthwhile to say that this does not prevent the
> acknowledgement of a CON request for non-multicast environments.

MT: We have mentioned it in the third paragraph of Section 6 (former
Section 4).

> * section 4 - does the prohibition on sending responses extend not only to
> malformed messages but to messages which do not validate cryptographically?

MT: Absolutely. Now the second paragraph of Section 6 (former Section 4)
also says "... or which is not cryptographically validated in a
successful way."

> * Section 7.2 - remind me what cases A and B are here

MT: Done (now Section 8.2).

> * What is the external_aad structure used for the counter signature
> operation - is it the same as for the encryption?

MT: Yes, it is the same one. Now we explicitly say that in Section 3,
first bullet.

> * Should make it explicit that the kid is always set in a response - unlike
> normal OSCORE.

MT: Now we say it explicitly in Section 3 (second bullet), as well as in
Section 4.1 (first bullet) when discussing the fourth least significant
bit of the flag byte.

> * Appendix A - the group size should note that the differences that are
> introduced by the use of silent servers - In that case the group size is
> limited by how stable it is and not the gross count of members.

MT: Could you please elaborate more on this point?

MT: "Stable" makes me think more of no or infrequent changes in the
group membership, regardless the role(s) of the group members.

MT: If the group size does not take into account silent servers (that by
the way can be configured also as clients), I agree there is a weaker
relation between group size and amount of expected traffic in the group.
On the other hand, it would badly reflect the expected overhead for
rekeying the group, which affects all members regardless their role(s),
hence why I tend to see the "group size" as a "gross count".

> * Notification from a client to the GM about the possibility of exhausting
> the PIV space

MT: This is now discussed in the new Section 2.2.

> * Appendix C - should note that roll over on the epoch w/o modifying the
> group prefix is perfectly reasonable assuming that sufficient time has
> elapsed so that the group ID is still temporally unique (i.e. there should
> be no messages running around the system w/ the old one).  Rate of
> addition/deletion of members can therefore be an influence on the size of
> the epoch.

MT: This is now discussed in the fifth paragraph of Appendix C.

> s/consistently with/consistent with/

MT: Done.

Thanks a lot again for your review!

> jim

Marco Tiloca
Ph.D., Senior Researcher

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

Phone: +46 (0)70 60 46 501