Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10

From: Göran Selander <[email-masked]>
Date: Tue, 1 Sep 2020 14:19:38 +0000

Hi Barry,

Sorry for the slow response. I missed this mail in the pile waiting after vacation. 

Thanks for your comments, responses inline below. I made a commit out of my responses:
https://github.com/core-wg/echo-request-tag/commit/d37ff64

My co-authors have not read this so may also have some input. When there are no further comments on this part we will submit -11.

On 2020-08-04, 05:17, "Barry Leiba" <[email-masked]> wrote:

    Thanks for the work on this document.  I have a number of comments about
    things that I think need clarification or rewording in my review below, so
    I’m setting the state on the document to “revised I-D needed.”  Please ask
    if you have questions or disagreements with anything below, and let’s
    discuss anything that needs discussion.

    I would prefer it if the document were specific about what “when CoAP is
    used with security” means, ideally not using that phrase at all, as
    “security” without explanation isn’t meaningful.  If you mean “over an
    encrypted channel”, please say that.  Or something else?

[GS] Is the formulation of section 4.2 better, i.e. "when CoAP is used with a security protocol"?
The text in the abstract would then read:
"This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, "
The rationale to mention "when CoAP is used with a security protocol " here is that a layman would expect a binding between response and request to hold when CoAP is used with a security protocol (in contrast to when CoAP is used without a security protocol, when no binding is expected) and would thereby be surprised that the property does not automatically hold, e.g., for CoAP with DTLS, but additionally requires restricted use of Tokens.

    — Section 1.1 —

       Unless otherwise specified, the terms "client" and "server" refers to

    Nit: “refer to”, plural.

[GS] Done.

       The complete interchange of a request and a response body is called a
       (REST) "operation".

    “REST” will need expansion and a reference.  You can copy these from 7252.

[GS] Done.

       Two request messages are said to be "matchable" if they occur between
       the same endpoint pair, have the same code and the same set of
       options except for elective NoCacheKey options and options involved
       in block-wise transfer (Block1, Block2 and Request-Tag).

    There’s something missing here: this says, “X is true if A, B.”  It needs
    an “and” or an “or” instead of the comma, no?

[GS] The intention was “X is true if A, B, and C.”  Does this read better?
"Two request messages are said to be "matchable" if they occur between the same endpoint pair, have the same code, and the same set of options with the following exception: elective NoCacheKey options and options involved in block-wise transfer (Block1, Block2 and Request-Tag) need not be the same."

       Two matchable block-wise operations are said to be "concurrent" if a
       block of the second request is exchanged even though the client still
       intends to exchange further blocks in the first operation.

    This appears to describe concurrent block-wise request operations.  Can
    there also be concurrent block-wise response operations?

[GS] The only aspect of concurrency we need to address here are those of concurrent requests. The CoAP option ETag can handle distinction between responses as is described at the end of section 3.1 and beginning of section 3.2.

    — Section 2.2 —

       but also in general for synchronizing state between CoAP
       client and server, cryptographically verify the aliveness of the
       client, or force a client to demonstrate reachability at its claimed

    Nit: This isn’t parallel: the first item uses “synchronizing”, so the
    second should use “verifying” and the third should use “forcing”.

[GS] Done.

    — Section 2.3 —

       One way for the server to verify freshness is that to bind the Echo

    Nit: There appears to be an extra word, “that”.

[GS] Done.

       (In most cases, this means that the proxy
       needs to ask the client to repeat the request with a new Echo value).

    Nit: the “.” needs to be inside the parentheses.

[GS] Done.

    — Section 3.3 —

       results in the new message not being part of he old operation.

    Typo: “the old”

[GS] Done.

    — Section 3.4 —

       What constitutes a concluded operation
       depends on that purpose, and is defined there.

    I’m missing the antecedent to “there”.  Where?

[GS] I replaced "there" with "accordingly" and repeated the reference to the applications:
"What constitutes a concluded operation depends on the purpose, and is defined accordingly, see examples in Section 3.5."

       The Request-Tag options MAY be present in request messages that carry
       no Block option (for example, because a Request-Tag unaware proxy
       reassembled them), and MUST be ignored in those.

    I think this should be “may” (or “might”), not “MAY”.  You’re not
    suggesting it as an option to do, but are instead warning about something
    that might happen.

[GS] Changed to:
"Note that Request-Tag options can be present in request messages that carry no Block option
(for example, because a Request-Tag unaware proxy reassembled them),
and MUST be ignored in those."

    — Section 3.5.1 —

       is still possible for a man-in-the-middle to maliciously replace a
       later operation's blocks with an earlier operation's blocks

    Not a requirement here, and I will accept your best judgment:  in the
    spirit of recent discussion on inclusive vs exclusionary language, I ask
    you to consider changing “a man-in-the-middle” to “an on-path attacker”.

[GS] I thought there was a slight difference between "on-path attacker" and "man-in-the-middle”, in that the latter has access to the message flow whereas the former need not have. For example, an on-path attacker may only be able to inject messages. In this case ("replace") the latter would then be more precise. If I'm right then I propose we use available distinctions pending a new dictionary, otherwise I'm fine with changing.

          changed, then the client MUST consider messages sent to _any_
          endpoint address within the new operation's security context.

    This is ambiguous.  I think you mean “to be within”, yes?

[GS] To me, this reads better by replacing "within" with "using":
 "If any future security mechanisms allow a block-wise transfer to continue after an endpoint's details (like the IP address) have changed, then the client MUST consider messages sent to *any* endpoint address using the new operation's security context."
The point here is that a necessary condition for a malicious replacement of blocks to work is that the same security context is used, since otherwise the integrity verification will detect the change. Now, if a future specification allows the same security context to be used more widely, say, even if IP address has changed, then the IP address is not sufficient to determine what message exchanges that needs to be assess as concluded when recycling a Request-Tag value. Does that make more sense?

       o  The client MUST NOT regard a block-wise request operation as
          concluded unless all of the messages the client previously sent in
          the operation have been confirmed by the message integrity
          protection mechanism, or are considered invalid by the server if
          replayed.

    It’s not clear to me how a client can comply with this: how can the client
    possibly know whether the messages it has sent would be considered invalid
    by the server if they were replayed?  Or is there something I’m not
    understanding?

[GS] The size of the replay buffer window may be fixed by the application and known to the client. The window could potentially be set small, e.g. if transported messages are rarely erroneous. If the client receives an integrity protected response (not necessarily related to the operation in question) it could deduce that the replay window have slided past all messages related to the operation in question, and therefore the server would not accept replay of messages of this operation.

While this may not be a common method, it is possible to infer such information and considering this is a "MUST NOT" requirement we wanted to allow for that.

    Honestly, I’m having trouble following the explanations in this section, in
    general, so there’s a reasonable chance that I am missing something

[GS] It is possible to expand more if you think that is necessary. Please let us know.

Thanks
Göran

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 1 Sep 2020 18:40:45 +0200

> [GS] I thought there was a slight difference between "on-path attacker" and "man-in-the-middle”, in that the latter has access to the message flow whereas the former need not have. For example, an…

Oh, so we are getting to have this fun discussion on *this* draft.

A MITM can read, inject, delete, and modify data.

An on-path attacker can read and inject, but not necessarily delete or modify data.

I would not use the latter as a synonym for the former.

The other proposal in https://github.com/ietf/terminology is even more broken: An impersonation attacker doesn’t even have to be on-path.

(See also my comment on https://github.com/ietf/terminology/pull/1, which fell by the wayside in the recent lull on this topic.)

In the mid-2000s, there was an attempt to replace MITM attack by “middleperson attack”.  That utterly failed, a simple Google search says “man-in-the-middle” (54100 hits on dl.acm.org) is overwhelmingly still the term of art and not “middleperson” (31 hits on dl.acm.org).

Wikipedia at least knows about the other established word for MITM, Janus attack https://en.wikipedia.org/w/index.php?title=Janus_attack&redirect=no — not very successful either (9 hits on dl.acm.org).

One word that already has the right semantics and does not require the cultural background of “Janus attack” is “Interposer attack”.  0 hits on dl.acm.org, but has all the right properties.  So in the above we would replace MITM by “interposer”:

>       is still possible for an interposer to maliciously replace a

WFM, even if this is blazing a new trail.

Grüße, Carsten

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Sep 2020 19:13:45 +0000

In this sentence I think on-path attacker works quite well or even better. It already follows from the sentence that the attacker is able to replace one block with another. The attacker in this case does only needs to be able to reorder packets flowing in one direction of the communication.

We could also just use the word attacker, e.g.

"it is still possible for an attacker able to reorder packets on the path from client to server to maliciously replace a later operation's blocks with an earlier operation's blocks."

Cheers,
John

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Date: Tuesday, 1 September 2020 at 18:40
To: Göran Selander <goran.selander=[email-masked]>
Cc: Barry Leiba <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [core] AD review of draft-ietf-core-echo-request-tag-10
Resent from: <[email-masked]>
Resent to: <[email-masked]>, John Mattsson <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Marco Tiloca <[email-masked]>
Resent date: Tuesday, 1 September 2020 at 18:40

    The other proposal in https://protect2.fireeye.com/v1/url?k=8bc8ba21-d57827b9-8bc8faba-861fcb972bfc-afe20b2d89bbd667&q=1&e=406fbb72-b2f0-4844-bd11-3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology is even more broken: An impersonation attacker doesn’t even have to be on-path.

    (See also my comment on https://protect2.fireeye.com/v1/url?k=a110182c-ffa085b4-a11058b7-861fcb972bfc-2890999e614b0870&q=1&e=406fbb72-b2f0-4844-bd11-3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology%2Fpull%2F1, which fell by the wayside in the recent lull on this topic.)

    Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Sep 2020 15:29:04 -0400

John has a good point here, and I support his proposal.

That said, remember: I did say that it's not a big deal and I'm
leaving it to y'all's best judgment.  All I wanted was for you to
consider the issue... not to rehash "fun" discussions from elsewhere.
And whichever way you choose isn't going to block this document.

Barry

---

From: Göran Selander <[email-masked]>
Date: Wed, 2 Sep 2020 12:52:02 +0000

Hi,

As I understand "replace" and Carsten's provided definitions, an on-path attacker does not necessarily have that capability. But I agree with John's proposal and updated the github version accordingly. In the same way I also replaced the only use of "on-path attacker" in the draft with "attacker". The commit is here:

https://github.com/core-wg/echo-request-tag/commit/29969c4

Any other comments on the recent changes? We plan to submit a new version on Friday.

Göran

On 2020-09-01, 21:29, "Barry Leiba" <[email-masked]> wrote:

    Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Sep 2020 08:56:28 -0400

For what it's worth, I just reviewed a routing document that uses the
phrase "an attacker in the middle of the network", which is another
option.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Sep 2020 09:25:45 -0400

Thanks, Göran, for the responses.  I'm leaving only the ones that need
further discussion; consider the rest handled.

> "This document updates RFC7252 with respect to the client Token
> processing requirements, forbidding non-secure reuse of Tokens to
> ensure binding of response to request when CoAP is used with a security
> protocol, "
>
> The rationale to mention "when CoAP is used with a security protocol "
> here is that a layman would expect a binding between response and
> request to hold when CoAP is used with a security protocol (in contrast
> to when CoAP is used without a security protocol, when no binding is
> expected) and would thereby be surprised that the property does not
> automatically hold, e.g., for CoAP with DTLS, but additionally requires
> restricted use of Tokens.

I think that "a security protocol" suffers from the same problem: what
does "security" mean here, and what is "a security protocol".  Again:
if you mean "an encryption protocol", that's clear.  But, for example,
OAuth is a security protocol.  EAP is a security protocol.  DOTS is a
security protocol.  You don't mean those kinds of security protocols.
We use "security" in so many related but different ways that the word
"security" by itself doesn't explain much.

> "Two request messages are said to be "matchable" if they occur between
> the same endpoint pair, have the same code, and the same set of options
> with the following exception: elective NoCacheKey options and options
> involved in block-wise transfer (Block1, Block2 and Request-Tag) need
> not be the same."

Ah, I see the point... and this is why it's important to make list
items parallel.  Now that I get what you mean I can suggest a fix:

NEW
   Two request messages are said to be "matchable" if they occur between
   the same endpoint pair, have the same code, and have the same set of
   options, with the exception that elective NoCacheKey options and
   options involved in block-wise transfer (Block1, Block2 and
   Request-Tag) need not be the same.
END

(The extra "have" is needed in the third list item to make the list
parallel.  Otherwise, the third item lacks the verb that the other two
items each have.)

> see examples in Section 3.5."

That's clear, thanks.  Just please change the comma after
"accordingly" to a semicolon.

>  "If any future security mechanisms allow a block-wise transfer to
> continue after an endpoint's details (like the IP address) have
> changed, then the client MUST consider messages sent to *any* endpoint
> address using the new operation's security context."
>
> The point here is that a necessary condition for a malicious
> replacement of blocks to work is that the same security context is
> used, since otherwise the integrity verification will detect the
> change. Now, if a future specification allows the same security
> context to be used more widely, say, even if IP address has changed,
> then the IP address is not sufficient to determine what message
> exchanges that needs to be assess as concluded when recycling a
> Request-Tag value. Does that make more sense?

I understand the point; thanks.  I still think you need something
other than the single word "within" or "using" to make the grammar
work right... it's just a small thing.  So tweaking the new text:

NEW
If any future security mechanisms allow a block-wise transfer
to continue after an endpoint's details (such as the IP address)
have changed, then the client MUST consider messages sent to *any*
endpoint address to be using the new operation's security context.
END

Or "as using" also works.  Without something there, one reads
"messages using the new security context" and parses that as a
compound noun... and then says, "must consider them... how?"

> [GS] The size of the replay buffer window may be fixed by the
> application and known to the client. The window could potentially be
> set small, e.g. if transported messages are rarely erroneous. If the
> client receives an integrity protected response (not necessarily
> related to the operation in question) it could deduce that the replay
> window have slided past all messages related to the operation in
> question, and therefore the server would not accept replay of messages
> of this operation.

Ah, I see; thanks.
So maybe putting it in active voice would make it better?:

NEW
o  The client MUST NOT regard a block-wise request operation as
concluded unless all of the messages the client previously sent in the
operation have been confirmed by the message integrity protection
mechanism, or the client can determine that the server would not
consider the messages to be valid if they were replayed.
END

Barry

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 2 Sep 2020 13:37:37 +0000

Hi!

The notion of defining, labelling and discussing the distinction between attackers who can read, inject, delete, and modify data vs. read and inject, but not necessarily delete on modify data, seems like helpful precision.  Thanks for doing it.  

To make a few general comments ...

For me, "on-path" speaks to where an attacker is located topologically, not what capabilities the attacker will _always_ have -- there can be mitigating factors based on the particular details of the protocol or operational configurations.  I'd also say the same for "MiTM" too.  Furthermore, I don’t think that in the abstract that we have a an commonly accepted definition precise enough with MiTM vs. on-path attacker to the degree  that we can make the distinction that the latter (again in the abstract) has less capabilities than the former (or vice versa).  

In terms of prior definitions, consulting Section 3.5 of RFC3552:

3.5. On-path versus off-path

   In order for a datagram to be transmitted from one host to another,
   it generally must traverse some set of intermediate links and
   gateways.  Such gateways are naturally able to read, modify, or
   remove any datagram transmitted along that path.  This makes it much
   easier to mount a wide variety of attacks if you are on-path.

This suggests that an "on-path attacker" can indeed read, modify and remove datagrams.

Back to this specific document, enumerating the specific collection of attacker capabilities _with_ a description of where this adversary would need to be topologically seems like the right editorial approach.  Again, thanks for trying to be so clear.

Regards,
Roman 

> From: core <[email-masked]> On Behalf Of Barry Leiba
> Sent: Wednesday, September 2, 2020 8:56 AM
> To: Göran Selander <[email-masked]>
> Cc: [email-masked]; [email-masked]
> For what it's worth, I just reviewed a routing document that uses the phrase
> "an attacker in the middle of the network", which is another option.
> 
> Barry
> 
> > As I understand "replace" and Carsten's provided definitions, an on-path
> attacker does not necessarily have that capability. But I agree with John's
> proposal and updated the github version accordingly. In the same way I also
> replaced the only use of "on-path attacker" in the draft with "attacker". The
> commit is here:
> >
> >     > In this sentence I think on-path attacker works quite well or even better.
> It already follows from the sentence that the attacker is able to replace one
> block with another. The attacker in this case does only needs to be able to
> reorder packets flowing in one direction of the communication.
> >     >
> >     > "it is still possible for an attacker able to reorder packets on the path
> from client to server to maliciously replace a later operation's blocks with an
> earlier operation's blocks."
> >     >
> >     > Cheers,
> >     > John
> >     >
> >     > Cc: Barry Leiba <[email-masked]>, "draft-ietf-core-echo-
> [email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> >     > Resent to: <[email-masked]>, John Mattsson
> <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>, Marco Tiloca
> <[email-masked]>
> >     >     On 2020-09-01, at 16:19, Göran Selander
> <goran.selander=[email-masked]> wrote:
> >     >     >
> >     >     >
> >     >     >    — Section 3.5.1 —
> >     >     >
> >     >     > [GS] I thought there was a slight difference between "on-path
> attacker" and "man-in-the-middle”, in that the latter has access to the message
> flow whereas the former need not have. For example, an on-path attacker may
> only be able to inject messages. In this case ("replace") the latter would then be
> more precise. If I'm right then I propose we use available distinctions pending a
> new dictionary, otherwise I'm fine with changing.
> >     >
> >     >     The other proposal in
> https://protect2.fireeye.com/v1/url?k=8bc8ba21-d57827b9-8bc8faba-
> 861fcb972bfc-afe20b2d89bbd667&q=1&e=406fbb72-b2f0-4844-bd11-
> 3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology is even
> more broken: An impersonation attacker doesn’t even have to be on-path.
> >     >
> >     >     (See also my comment on
> https://protect2.fireeye.com/v1/url?k=a110182c-ffa085b4-a11058b7-
> 861fcb972bfc-2890999e614b0870&q=1&e=406fbb72-b2f0-4844-bd11-
> 3ff570edaf0f&u=https%3A%2F%2Fgithub.com%2Fietf%2Fterminology%2Fpull
> %2F1, which fell by the wayside in the recent lull on this topic.)
> >     >
> >     >     In the mid-2000s, there was an attempt to replace MITM attack by
> “middleperson attack”.  That utterly failed, a simple Google search says “man-
> in-the-middle” (54100 hits on dl.acm.org) is overwhelmingly still the term of
> art and not “middleperson” (31 hits on dl.acm.org).
> >     >
> >     >     Wikipedia at least knows about the other established word for MITM,
> Janus attack
> https://en.wikipedia.org/w/index.php?title=Janus_attack&redirect=no — not
> very successful either (9 hits on dl.acm.org).
> >     >
> >     >     One word that already has the right semantics and does not require
> the cultural background of “Janus attack” is “Interposer attack”.  0 hits on
> dl.acm.org, but has all the right properties.  So in the above we would replace
> MITM by “interposer”:
> >     >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Göran Selander <[email-masked]>
Date: Wed, 2 Sep 2020 17:47:05 +0000

Hi Roman!

Thanks for your input on location and capability! 

For the arguments presented in this draft I believe that the location of the attacker is not really relevant. Even if some attacks require the attacker to be in a certain location, it is the fact that an attack is possible that is providing the motivation for a required security feature, not where the attacker is located. And since there is no commonly accepted definition precise enough about distinction of capabilities between the different qualified attacker roles,  it seems reasonable to leave out that qualification altogether. This is what we do in the latest version on github [1], where only the capabilities of the attacker are being described. Does this match your expectations? 

Thanks
Göran

[1] Editor's copy: https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-request-tag.html

On 2020-09-02, 15:37, "Roman Danyliw" <[email-masked]> wrote:

    Hi!

    Regards,
    Roman 

    > > https://protect2.fireeye.com/v1/url?k=6db013eb-33008e73-6db05370-861fcb972bfc-c97d000a9303d52e&q=1&e=3671254a-f98c-4bd4-ae74-a74a56c41df5&u=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fecho-request-tag%2Fcommit%2F29969c4
    > >

---

From: Göran Selander <[email-masked]>
Date: Thu, 3 Sep 2020 07:59:07 +0000

Hi Barry, 

Thanks for further explanations, more comments below. 

I restructured the mail, the two open items first and the closed items at the end (which are resloved in this commit:
https://github.com/core-wg/echo-request-tag/commit/afb9afd)

On 2020-09-02, 15:26, "Barry Leiba" <[email-masked]> wrote:

OPEN ITEM 1

[GS] OK, I see. You read "CoAP is used with a security protocol" as any combination of CoAP and a security protocol, whereas the intention is 
"communication security for CoAP messages is provided by a security protocol", which typically means CoAP with DTLS, TLS or OSCORE, but the same problem statement is relevant with e.g. IPsec, or some link layer providing integrity protection.

We may have a completely different formulation of this text (see below), which appears in the abstract, but there are a number of other occurrences of "security protocol" in the draft where we do need to talk about the protocol providing communication security for CoAP messages, for example:

"CoAP server receiving a request is in general not able to verify when the request was sent by the CoAP client. This remains true even if the request was protected with a security protocol, such as DTLS."

"This remains true even when CoAP is used together with a security protocol such as DTLS or OSCORE,"

"If used with a security protocol not providing bindings between requests and responses (e.g. DTLS and TLS) Token reuse may result in situations where a client matches a response to the wrong request."

"The use of a sequence number is therefore recommended when CoAP is used with a security protocol that does not provide bindings between requests and responses such as DTLS or TLS."

"The security provided by the Echo and Request-Tag options depends on the security protocol used."

Do you think the same problem apply also to these sentences?

Two proposals:

A. We change "used" to "protected"
"CoAP messages are protected with a security protocol"

B. For the abstract, an alternative is to negate and turn "prevent" into "ensure":

OLD
This document updates RFC7252 with respect to the client Token processing requirements, forbidding non-secure reuse of Tokens to ensure binding of response to request when CoAP is used with a security protocol, 
and with respect to amplification mitigation, where the use of Echo is now recommended.
NEW
This document updates RFC7252 with respect to the client Token processing requirements, to make sure that Tokens are not used in a way  that responses risk being associated with the wrong request, 
and with respect to amplification mitigation, where the use of Echo is now recommended.

Is that better?

OPEN ITEM 2

    NEW

[GS] The explanation for how to consider is in the text preceding this excerpt, so I maybe we need to involve that to make this more clear? For example like this:

OLD
* The client MUST NOT recycle a request tag in a new operation unless the previous operation matchable to the new one has concluded.

If any future security mechanisms allow a block-wise transfer to continue after an endpoint's details (like the IP address) have changed, then  the client MUST consider messages sent to *any* endpoint address using the new operation's security context.

NEW
* The client MUST NOT recycle a request tag in a new operation unless the previous operation matchable to the new one has concluded.

If any future security mechanisms allow a block-wise transfer to continue after an endpoint's details (like the IP address) have changed, then  when assessing matchable operations for the purpose of recycling a request tag the client MUST consider messages sent to *any* endpoint address using the new operation's security context.
END

So, this is about deciding whether a particular request tag can be used in a new operation by considering all messages having used the same security context as will be used in the new operation, and make sure that they are concluded, including those where endpoint details have changed (like the IP address)

Does that make more sense? Can it be formulated better?

CLOSED ITEMS

    NEW

[GS] Thanks for explaining! Fixed.

[GS] Done.

    Ah, I see; thanks.

    NEW

[GS] Fixed.

Göran

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 4 Sep 2020 10:04:58 +0200

Hello Göran,

thanks for handling the comments.

On the topics in this sub-thread, I'm happy with all the changes, and

> > by the server if they were replayed?  Or is there something I’m not

In OSCORE, the size (or style) of the replay window *is* fixed for each
security context (and where protocols for establishing an OSCORE context
lack the terminology to express it, defaults to 32 messages). That was
added precisely for this reason.

I've noted that there are a few points in the original mail that have
not been taken up, I'm just going through them and will follow up
shortly (as I don't suppose they fall under the "consider the rest
handled").

Kind regards
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 4 Sep 2020 13:26:14 +0200

Hello Barry,

thanks for all your comments.

Some points went unhandled due to a very curious glitch that had your
mail truncated mid-body when it went through the draft mail forwarder but not
when it went through the list; here's addressing the tail, grouped by
"done", "explained" and "better answered by Göran or John":

Done
=====

> Nit: [various]

Thanks, fixed.

>    The Request-Tag option is repeatable because this easily allows
>    stateless proxies to "chain" their origin address.  They can perform
>    the steps of Section 3.5.3 without the need to create an option value
>    that is the concatenation of the received option and their own value,
>    and can simply add a new Request-Tag option unconditionally.
> 
> I don’t know what ‘“chain” their origin address’ means, and I don’t know
> what ‘their own value’ means.  Can you clarify this?

Yes that's hard to parse without the mindset I was in when writing it;
replaced with

  [...] because this easily allows several cascaded stateless proxies to each put in an
  origin address.

> — Section 3.8 —
> 
>    The threat model here is not an
>    attacker (because the response is made sure to belong to the current
>    request by the security layer), but blocks in the client's cache.
> 
> I don’t understand “The threat model is blocks in the client’s cache.”  I
> think this needs some rewording to explain better what you mean.

Clarified to:

  The threat model here does not depend on an attacker: a client can
  construct a wrong representation by assembling it from blocks from
  different resource states.  That can happen when a resource is
  modified during a transfer, or when some blocks are still valid in the
  client's cache.

> — Section 4.1 —
> 
>    The wrong response may be an old response for the same
>    resource or for a completely different resource
> 
> Are you referring to an old response for a completely different resource
> (which is what this says as written), or to any response for a completely
> different resource (which is what I think you mean)?  If the latter, it
> should say, “...or a response for a completely different resource”.

It does now.

>    A straightforward mitigation is to mandate clients to not reuse
>    Tokens until the traffic keys have been replaced.  One easy way to
>    accomplish this is to implement the Token as a counter starting at
>    zero for each new or rekeyed secure connection.
> 
> This is essentially repeated in the next section.  Can you avoid that,
> probably by rewording this to say that the next section privides a
> mitigation?

That indeed sounds like the way to go for that paragraph (although we
might just drop it as well); changed to:

  A straightforward mitigation is to mandate clients to not reuse
  Tokens until the traffic keys have been replaced. The following
  section formalizes that.

> — Section 4.2 —
> 
>    One easy way to accomplish this is to implement the Token (or part of
>    the Token) as a sequence number starting at zero for each new or
>    rekeyed secure connection, this approach SHOULD be followed.
> 
> This is not a proper sentence: I think it’s two sentences splicd together,
> but it might be that it needs rewording instead.

I think it works now that the comma is replaced with a full stop, and
the former sentence is put on a paragraph of its own to clearly separate
what is mandated and what is recommended.

> — Section 5 —
> 
>    As each pseudoranom number must only be used once,
>    an implementation need to get a new truly random seed after reboot,
>    or continously store state in nonvolatile memory, see ([RFC8613],
>    Appendix B.1.1) for issues and solution approaches for writing to
>    nonvolatile memory.
> 
> And this also looks like two sentences spliced together.

Yes, changed to two sentences.

>    They MUST only be
>    used when the request Echo values are integrity protected.
> 
> I think this is a tricky way to word it, and that it invites
> misunderstanding.  I suggest that it might be better said as, “They MUST
> NOT be used unless the request Echo values are integrity protected.”

Agreed and taken verbatim.

> — Section 5.1 —
> 
>    Reusing Tokens in a way so that responses are guaranteed to not be
>    associated with the wrong request is not trivial as on-path attackers
>    may block, delay, and reorder messages, requests may be sent to
>    several servers, and servers may process requests in any order and
>    send many responses to the same request.
> 
> This is a complicated sentence and it has a lot of cascaded negatives.
> Please try rewording it, and consider splitting it up.  One way is to start
> with “On-path” to the end of the sentence, and then have another sentence
> that says, “That makes it non-trivial to reuse tokens...”

I've removed the "to several servers" part as it doesn't really
contribute (it can, but not using security protocols other than OSCORE),
and reordered it to "it's difficult: this already happens regularly. an
attacker may do that. therefore...". Now reads as:

  Reusing Tokens in a way so that responses are guaranteed to not be
  associated with the wrong request is not trivial: The server may
  process requests in any order, and send multiple responses to the same
  request. An attacker may block, delay, and reorder messages. The use
  of a sequence number is therefore recommended when CoAP is used with a
  security protocol that does not provide bindings between requests and
  responses such as DTLS or TLS.

>    Unencrypted timestamps MAY
>    reveal information about the server
> 
> This needs to be “may” (or “could”), as it’s a statement, not a directive.

Agreed, changed to "could".

>    Like HTTP cookies, the Echo option could potentially be abused as a
>    tracking mechanism to link to different requests to the same client.
> 
> I can’t follow this sentence, particularly the part with the word “to”
> repeated three times.  Please reword it.

Reworded to:

  [...] the Echo option could potentially be abused as a tracking
  mechanism that identifies a client across requests.

>    Clients only send Echo to the same
>    server from which they were received.
> 
> The only possible antecedent to “they” here is “clients”, which is clearly
> wrong: you mean “Echo”.  So this needs rewording.  Maybe use “Echo
> options”, or something like that.

Changed:

  Clients send Echo values to the same server from which the values were
  received.

> — Section 8.2 —
> I’m having a hard time deciding whether some of these references should be
> normative, especially 8613.  Please give these another review with that in
> mind and see if you think any of them should be moved.  You can find some
> guidance in the relevant IESG Statement <
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/>,
> keeping in mind the general rule that something that needs to be fully
> understood should be normative, while something that just adds extra
> enlightenment can be informative.

Most of the document can be applied with either DTLS or OSCORE. But
given that "[e]ven references that are relevant only for optional
features must be classified as normative",

Given that we specify behaviors for token handling over transport
security (mentioning rekeyings) and body protection for OSCORE, after
reading the guidance I'm promoting RFC 6347 DTLS and RFC8613 OSCORE to
normative.

(CoAP-over-TLS can stay informative as it's only used in "all is fine,
move on" context).

>    A server MAY want to encrypt its timestamps
> 
> I suggest that a server doesn’t “want” to do anything.  Perhaps it’s better
> to say, “It might be important to encrypt a server’s timestamps (see
> Section 6)”.

As much as I'd enjoy discussing the concept of "the server" as an
overarching entity encompassing its operator, implementer and
implementation, I'm taking up the suggestion as not to distract the
reader.

>    repeated transmission failure; in DTLS, if no packages are lost)
> 
> Should that be “packets”?

Yes, fixed.

No changes needed IMO
=====================

>    In those situations, no message has any Request-Tag option set, and
>    that can be recycled indefinitely.
> 
> I don’t understand what is being “recycled” if you’re not using he
> Request-Tag option (also applies to the subsequent sentence).

There's an explicit note where request tag recycling is introduced that
for the purpose of recycling, the absence of an option is just another
"value" for that purpose.

>    In draft versions of this document, the Request-Tag option used to be
>    critical and unsafe to forward.  That design was based on an
>    erroneous understanding of which blocks could be composed according
>    to [RFC7959].
> 
> It makes sense that this was here during working group discussion.  Is
> there value in having it in the published RFC?  If so, why?

It's included that way (and not as a to-be-removed-before-publication)
because seeing that there used to be now-considered-wrong
interpretations around is valuable information to readers. (Not that I'd
insist, but maybe it makes sense that way)

> — Appendix A —
> 
>    security against an attacker guessing echo values is given by s = bit
>    length of r - log2(n).
> 
> What is “r”?

Added a "called r" to the introduction of "a (pseudo-)random byte
string" at the start of the paragraph.

Deferred to the other authors
=============================

>    Unless a counting Echo value is used, the Echo
>    option value MUST contain 32 (pseudo-)random bits that are not
>    predictable for any other party than the server, and SHOULD contain
>    64 (pseudo-)random bits.
> 
> What’s the reason for not just using MUST for 64 bits and being done with
> it?

I'd suppose that it's to allow for applications with well controlled
power cycles and Echo value changes to reduce their message sizes --
Göran, could you say a bit more here?

>    Servers MAY use the time since reboot measured in some unit of time.
> 
> For what?  It’s not clear to me what this refers to.

John, Göran, could this be a leftover from the later changes around
server / wall time?

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Göran Selander <[email-masked]>
Date: Fri, 4 Sep 2020 12:12:48 +0000

On 2020-09-04, 13:26, "Christian Amsüss" <[email-masked]> wrote:

    Hello Barry,

    Some points went unhandled due to a very curious glitch that had your
    mail truncated mid-body when it went through the draft mail forwarder but not
    when it went through the list; 

[GS] So, the mail from Barry dated Tue, 04 August 2020 03:16 UTC in my mailbox (and in other's) ends with

"Honestly, I’m having trouble following the explanations in this section, in
general, so there’s a reasonable chance that I am missing something."

which seemed to me at the time like a reasonable ending of a review mail, but there was more:
https://mailarchive.ietf.org/arch/msg/core/B6hwBECcKq5QTBV4nEr5sGnIJHA/

Thanks, Christian, for detecting and responding to the remaining comments!

Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 10 Sep 2020 09:46:39 +0000

Hi Barry,

Here are responses to the two comments of your review which Christian redirected.

[GS] The recommendation of 64 bits is motivated by the comparison with 64 bits MAC in the beginning of this paragraph, but the requirements of 32 bits depends on application so we replaced that with an application-dependent requirement to mitigate against reuse, see:
https://github.com/core-wg/echo-request-tag/pull/61/commits/d8ba0f5

[GS] This text is intended to be read in context of other text previously in this section. I tried to rephrase to make it more clear, see:
https://github.com/core-wg/echo-request-tag/pull/61/commits/4d3ca93

Both these commits are part of PR#61 which makes additional clarifications on Echo, the current changes are here:
https://github.com/core-wg/echo-request-tag/pull/61/files

Please let us know if you have any further comments.

Thanks,
Göran

    Hello Barry,

    Done
    =====

    Thanks, fixed.

    Clarified to:

    It does now.

    Reworded to:

    Changed:

    Yes, fixed.

    No changes needed IMO
    =====================

    Kind regards
    Christian