Subject: [Gen-art] Genart last call review of draft-ietf-core-object-security-08

From: Joel Halpern <[email-masked]>
Date: Wed, 21 Feb 2018 19:51:43 -0800

Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-core-object-security-08
Reviewer: Joel Halpern
Review Date: 2018-02-21
IETF LC End Date: 2018-03-02
IESG Telechat date: 2018-03-08

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: N/A

Minor issues:
    In section 8.2 on verifying the request, step 5 says to "compose" the
    Additional Authentication Data.  I would have expected it to be "verify"
    the Additional Authentication Data.  I could imagine that the verification
    consists of composing what it should be, and then comparing with what is
    received.  But I do not see the comparison step.  is it implicit in some
    other step?  This occurs again in 8.4, so I presume I am simply missing
    something.  This may suggest some clarification could be useful.

Nits/editorial comments: N/A

---

From: Göran Selander <[email-masked]>
Date: Fri, 23 Feb 2018 10:26:09 +0000

Hi Joel,

Thanks for your review. Comments inline.

>    something.  This may suggest some clarification could be useful.

The AAD is indeed “composed" both on encrypting and decrypting side from
data which needs to be known to the endpoint at the time when the AEAD
operation is performed. The authenticated decryption process is described
in:

https://tools.ietf.org/html/rfc5116#section-2.2

So the verification consists of feeding the input, including the AAD, to
the authenticated decryption which calculates the plain text or FAIL, and
a failure may be - but is not necessarily - caused by wrong AAD.

The AD review also indicated that we should move the reference to RFC 5116
to an early section in the draft and that change is already included in
the latest version on the CoRE WG Github.

Best regards
Göran

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Feb 2018 08:59:38 -0500

In terms of my concerns, if Step 7 said "Verify and Decrypt the COSE 
object using the Recipient Key as per RFC 5116 Section 2.2" that would 
fill in the confusion for this reader.

Yours,
Joel

---

From: Göran Selander <[email-masked]>
Date: Fri, 23 Feb 2018 14:30:40 +0000

Hi Joel,

Thanks for quick feedback, inline.

>fill in the confusion for this reader.

Since the AEAD is used throughout the draft, in particular in other parts
of this section I’m thinking that maybe we should add RFC 5116 to the list
of specifications following "Readers are expected to be familiar with” in
Section 1.1. Would that address your comment?

Thanks
Göran

>>>     consists of composing what it should be, and then comparing with
>>>what
>>> is

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 23 Feb 2018 09:32:34 -0500

I guess it is up to you.  Personally, I like the idea of the verify 
description including some reference to how one actually does verify.
I will leave it to the authors and WG to decide what degree of clarity 
is called for here.

Yours,
Joel

---

From: Göran Selander <[email-masked]>
Date: Fri, 23 Feb 2018 14:38:29 +0000

How about this (see the last and third to last edit):
https://github.com/core-wg/oscoap/commit/8f277d83

where the reference is made to COSE instead of AEAD?

Best
Göran

On 2018-02-23 15:32, "Joel Halpern Direct" <[email-masked]>
wrote:

>>>>> Summary: This document is ready for publication as a Proposed
>>>>>Standard
>>>>> RFC
>>>>>
>>>>> Major issues: N/A
>>>>>
>>>>> Minor issues:
>>>>>      In section 8.2 on verifying the request, step 5 says to
>>>>>"compose"
>>>>> the
>>>>>      received.  But I do not see the comparison step.  is it
>>>>>implicit in
>>>>> some

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Feb 2018 09:40:57 -0500

Yes, that is what I was looking for.
Thank you,
Joel