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

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

Hi Jim,

Some replies inline. The .md file in core-wg/echo-request-tag is updated.

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

    > -----Original Message-----
    > From: Göran Selander <[e-mail]>
    > Sent: Friday, October 19, 2018 8:43 AM
    > To: Jim Schaad <[e-mail]>; [e-mail]
    > Cc: [e-mail]; [e-mail]
    > Subject: Re: Comments on draft-ietf-core-echo-request-tag-02
    > 
    > 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?
    
    Not really.  What you are saying is that the proxy would reject a message w/ a request for an echo.  This would be satisfied by the client resending the request.  The server would then reject the message w/ a request for an echo and the client would then need to resend the request a second time.

GS: No, the order I had in mind is the one you sketch below.

    If the client had an encrypted message that it sent the first time which was rejected, then it needs to end that echo externally but the second echo would be sent inside of the encrypted message.  

GS: Echo may be Inner or Outer and are independent, I see no reason to mix them. If the server receives an OSCORE request that verifies but maybe isn't fresh, it can reject with an Inner Echo, and the OSCORE client needs to respond with an Inner Echo. If the server uses an outer Echo to verify the reachability of the client, then the client should respond with an outer Echo. In this case the message may be unprotected or only hop-by-hop with e.g. DTLS, which means that intermediary nodes may also need to take responsibility for ensuring reachability of requesting device.

    You are also assuming that the proxy would know it is going to be a large response before it sends the request to the server while it would not know that until it gets the response from the server so the order of events would be
    
    Client sends request
    Proxy passes on request
    Server says please echo
    Client sends request with echo
    Server replies
    Proxy caches result
    Proxy says please echo
    Client sends request with new echo
    Server replies
    
GS: This is the order I was thinking of. I didn't include this example it in the recent update, but perhaps we should?

    
    > 
    >     >
    >     > ---
    >     >
    >     >     * 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.
    
    My problem is that the text says something that I don't agree with.  It says:
    
    Servers SHOULD NOT use wall clock time
       for timestamps, as wall clock time is not monotonic, may reveal that
       the server will accept expired certificates, or reveal the server's
       location.
    
    If you are using encrypted wall clock time the only possible issue is that the wall clock may not be monotonic.  The second two items are not correct as the value of time cannot be seen.   In appendix A, you are suggesting an integrity protected time, but that is revealing information because the time is in the clear so the last two items might have some relevance (although I kind of doubt it unless you know that all of the devices are started up at 9 am every morning).
    
GS: Yes, there were too many statements combined here. I kept "not monotonic" in the security considerations and have "reveal location" and "accept expired certificates" in the privacy considerations.

    I would not recommend an integrity protected internal clock as a good method.  I would only recommend an encrypted wall clock value.
    
GS: I changed the recommendation to generally recommend the random value based method ("1. List of Cached Random Values and Timestamps.") as this is very simple to implement. 
The integrity protected time stamp is also recommended but only when Echo is encrypted. I also mention the encrypted timestamp but do not propose a mechanism. If you have a simple concrete proposal we could include that as well. 

Göran