Re: Dialback authentication

Cool stuff! some remarks -

1) The Date field seems to introduce a one-second granularity which
seems quite arbitrary. For instance, if a client is continuously
sending one request every 10ms with the same token, then this would
cause the server to have to check its validity once every 100
requests. Also the other way around, if a client sends a request every
10s, then each request needs to trigger a check, even though maybe you
would want the token to have a validity of say 5 minutes.

i guess you answered this in your other reply, saying that you would
typically use dialback only once between two given domains, and then
switch to something else. But it would be nice if there were a way to
fix it. For instance, instead of the client sending a Date header, the
verification service could indicated a maximum validity of its answer.
the server could just make its own caching decisions, taking into
account that maximum.

2) about 7.6 DoS, you mention caching of host-meta and webfinger, but
what if the client sends many different tokens? then the server would
still have to do many requests to the third party, right? the client
would still have the same work to attack the third party, but it would
be harder for the third party to block the attacker (other than taking
down its whole dialback auth service for any IP address, which was the
presumed purpose of the attack anyway). i don't see how a sysadmin
could defend against that, other than making sure it has a lightweight
method to distinguish its own tokens from the attacker's tokens, and
then just try to sustain the attack by adding enough server power
while it lasts.

3) the client's original http request stays open while verification is
taking place, right? so maybe an extra remark about timeouts would be
in place. If the verification service takes longer than say 3000ms to
answer, then the server is allowed to treat that as a 'no', even if a
'yes' would still have arrived after waiting longer.

4) on that note, say i vote up some blogpost. it's not vital to know
whether my vote counts, i just want my client to get a quick response
from the server. Could the server respond with a 202 Accepted and deal
with the decision (e.g. whether to publish a comment that was posted
or discard it) afterwards? just a thought in the 'someone might want
to' category. ;)

5) does this deprecate the From: header in a way? (section 14.22 of rfc2616)

6) the big open issue now seems to be per-host vs per-user. You
started by saying webfinger but Mart argued a good point that per-user
granularity is maybe not so useful, and Blaine also mentioned (iiuc)
separating the question of which hosts trust each other in
server-to-server comms from the question of which user can do what
where.

I think the important point to make is that this protocol only
introduces a sort of trustable From: header, and what the server does
with that verified information is i think out of scope. So even if
announcing the verification service can probably be announced
per-host, i think we would typically use it to send verifiable
webfinger identities along with our http requests. Being able to do
that is a really cool feature with many possible applications.

thanks a lot for doing this, Evan!

ciao,
Michiel

On Fri, Sep 7, 2012 at 6:24 AM, Evan Prodromou <evan@status.net> wrote:
> On 12-09-05 11:45 AM, Blaine Cook wrote:
>
> Following up on some feedback I've just given Evan, I think it's best
> if the "user doing something" bit should be separate from the "hosts
> negotiating a secure / shared channel.
>
> Effectively this would just mean splitting the document into two
> separate documents; one that does the host negotiation stuff, and the
> other that handles the semantics of allowing delegation. That way, if
> two hosts wanted to do their secure communication using client certs
> instead, they could do so and still use the webfinger semantics around
> "is <host> allowed to act on behalf of <user>".
>
> In the interest of getting this editorial collaborative process going, I've
> taken the document on the wiki and turned it into an Internet Draft:
>
> https://datatracker.ietf.org/doc/draft-prodromou-dialback/
>
> I think there's a bug tracker for handling next versions.
>
> -Evan
>
>

Received on Friday, 7 September 2012 05:56:22 UTC