search

haskell-mafia / zodiac

API request-signing utilities
BSD 3-Clause "New" or "Revised" License
2 stars 2 forks source link

Add TARPv1 spec draft #90

Closed olorin closed 8 years ago

olorin commented 8 years ago

Large parts of this are cannibalised from the TSRP spec, but the spec should be viewed on its own.

I expect this to be iterated on a lot (probably both before and after the draft is merged); the core of it is correct but it could use some cleanup + fixing a few minor things I got wrong with TSRP. Looking for all kinds of review on this PR, everything from wording suggestions to "this protocol is bad and you should feel bad". To be clear, none of this is implemented yet; the current plan is to re-use a bunch of primitives from the TSRP implementation (e.g., canonical requests), but if there are improvements to be made now is the best time to make them.

! @thumphries @erikd-ambiata @markhibberd @novemberkilo @nhibberd @tranma

novemberkilo commented 8 years ago

Read this at medium speed and things seem generally fine. I did notice that we're not using a nonce as part of the defense against replay attacks - is this intentional? Also, a general question about the values of various timeouts (10 min, one solar year etc.) - are these based on the TSRP spec or other?

olorin commented 8 years ago

I did notice that we're not using a nonce as part of the defense against replay attacks - is this intentional?

It is intentional; iirc this was discussed in meatspace with @markhibberd for the TSRP design, and we concluded that for our case the benefit of a nonce wasn't worth the added complexity of handling state at this layer given that it's designed for use over TLS.

Also, a general question about the values of various timeouts (10 min, one solar year etc.) - are these based on the TSRP spec or other?

They are the same values as used in the TSRP spec. One solar year doesn't have any particular reasoning behind it apart from not wanting to have unbounded parameters (stepping over the corpses of protocols past) and a year being more than I can imagine anyone actually using, plus an order of magnitude or two and a nice human-friendly number.

The ten-minute one is the clock-skew window - we don't want to allow request timestamps in the future as it means we can't reason about expiries, but we also don't want to break for clients who have clocks slightly ahead of ours. Now that you mention it, I think ten minutes is actually excessive here - initially I was erring on the side of not-breaking, but one minute should be ample and matches the default request expiry we're using in TSRP implementations.

Do you think I should add the reasoning for these to the spec? The reason I didn't is a desire to not make it even more wordy than it already is/pollute with extraneous data, but it should probably be documented somewhere.

novemberkilo commented 8 years ago

Ok thanks that makes sense.

Do you think I should add the reasoning for these to the spec? The reason I didn't is a desire to not make it even more wordy than it already is/pollute with extraneous data, but it should probably be documented somewhere.

In my opinion the rationale should not be in the spec (unless it fits in a phrase - e.g. "in order to allow for clock-skew"). If there is the need to describe rationale in detail then perhaps that should go in a supporting document.

olorin commented 8 years ago

In my opinion the rationale should not be in the spec (unless it fits in a phrase - e.g. "in order to allow for clock-skew"). If there is the need to describe rationale in detail then perhaps that should go in a supporting document.

Makes sense, I might add a design-notes.md or something to that effect.

olorin commented 8 years ago

Also, I should mention that if anyone needs a refresher/intro on any of the crypto stuff to make sense of the spec - digital signatures, elliptic-curve crypto, ed25519 et cetera - just let me know and we can whiteboard it. It's not really necessary for understanding the protocol, but is helpful for ensuring the selection of primitives is appropriate.

erikd-ambiata commented 8 years ago

@olorin I'd be happy for a refresher/intro whiteboard session. I sort of know little bits and pieces, but thats about it.

olorin commented 8 years ago

@olorin I'd be happy for a refresher/intro whiteboard session. I sort of know little bits and pieces, but thats about it.

Will do a broad-overview type of thing (basic conceptual stuff about ECC, then run through the algorithm). Probably Monday, let me know if you are interested and I will let you know when it happens.

thumphries commented 8 years ago

Is it right to say this is TSRP with a ed25519 signature instead of a MAC? Are there any other differences I might have missed? I would appreciate some compare and contrast to TSRP (in this thread or in the document)

In particular it is clear to me that the server cannot forge a customer request under TARP, while we could do so under TSRP due to the preshared key. Outside of this the outcomes and threat model look the same. I'd like to understand the other benefits from using an asymmetric protocol; would be down for whiteboarding sometime.

This spec read clearly to me, mostly due to familiarity with TSRP. Spotting the differences took some effort. If the two specs are to coexist going forward it would be nice to line up the wording such that they can be diff'd, given there is so much overlap.

Usual disclaimer: IANACryptographer 👍

olorin commented 8 years ago

Will do a broad-overview type of thing (basic conceptual stuff about ECC, then run through the algorithm). Probably Monday, let me know if you are interested and I will let you know when it happens.

@erikd-ambiata not going to have time for this today sorry, could we try for Tuesday?

erikd-ambiata commented 8 years ago

Yup, no problem.

olorin commented 8 years ago

This revision of the draft has now undergone external review without uncovering major issues. Reasonably happy with it as a starting-point, there are a few tweaks/improvements to make but will merge the draft if no-one objects.