* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #365 (closed editorial: incorporated)

Opened 2 years ago

Last modified 2 years ago

Conditional Request Security Considerations

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 20
Component: p4-conditional Severity: In WG Last Call
Keywords: Cc:
Origin: http://www.ietf.org/mail-archive/web/secdir/current/msg03268.html

Description

[ from the secdir review]

Security Considerations (section 6)

Section 6 refers to the security considerations of part 1 and states that the security considerations are the same as for HTTP in general. IMO that is a bit too easy, for example throughout the text there is discussion about clock synchronization, evaluation of weak conditionals, hashes etc. All of those can lead to the client having a "wrong" view of the resource. I would expect some discussion as to what that could mean and what measures could be taken to avoid that.

Also, in part 1, security considerations 8.5 there is some discussion about MitM attacks and evil proxies, and the general statement is made that proxies should not be trusted anymore than the person who operates it. Whereas it is true that everyone in the path can change the transmitted information at will, I could imagine that with ETags one could actually implement some rsort of integrity protection by using ETags that are signed hashes of the content that is transfered.... thinking out loud... anyway, my bottom line is that I am not sure that the security properties of the system as a whole don't change by introducing conditionals.

  • - 2.1, p5, weak vs strong, 4th paragraph

"A cryptographic hash function", which one? I think you need to state at least that you should choose one that is collusion resistant (and this should probably go into the security considerations)

  • - 2.3.1 p 9, generation

same discussion as in 2.1 about collission resistant hashes

Change History

comment:1 Changed 2 years ago by julian.reschke@gmx.de

  • Origin set to http://www.ietf.org/mail-archive/web/secdir/current/msg03268.html

comment:2 Changed 2 years ago by fielding@gbiv.com

From [1801]:

Add a paragraph about validators to security section and refer to collision-resistant hash instead of cryptographic hash. Addresses #365

comment:3 Changed 2 years ago by fielding@gbiv.com

  • Status changed from new to closed
  • Type changed from design to editorial
  • Resolution set to incorporated
  • Milestone changed from unassigned to 20
Note: See TracTickets for help on using tickets.