Re: [core] Comments on draft-ietf-core-echo-request-tag-02

[Christian M. Amsüss <[e-mail]>]

Hello Jim,

thanks for your review; we're working it into an updated document for
WGLC.

Responding to the comments related to Request-Tag:

On Thu, Oct 11, 2018 at 03:17:12PM -0700, Jim Schaad wrote:
> * Section 3.1 - The note to the RFC editor has me confused.  Firstly, I am
> not sure why it should be moved rather than just staying here.  

Updated. I hope that the process of submission will be clear enough
beforehand that we can remove the paragraph or move the text ourselves
-- if (as I expect) OSCORE enters AUTH48 before we submit ERT to the RFC
editor, that text will be gone by then.

> * Section 3.1 - I think that the value of Request-Tag is potentially going
> to be different depending on if it is in the inside rather than the outside.
> You may be doing two different block transfers and each needs its own value.

Updated to explicitly state that those values are independent because
they relate to an inner or outer blockwise transfer.

> * Section 3.2 - the first paragraph does not scan.  I am not sure what it
> says as it seems to be contradictory.

That paragraph assumed a very particular implementation method for
servers (that unknown options are processed in bulk before known
options); does this re-wording read better to you?:

  The Request-Tag option does not require any particular processing on
  the server side outside of the processing already necessary for any
  unknown elective proxy-safe cache-key option: The option varies the
  properties that distinguish blockwise operations (which includes all
  options except elective NoCacheKey and except Block1/2), and thus the
  server can not treat messages with a different list of Request-Tag
  options as belonging to the same operation.

> * Section 3.2 - para 2 - The example sentence looks odd.  Do you mean it can
> have a cached response not a free response?

That was worded confusingly and is now changed.

> * Section 3.2 - para "especially" - I find the first sentence very hard to
> understand.

That paragraph has become obsolete with the presence of core-stateless
anyway and was replaced with a reference there later in the proxy
application.

> * Section 3.3 - last para - how do you recycle something that is absent?  I
> think the last clause needs examining.

Added a sentence on absent Request-Tag options being a value of its
own, explaining why that can be recycled just as well.

> * Section 3.4.1 - Item 2 - how is a client supposed to be able to know this
> if the proxy in the middle just passes it through w/o changing it?  Two
> different clients could end up with the same Request-Tag.  One would hope
> that they would have different tokens because of the proxy however.

The whole 3.4.1 is, as per item 1, only applicable to blockwise
operations split into end-to-end protected individual exchanges.

(Ie. DTLS w/o proxies, or inner blockwise in OSCORE).

If that does not answer the question, I don't fully understand it,
please help me find where we diverge.

> * Section 3.4.1 - This seems backwards.  I thought that OSCORE was tightly
> bound to the end point, but this paragraph says it is not.

That was my idea of OSCORE inner-blockwise being allowed to jump
transports (which it could easily do but is not specified that way);
I've replaced the paragraph with a weaker and more hypothetical one.

(By "bound to the end point" I meant that whereas a running DTLS session
will only stay alive while IP/port/interface quintuple stays the same,
an OSCORE context can be used even after those endpoint identifiers have
changed.)

> * Section 3.4.3 - You have a "Section TBA" here
>
> * Section 3.4.3 - Please keep the section for justification of Request-Tag
> being repeatable.

Given that we now do groundwork for Stateless which is more directly
applicable, that document is now referenced instead, and left in.


Thanks again
Christian

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