Re: [core] WGLC draft-ietf-core-echo-request-tag-05

[Jim Schaad <[e-mail]>]

I believe that this update (and the prior one) address all of the issues that I had identified.  I still have not managed to identify the vague feeling item so it should be ignored.

I am wondering if someplace there needs to be a statement that all of the request tags much match in order for a match to occur?  This may be default behavior, it is for uri-path, but I don't know if it is always true, for example accept requires only a single match.  May also want a note on duplicates in section 3.4.3 or 3.5

Jim


-----Original Message-----
From: John Mattsson <[e-mail]> 
Sent: Thursday, September 19, 2019 6:20 AM
To: Jim Schaad <[e-mail]>; [e-mail]
Cc: 'core' <[e-mail]>
Subject: Re: WGLC draft-ietf-core-echo-request-tag-05

Thanks Jim!

>11. Section 6 - I am having problems with the idea of a forgery of an 
>Echo option, if the option is visible to an attacker why would they 
>need to forge it?
>
>12. Appendix A - I think we have a different definition of forgery for 
>list item 1.  I would have labeled this as guessing not forgery.  That 
>is probably my security background talking.

I changes "frogery" to "guessing" everwhere. 

>13. Appendix A - point 2 - The security is even higher if encryption 
>rather than integrity is used here.

I added a sentence that "The use of encrypted timestamps in the Echo option increases security, ...."

We thought about this before and at some point we did have an solution example with encryption. But as most uses of Echo will be encrypted anyway DTLS/TLS/OSCORE and encryption requires an nonce, and as a nonce increases overhead we did not feel that the message overhead/complexity/security trade-off was good enough to have as an example and chose to have Integrity Protected Timestamp as an example instead.

Cheers,
John

-----Original Message-----
From: Jim Schaad <[e-mail]>
Date: Thursday, 11 July 2019 at 00:17
To: "[e-mail]" <[e-mail]>
Cc: 'core' <[e-mail]>
Subject: WGLC draft-ietf-core-echo-request-tag-05
Resent from: <[e-mail]>
Resent to: <[e-mail]>, John Mattsson <[e-mail]>, <[e-mail]> Resent date: Thursday, 11 July 2019 at 00:16

    Here are some comments:
    
    1.  The Abstract needs to say that it updates RFC 7252 - and it would be
    nice if it summarized what it updated.
    
    2.  You can clean up the text dealing with core-object-security
    
    3.  In section 2.1 - It is not clear to me why one would use an outer option
    for the echo option.   The inner one would be end-to-end and thus does the
    freshness thing.  What does the outer one do?
    
    4.  In section 2.1 (or section 2.2) - There needs to be some text about
    where the echo options should be reflected in the event that either both
    inner and outer options are returned or just an outer is returned.  Can you
    use an inner w/o security for a new request?  I.e. is the inner echo value
    considered to be a security value?
    
    5.  Not sure if it is permissible for a proxy to modify the request in
    response to a 4.01 with an echo option or not.  Clarification might be
    useful on this topic.  I think I understand the paragraphs about proxies as
    servers.
    
    6.  In section 2.3 - item 1 star 2 - I would think that a server could
    proactively return an echo option even if the request did not come with one.
    Thus  GET - Content w/ echo - PUT w/ echo
    
    7.  In section 2.3 - item 2 - star 2 - s/expect/except/
    
    8.  In section 3 it says that the requests must be integrity protected, but
    in section 3.1 it says that this may be an outer option and is of class E
    not class I.  (And I recognize that it cannot be class I.)  I think that
    section 3 is probably the incorrect one.
    
    9.  I think that section 3.4.1 is missing something, but I have not figure
    out what it is yet.  I'll continue to mull this one over.
    
    10.  Section 3.4.2 - I think that it would be reasonable to highlight that
    two OSCORE blockwise operations meet these conditions as the path is hidden
    by security.
    
    11. Section 6 - I am having problems with the idea of a forgery of an Echo
    option, if the option is visible to an attacker why would they need to forge
    it?
    
    12. Appendix A - I think we have a different definition of forgery for list
    item 1.  I would have labeled this as guessing not forgery.  That is
    probably my security background talking.
    
    13. Appendix A - point 2 - The security is even higher if encryption rather
    than integrity is used here.
    
    jim