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

From: Jim Schaad <[email-masked]>
Date: Thu, 11 Oct 2018 15:17:12 -0700

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?

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

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

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

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

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

* 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

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

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

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

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

* Section 3.2 - the first paragraph does not scan.  I am not sure what it
says as it seems to be contradictory.

* Section 3.2 - para 2 - The example sentence looks odd.  Do you mean it can
have a cached response not a free response?

* Section 3.2 - para "especially" - I find the first sentence very hard to
understand.

* Section 3.3 - last para - how do you recycle something that is absent?  I
think the last clause needs examining.

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

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

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

* Section 5 - I have not seen a justification for this anyplace.

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

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

Jim

s/bock-wise/block-wise/
s/incomplte/incomplete/
s/woud/would/

---

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 17 Oct 2018 16:18:14 +0200

Hello Jim,

thanks for your review; we're working it into an updated document for
WGLC.

Responding to the comments related to Request-Tag:

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

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

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

> 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

That paragraph has become obsolete with the presence of core-stateless
anyway and was replaced with a reference there later in the proxy
application.

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

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

> 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 - Please keep the section for justification of Request-Tag

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

---

From: Göran Selander <[email-masked]>
Date: Thu, 18 Oct 2018 21:32:11 +0000

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" <[email-masked]> wrote:

    
GS: "several" removed. A number of applications are listed, e.g. in section 2.3, but no need to go into that here.

GS: Done.

GS: Motivation included.

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.

GS:  "continuity" seems to be the right term here. Changed in 3 places.

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.

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.

GS: This is now item 3. There is no intention to use a proxy here, so I don't understand the question. Please elaborate.
  
---

GS: Included reference to section 1.3. (Also reference to section 1.1 in section 2, and to section 1.2 in section 3)

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.

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" <[email-masked]> wrote:

    Hello Jim,

    

    

    

    

    

    

    

    

    Thanks again
    Christian

---

From: Jim Schaad <[email-masked]>
Date: Thu, 18 Oct 2018 15:50:50 -0700

> -----Original Message-----
> From: Christian M. Amsüss <[email-masked]>
> Sent: Wednesday, October 17, 2018 7:18 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comments on draft-ietf-core-echo-request-tag-02
> 
> Hello Jim,
> 
WGLC.
> > * 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.
> 
beforehand
> that we can remove the paragraph or move the text ourselves
> > * 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.
> 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?:
> 

Yes that reads better

> 
> > * Section 3.2 - para 2 - The example sentence looks odd.  Do you mean
> > it can have a cached response not a free response?
> 
> > * Section 3.2 - para "especially" - I find the first sentence very
> > hard to understand.
> 
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.
> 
> If that does not answer the question, I don't fully understand it, please
help me
> find where we diverge.

Ok - if you say proxies are not there then I have no issues

> 
> > * 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.
> 
transports
> (which it could easily do but is not specified that way); I've replaced
the
> paragraph with a weaker and more hypothetical one.
> 
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.)

That makes sense - It might be better to talk about endpoint addresses then
rather than just using endpoint which corresponds to a server (or client).

> > * Section 3.4.3 - Please keep the section for justification of
> > Request-Tag being repeatable.
> 

Look good

Jim

---

From: Jim Schaad <[email-masked]>
Date: Thu, 18 Oct 2018 16:01:24 -0700

> From: Göran Selander <[email-masked]>
> Sent: Thursday, October 18, 2018 2:32 PM
> GS:  Added clarification: "The server MAY include the same Echo option value
> in several different responses and to different clients."
> 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.
> 
> 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.

> 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

---

From: Göran Selander <[email-masked]>
Date: Fri, 19 Oct 2018 15:43:29 +0000

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

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

    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?

    
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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Oct 2018 10:26:52 -0700

> Sent: Friday, October 19, 2018 8:43 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> 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.
>     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

>     > GS: Included reference to section 1.3. (Also reference to section 1.1 in
> section
>     > 2, and to section 1.2 in section 3)
>     >
>     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

---

From: Göran Selander <[email-masked]>
Date: Sun, 21 Oct 2018 12:45:12 +0000

Hi Jim,

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

    

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

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.

    Client sends request
    Proxy passes on request
    Server says please echo
    
GS: This is the order I was thinking of. I didn't include this example it in the recent update, but perhaps we should?

    

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.

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Oct 2018 13:55:14 +0200

> https://github.com/core-wg/echo-request-tag

I don’t know why, but this repo doesn’t seem to be set up for automatic builds.

You can always build manually by saying

	make ghpages

(Note that there also was a partial github outage [1] since yesterday evening, which may influence whether you can see that something has happened.  This was supposed to be fixed about now, but I haven’t seen the “all clear” yet.)

Grüße, Carsten

[1]: https://blog.github.com/2018-10-21-october21-incident-report/