Re: Mitigating DDoS via Proof of Patience

On 28 June 2015 at 17:16, Manu Sporny <msporny@digitalbazaar.com> wrote:

> 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?).
>

Fair point.  Re; "the powers that be", I know some people have stronger
views than others, anyone in particular that pushed back against using the
web here?


>
> > 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.
>

Pre registration with the website, or pre registration in general?  For
example PGP does not require pre registration with a website, just to
publish your keys.  And then an email can be sent to any email provider
without registering.


>
> 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.
>

Got it.  However, aren't the two closely related?  e.g. I could send a
User: header saying who I am, and then the person will know it's not a
DDoS.  If I *dont* want to send a User: header then the server can *fall
back* to a zero trust paradigm.  Would it not be useful to consider this as
a joint kind of workflow?


>
> > 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
>

Yes, I do this already, on my homepage I have url/#me for me and url/#key1
for an RSA key.


>
> ... 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.
>

You dont have to own the url (although I do).  A provider could do that for
you.  Like with webmail.


>
> 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.
>

The market can decide this, the more stable providers will gain market
share.  This is the "COOL URIs dont change" principle.

>
>
> 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.
>

The advantage of URLs is not portability.  URLs are designed to be stable
and accrue reputation over time.  One way to do that is to add
credentials.

The advantage of URLs is that they are widely deployed, and scale to a mass
audience.

Let's assume it would be perhaps a decade or more for did: identifiers to
gain traction, is that cost worth mitigating against a risk that we all
accept today with our email providers?

Why not look at what can be done using web architecture to help with this.
e.g. owl : sameAs, hash URIs that dont closely couple the content and
document, inverse functional properties etc.  The other problem with did:
identifiers are that no one will know how to dereference them.  Why not use
ni:// (named instance) URIs which can be derferenced at well-known/ni/

Why not have a credentials footprint that spans many sites connected
together with owl : sameAs, and you can have a preferredURI.

To be clear, I dont want to say did: is a bad idea, certainly there are
advantages, just to understand the pros and cons and motivations a bit
better.


>
> -- 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/
>
>
>