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

[Jim Schaad <[e-mail]>]

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

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.  

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


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

I would not recommend an integrity protected internal clock as a good method.  I would only recommend an encrypted wall clock value.

Jim


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