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

[Göran Selander <[e-mail]>]

Hi Barry,

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

    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?

[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


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


[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


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

    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