Discussion:
[core] Request-Tag follow-up from WG meeting
Christian Amsüss
2017-03-30 09:40:29 UTC
Permalink
Hello working group,

this is a follow-up on the Request-Tag draft[1] that Göran presented in
the core WG meeting on Tuesday (thanks for standing in, and sorry for
the trouble).

I'd like to clarify two things that came up in the questions afterwards:

a. This is option would only be used in where Block1 option is set by
the client.

b. Yes, the window of attack *is* very small, and the examples are
contrived, but nevertheless, that keeps OSCOAP from claiming security
for bodies.

c. Like ETag, this is only secure as long as the chosen tag is unique
within the (security context, URI) pair.


Questions I'd like to ask the working group are:

1. Do you have any better idea on how to protect Block1 bodies?

2. Request-Tag technically allows distinguishing simultaneous legitimate
Block1 operations. Do you see reasons not to allow that?

(It would greatly help proxies, especially those forwarding OSCOAP,
because without, they have to either spool request bodies or deny
forwarding to other clients while waiting for data).

3. DTLS users, would you use that?

Would DTLS provide any guarantees on old packages not being
acceptable any more after some other package has been sent or
acknowledged, epochs maybe? (Short of that, the option would incur 1
+ ceil(log256(number of Block1 operations done)) bytes of options
overhead; that approximation resets to 0 whenever the client is sure
the server won't accept old messages any more.)

4. Is this something that can become a WG document?

Should the "how to use this to protect bodies" (currently "For
inclusion in OSCOAP") part be in object-security or here?

Please give feedback.

Thanks
Christian

[1]: https://tools.ietf.org/html/draft-amsuess-core-request-tag-00
--
Christian Amsüss | Energy Harvesting Solutions GmbH
founder, system architect | headquarter:
mailto:***@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/
| ATU68476614
Loading...