Re: Mitigating DDoS via Proof of Patience

On 06/28/2015 09:57 AM, Melvin Carvalho wrote:
> Nice work!
> 
> Some comments:
> 
> 1. Why another IANA registry rather than just use the web?

Mostly because that's the way IETF does things for a variety of good and
bad reasons. We could use URLs, but then people complain that the URL is
too long. In the past, I've tried writing IETF specs that mention that
the "IDENTIFIER" should be tacked onto a fragment identifier and the
registry lives at a particular URL (like "https://w3id.org/proofs#"):

https://w3id.org/proofs#IDENTIFIER

... but the powers that be complained about that construct and required
a protocol that uses certain keywords that is published via IETF to have
the registry managed via IANA (because there is a clear process that has
been in place for decades on how to do this).

Basically, going against the IANA registries will be a struggle and we
have more important problems that require our time and energy.

If someone can talk to the powers that be that are closely attached to
the IANA/IETF registry folks and convince them that the w3id-based
mechanism above would be a better approach, I'd be happy to change the
spec to just using the Web. Many of us know it's a better approach, but
I know of no finalized RFC that does so (but maybe I missed one?).

> 2. re: "How do you determine legitimate requests for a resource 
> without requiring pre-registration?" -- surely a web of trust is the 
> primary solution here?

A Web of Trust requires pre-registration and thus doesn't solve the
initial problem statement.

A Web of Trust could be used when you need to strongly authorize an
individual or organization (and is what HTTP Signatures[1] and Linked
Data Signatures[2] is about), but that's not this use case. This use
case is about weakly determining that a client is most likely acting in
good faith when they hit a resource. Another way to state it is that
you're trying to make attacking the resource economically detrimental to
the attacker.

> 3. I'm not sure I see the relation to DHT, and credential portability
> here or how it fits into the bigger picture.  In my world credential
> portability is achieved using # URIs.

We are using URIs for the decentralized identifiers. This is what they
look like:

did:99817953-c376-4957-8b1d-43ed800baba9

("did" stands for "decentralized identifier")

... but I think you may mean URLs? More on using URLs below:

> Isnt this a much more complex way to solve the problem that would 
> take potentially many years to get adoption by clients?

URLs are a bad solution to this particular problem. When you issue a
credential, it needs to be tied to an identifier of some kind. If you
don't do that, you're issuing a bearer credential and those can be
copied and re-used quite easily. Group signatures (such as
Camenisch-Lysyanskaya) don't scale as far as we can tell either, based
on research that Dave Longley has done.

So, if we need an identifier, and use a URL, like so:

https://identity.aol.com/melvin#me

Then the assumption is that you're also going to be storing your public
keys there:

https://identity.aol.com/melvin/keys#1

... and that's where the problem comes in: You don't own that URL. You
could argue that you'd just setup a server that you own to do that, but
the very large majority of people using credentials won't do that.
They'll use a super-provider.

Now, what happens when AOL's identity business folds and you want to
port your credentials over to Google, or Facebook, or your own server?
You can't, because your credentials are tied to an identifier that is on
AOL's servers using an AOL URL. All your public keys live at the URL as
well, so when AOL's identity business folds, every person on the service
loses all of their identities and credentials.

Even if AOL's identity business stays around forever, they have you
locked in because every credential that you get will be tied to /their/
URL, which they control. Even if they wanted to provide data
portability, they're locked into running a permanent re-direct service
for all time.

This is what I meant when I said URLs are broken /for this
particular use case/. URLs are great for a variety of other use cases,
but not this one.

Credentials should be portable, using URLs make that very difficult. I'd
be happy to be proven wrong on this point, as I do agree that using a
URL would be far easier than what we're trying to do.

-- manu

[1]http://tools.ietf.org/html/draft-cavage-http-signatures-03
[2]https://web-payments.org/specs/source/ld-signatures/

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/

Received on Sunday, 28 June 2015 15:16:35 UTC