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

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

Hi Jim,

See below.

Please note that the "Editor's copy" does not build to the latest version (perhaps someone with admin rights could look at this __) so look at the .md file instead.
https://github.com/core-wg/echo-request-tag

                                                                                                                                                                                             
On 2018-10-19, 01:02, "Jim Schaad" <[e-mail]> wrote:

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


GS: Echo applies for the hop-by-hop setting as well. Reading item 3 of section 2.3 with the proxy in the role of server:

"3. A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of [RFC7252] (where an attacker would put a victim’s address in the source address of a CoAP request). For this purpose, the server MAY ask a client to Echo its request to verify its source address. This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server."

So in this case the server needs to mitigate amplification from the Proxy, and the Proxy, in turn, needs to mitigate amplification attacks from C1 and C2. 
Does that make sense?

    > 
    > ---
    > 
    >     * 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.
    
GS:  I didn't understand this last comment. I agree that unencrypted time would leak information - but that was the content of your comment following this one (below). The question you posed and I tried to answer was: why not encrypted timestamp? And a better answer is perhaps: encrypted time stamp is fine, but we considered it more difficult to specify and doesn't seem to have any advantage compared to the examples of Appendix A. In particular, the random value method does not have to leak any information at all. Is it more clear now? I will mention encrypted timestamp in Appendix A.
    
Göran


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