Confirmed users
358
edits
Identity/AttachedServices/StorageServerProtocol: Difference between revisions
Jump to navigation
Jump to search
Identity/AttachedServices/StorageServerProtocol (view source)
Revision as of 23:18, 15 May 2013
, 15 May 2013no edit summary
No edit summary |
No edit summary |
||
| Line 234: | Line 234: | ||
* Is json the best format for this transfer, or could we come up with a more efficient representation? | * Is json the best format for this transfer, or could we come up with a more efficient representation? | ||
* Should we add a way to retrieve specific keys, for real-time updating of just the important bits? | * Should we add a way to retrieve specific keys, for real-time updating of just the important bits? | ||
feedback from warner: | |||
<warner> rfkelly: some random thoughts | |||
<rfkelly> please :-) | |||
<warner> there will be "shared collections" and "per-device collections", might be useful to have some metadata indicating which is which | |||
<warner> something to indicate whether data is stored as class-A or class-B, although we've talked (without conclusion) on how to prevent the storage server from getting to make a downgrade attack | |||
<warner> might be good to store a key ID with each collection, so clients can discover when a key has been changed (and thus they shouldn't be surprised to get MAC failures when they try to decrypt the records) | |||
<warner> garbage-collection when the password (and thus kB) is reset, pretty tricky | |||
<rfkelly> could the keyID also double as the classA/classB indicator? | |||
<warner> GET base/collection/version?limit= needs a response code to indicate "we're done" versus "more is coming" | |||
<warner> yeah, probably | |||
<warner> keyID probably = hash(key) | |||
<rfkelly> right | |||
<warner> although, if that, (encKey,hmacKey,keyID) = HKDF(key) would be better | |||
<rfkelly> is "garbage collection" essentially "delete everything that was created with the old key" | |||
<rfkelly> ? | |||
<warner> POSTing batches: first= and upto= sounds good, using "upto not in args" requires that we can always detect a missing message, which might not be the case if we memcache the inbound batch (or if we write it to SQL but then SQL rolls back). Might be worth thinking about that part more than I did in my docs. | |||
<rfkelly> GET base/collection/version?limit= currently indicates doneness by presence/absence of the "next" key in the body; a response code would be better | |||
<warner> yeah, GC is that, although we probably need some care to make sure an out-of-date client doesn't manage to delete everything, or get into a delete-fight with a less-out-of-date client | |||
<warner> (might require seqnums in the keyids) | |||
<warner> ah, next= is fine, unless REST prefers a response code | |||
* warner gets down to Things To Think About | |||
<warner> I think the login step is fine, you probably don't want to be doing pubkey verification with every message | |||
<warner> it adds one RTT (plus sign, plus verify) per hour, or per whatever lifetime we use on the certs (maybe 12 hours?), which seems pretty reasonable | |||
<warner> but removes the verify time on every single server message | |||
<warner> ok, time to chat with chris about native-data stuff | |||
<warner> rfkelly: looks good overall, I think your list of outstanding questions matches my own | |||