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

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

Hi Jim,

Thanks for comments, responses to the remaining comments below. The CoRE WG Github is updated.

On 2018-10-12, 00:17, "Jim Schaad" <[e-mail]> wrote:

    I have read this document and I have the following comments:
    
    * Introduction - you say several enhancements, but there are only two new
    options.  What are the other enhancements?
    
GS: "several" removed. A number of applications are listed, e.g. in section 2.3, but no need to go into that here.

    * Introduction - The sentence "This document specifies ..." this sentence
    says you are doing two thing and then there are two sentences.  I think you
    can tighten this up with a colon following "Request-Tag option:", delete the
    rest of this sentence and keep the next two sentences.

GS: Done.
    
    * Section 1.1 para 1 - I think you should provide a couple of reasons why
    this is not a suitable solution.  I can think of multiple different reasons:
    a) The amount of traffic and resources required - which may not be a problem
    with both sides just one. b) Going through proxies where the freshness gets
    lost as a client renegotiation does not get to the server and a proxy
    renegotiation says nothing about the client. c) Amount of time involved.

GS: Motivation included.

    * Section 1.3 - I am a bit lost in this section.  When doing matches between
    a request and a response I am matching up the message id and the token if it
    exists.  You need some additional text in here to describe why it is that
    you are talking about something interesting to me.  
    
GS: Text updated and example included.

    * Section 2.1 - Something seems to be odd.  I don't think the RFC editor
    note is correct.  I think a paragraph must have disappeared

GS: Paragraph added.
    
    * Section 2.2 - I don't think if you reboot that you have lost time
    synchronization, rather you have lost time continuity.  That said the
    current term may be state of art and thus correct.  To me synchronization
    implies a minimum of two parties.

GS:  "continuity" seems to be the right term here. Changed in 3 places.
    
    * Section 2.2 - I think that you need to make some arguments about what
    happens if an Echo option value is provided to multiple entities either
    because the server will just re-use it's current value for some period of
    time after creation (valid for time m and used for time m/3) or because a
    proxy provides the same answer to two different clients.   Note that this
    seems to be not recommended in item 2 of section 2.3
    
GS:  Added clarification: "The server MAY include the same Echo option value in several different responses and to different clients."
Also added example of this, now sub-bullet of item 1 of section 2.3.


    * Section 2.3 - Item 4 - I don't understand what is going on here.  I am not
    sure what the device is joining as (a responder?)  Is the sync done by two
    unicast messages or a unicast followed by a multicast?  

GS: Restructured section 2.3. A sub-bullet of item 2 now describes a new device joining a group and synchronizing state or time with a client, allowing synchronization either with multicast or unicast. I hope that is more clear.
    
    * Section 2.3 - Item 5 - I am not sure that this is a reasonable answer for
    having a proxy sitting there.  I could easily be wrong and should probably
    spend some time thinking about how this does/does not work.

GS: This is now item 3. There is no intention to use a proxy here, so I don't understand the question. Please elaborate.
  
---
  
    * Section 5 - I have not seen a justification for this anyplace.
    
GS: Included reference to section 1.3. (Also reference to section 1.1 in section 2, and to section 1.2 in section 3)

    * Section 7 - para 1 - What is the problem w/ using an encrypted wall clock
    time for a timestamp?  These text appears to say that this is a bad idea but
    the issues seem to be with using unencrypted items not with the wall clock.
    The next sentence makes more sense about why not to use one.  
    
GS: With encrypted wall clock we typically need to store or transport the IV, 
in which case the random value method is not worse in message size and server state.

    * Appendix A - I would think that if you send a 32-bit timestamp in the
    clear w/ an integrity value that one can start making guesses about some of
    the same privacy problems as the use of a wall clock.  Knowing when a server
    was last reset could tell you the same things.

GS: Added reference to the new privacy considerations section.


Any further comments are much welcome.

Göran




On 2018-10-17, 16:18, "Christian M. Amsüss" <[e-mail]> wrote:

    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