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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Göran Selander <[e-mail]>
> Sent: Thursday, October 18, 2018 2:32 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: Comments on draft-ietf-core-echo-request-tag-02
> 
> 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.


Consider the following setup

C1 -----------|
                 Proxy  ----------- Server
C2 -----------|

C1 sends a request to server via the proxy
Server responds w/ request w/ echo
C1 responds w/ request + echo
C2 sends request to server

Since the server thinks the proxy is just fine - it got a response w/ its echo.  Then the server will think that C2 is also ok so will not do any of the amplification mitigation work of asking for a repeat w/ echo value.

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

Yes, but the same issue exist w/ a time since reboot clock.  If you use this value unencrypted you are heavily leaking information.

Jim


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