Re: Mitigating DDoS via Proof of Patience

On 06/28/2015 09:04 PM, Melvin Carvalho wrote:
> 
>> 
>> On 29 June 2015 at 01:56, Dave Longley <dlongley@digitalbazaar.com 
>> <mailto:dlongley@digitalbazaar.com>> wrote:
>> 
>> On 06/28/2015 11:41 AM, Melvin Carvalho wrote:
>>> 
>>> Why not have a credentials footprint that spans many sites 
>>> connected together with owl : sameAs, and you can have a 
>>> preferredURI.
>> 
>> Suppose we went with "owl:sameAs". What mechanism would you suggest
>> that we would use to establish "owl:sameAs" relationships as
>> authentic?
> 
> So if you have a two way owl : sameAs and one of them goes down. Any 
> software that had that information, could look in the other place
> for the information and slowly self heal.
> 
> So any software looking at a bunch of triples could conceivably 
> deduce that the credential belonged to the new entity.

Suppose I, your adversary, assert "https://iamaliar.com/#adversary" is
"owl:sameAs" "https://superprovider.com/#melvin". In this case, we do
*not* want any software looking at a bunch of triples to conceivably
deduce that the credential belonged to this new entity. How do we avoid
this?

You can't just put an assertion out there and have everything be just
fine in the world of credentials. The original question primarily had to
do with dealing with adversaries. How do you deal with them in this
"anyone can assert anything" world with "owl:sameAs"? What other
complexities do you have to build into the system to preserve trust?

> 
> In order to support portable credentials, some complexity is going
> to have to be added somewhere. With the `did` scheme, we push most of
>  that complexity into the software responsible for storing and 
> looking up `dids`. "Infrastructure software", if you will. This
> keeps the problem isolated away from most people, away from the
> common users of the system.
> 
> 
> Portable identifiers have been proposed many times.  The main con is 
> that you have to persuade lots of people and devices to use them. 
> This can typically take a decade.  The main disadvantage of HTTP is 
> that URLs are sticky.

Your argument holds for devices and any software that needs to use a new
protocol -- it may take time to adopt it. However, regarding people,
most of them either don't use URLs as identifiers now or are unaware of
the fact that they do. That wouldn't change with `dids`, it would remain
the same. However, if people need to start understanding and managing
their identity URLs (eg: "owl:sameAs"), I see that as a much greater
barrier to adoption.

Whatever choices we make to enable identifier portability, I believe
people must come first. At a minimum, their experience needs to be no
significantly worse than it is today. I think a `did` scheme (or some
even deeper infrastructure-based mechanism in DNS or similar) is the
most likely to achieve that because it's layers away from the typical
person's experience. I suspect "owl:sameAs" approaches would be more
likely to bubble to the surface cause aggravation.

>> 
>> An alternative to this approach is to push the problem to the 
>> surface. Make people take care of linking up their various 
>> identifiers and, I suspect, managing a more complex set of keys. 
>> You can probably try to hide this behind software as well, but, 
>> firstly, it's going to touch many more parts of the system, and 
>> second, people are going to be more aware of it (and less
>> satisfied with the system as a result).
> 
> 
> Yes
> 
> Another way to do it is to have the signature make the document 
> portable, so that it can live on *any* HTTP doc.

I'm not quite sure I understand this. This seems to be orthogonal to the
question at hand; the current credentials work already allows credential
documents to be portable in that sense. The credential documents
themselves can live anywhere, the problem is with what they assert. Do
they assert "https://superprovider.com/#melvin" is the recipient of the
credential or someone else?

> What can then happen is discovery via inverse functional properties 
> to get the data structure.  e.g. search for email address user@host 
> (that becomes the hard part) and then see who has signed credentials
>  associated with it.

How would you have a credential associated with it unless you had it
reissued? Of course, if you can reissue credentials at any time there is
no problem. You can't do that with many credentials. The problem that
needs solving is this:

If a credential has been issued to your identifier and your identifier
changes, how do you keep using that credential without having it reissued?

Simply saying "make an `owl:sameAs` assertion" doesn't fully solve the
problem. What if an adversary makes such an assertion? What are the
details for thwarting such an adversary?

> 
> In short, both systems are going to pose hard problems.  HTTP URIs 
> being sticky, but with some ways to limit damage (I think this is the
> path to explore), but with huge adoption.  Then did: URIs as portable
> but much harder to find via follow your nose, search, or well known
> lookups, and the battle to get the libraries well supported.
> 
> No reason why both cant happen together.

Sure, they can happen together, and a `did` is just a new type of URL
(they are locators and contain the scheme for retrieving them, eg:
`did:abcd-1234-5678-1234`). In the current credentials work, an
identifier for the recipient of a credential is just a URL.

> 
> What about ni:// type URIs with a .well-known lookup area.

How do you propose that would work?

> 
> The above was something of a brain dump.  I hope no opinion there 
> comes across as a strong view or inflexible.

Nope. :)

I just think there are a lot of details to consider to make a system
like this both function and establish trust.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 29 June 2015 03:02:18 UTC