On Fri, 2014-09-19 at 22:17 -0400, Steve Dougherty wrote: > On 09/16/2014 04:45 AM, Florent Daigniere wrote: > > On Mon, 2014-09-15 at 23:42 -0400, Steve Dougherty wrote: > ... > > I think it's the wrong-layer... You really need a new key-type to do > > revocation/multi-signature properly. It doesn't have to be > > over-engineered (programmable) but it has to be consistent... think > > about TOCTOU > > Are you suggesting a key type that requires multiple signatures instead > of SSK's one?
Not necessarily; A clever, very simple, way of doing it is to check revocations *at a particular slot* on a USK. With that scheme, there would be only a single key. > That seems likely to be a fair amount of work. Does it > make sense to categorize that as a later-stage improvement to an > implementation of this? > IMHO it's not a lot of work; it's trivial RSKs would be USKs... for which slot XXXXXX is checked for before returning any data; there wouldn't be any fallback once the key/slot is blown > > Moreover, I think that you should start by a threat model: who are the > > players/actors? What do you expect them to be able/unable to do? > > I didn't have a threat model in mind - this is a collection of stuff > that sounded cool to me. The main security thing I was aiming for is > seizing the insert key being insufficient to deploy a build. > If you want to prevent that you need a multi-signature key scheme; that's more complex. A scheme with Revocation won't prevent someone from inserting the malicious build; it'll hopefully prevent people from using it > I could try coming up with a model now, but it seems backwards to fit a > model to a system instead of the other way around. Do you have > suggestions for a model? > There are plenty of models; if you listen to people you'll end up with a complex one for which the only answer is an over-engineered programmable key-type... I'm not sure it's practical for us to implement such a scheme right now. > > ... and clarify who holds which key in the above; I've re-read it > > several times but it's still confusing to me. For instance: who holds > > the insert-key of the USK? Is it okay for them to DoS the mechanism? > > I was thinking the release manager holds the USK insert key, but that > doesn't explain how the others insert their signatures. They could also > hold the insert key, or the RM could solicit their signatures and insert > them on their behalf. > Ok, so that's a multi-signatory key-type you're after. My suggestions is to separate both the revocation and multi-signatory bits... You can have a simple revocation scheme like I've explained above (where all RMs have the insert/revocation key)... but inserted stuff needs to contain metadatas signed by *n* RMs for it to be deployed (two phase check: first check it's not revoked, then check there's enough sigs) > Someone with the key could insert junk editions, but as long as the > initial channel definition required more signatures on artifacts than > the attacker controls they couldn't actually deploy a build, just make > the channel useless. Which is still bad. > > > What if they "fast-forward" (inserting enough editions) a revocation to > > ensure the client layer skips the edition they want to ban? > > Inserting junk editions is an effective attack here, yes. My concern with the naive approach is that you can prevent the revocation to be found. Whereas with the scheme above, if it's always at a specific slot... you can't :) Florent
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
