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

[Alissa Cooper]

Joel, thanks for your review. Göran, thanks for addressing Joel’s comment. 
Unfortunately I ran out of time to review this document before the telechat.

Alissa

> On Feb 23, 2018, at 9:40 AM, Joel M. Halpern  wrote:
> 
> Yes, that is what I was looking for.
> Thank you,
> Joel
> 
> On 2/23/18 9:38 AM, Göran Selander wrote:
>> 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" 
>> wrote:
>>> 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
>>> 
>>> On 2/23/18 9:30 AM, Göran Selander wrote:
 Hi Joel,
 
 Thanks for quick feedback, inline.
 
 On 2018-02-23 14:59, "Joel M. Halpern"  wrote:
 
> 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.
 
 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
 
 
 
> 
> Yours,
> Joel
> 
> On 2/23/18 5:26 AM, Göran Selander wrote:
>> Hi Joel,
>> 
>> Thanks for your review. Comments inline.
>> 
>> 
>> On 2018-02-22 04:51, "Joel Halpern"  wrote:
>> 
>>> 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
>>> 
>>> .
>>> 
>>> 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.
>> 
>> 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
>> 
 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel M. Halpern]

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

On 2/23/18 9:38 AM, Göran Selander wrote:


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" 
wrote:


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

On 2/23/18 9:30 AM, Göran Selander wrote:

Hi Joel,

Thanks for quick feedback, inline.

On 2018-02-23 14:59, "Joel M. Halpern"  wrote:


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.


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





Yours,
Joel

On 2/23/18 5:26 AM, Göran Selander wrote:

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern"  wrote:


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

.

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.


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







___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Göran Selander]

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" 
wrote:

>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
>
>On 2/23/18 9:30 AM, Göran Selander wrote:
>> Hi Joel,
>> 
>> Thanks for quick feedback, inline.
>> 
>> On 2018-02-23 14:59, "Joel M. Halpern"  wrote:
>> 
>>> 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.
>> 
>> 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
>> 
>> 
>> 
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/23/18 5:26 AM, Göran Selander wrote:
 Hi Joel,

 Thanks for your review. Comments inline.


 On 2018-02-22 04:51, "Joel Halpern"  wrote:

> 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
>
> .
>
> 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.

 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

>> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel Halpern Direct]

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

On 2/23/18 9:30 AM, Göran Selander wrote:

Hi Joel,

Thanks for quick feedback, inline.

On 2018-02-23 14:59, "Joel M. Halpern"  wrote:


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.


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





Yours,
Joel

On 2/23/18 5:26 AM, Göran Selander wrote:

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern"  wrote:


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

.

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.


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





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Göran Selander]

Hi Joel,

Thanks for quick feedback, inline.

On 2018-02-23 14:59, "Joel M. Halpern"  wrote:

>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.

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



>
>Yours,
>Joel
>
>On 2/23/18 5:26 AM, Göran Selander wrote:
>> Hi Joel,
>> 
>> Thanks for your review. Comments inline.
>> 
>> 
>> On 2018-02-22 04:51, "Joel Halpern"  wrote:
>> 
>>> 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
>>>
>>> .
>>>
>>> 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.
>> 
>> 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
>> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Joel M. Halpern]

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

On 2/23/18 5:26 AM, Göran Selander wrote:

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern"  wrote:


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

.

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.


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



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Göran Selander]

Hi Joel,

Thanks for your review. Comments inline.


On 2018-02-22 04:51, "Joel Halpern"  wrote:

>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
>
>.
>
>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.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art