On 9-Mar-06, at 12:44 PM, Robert Yates wrote:
Hallam-Baker, Phillip wrote:
I think that DoS attacks are going to be a major issue that any
protocol in
this space is going to have to cope with.
Agreed, I apologize for bringing this up again, but I think it very
important that we get this right and am interested in the thoughts
of others as to whether dmd0 should be tightened to help protect
against DoS attacks.
As far as I can make out, it is going to be fairly hard to protect
against DoS if we develop a protocol that requires a membersite's
thread to block wait (either directly or indirectly) on the
retrieval of two urls from potentially unknown and untrusted
sources. I know that Phillip mentioned that membersites could
"learn" not to trust certain sources, but should we instead look at
ways of avoiding these calls?
I guess what I am asking is whether it should be a design
consideration of DIX to minimize the synchronous calls that must be
made to untrusted sites when verifying messages, particularly those
messages asserting a persona-url?
If this is a consideration worth persuing then I wanted to jot down
a few approaches to reducing the need for these calls and see what
others think..
1) PKI, this would obviously remove the need to make the verify
call, but I agree that PKI should not be a MUST requirement.
PKI resolves the requirement for the MS to call other servers.
It would be possible for a MS to only work with Homesites that used
PKI for verification. This would allow a Membersite to choose the
methodology used for verification, without requiring ALL membersites
to support PKI.
2) Only call the remote site once to generate a shared secret and
then use the secret to verify signatures coming from that site.
This would be akin to openid's associate mode.
I think having a shared secret mode is a good option for improving
performance. Just as in OpenID, having it as an option rather then a
requirement is best as it requires state management and additional
overhead if little interaction between that Homesite and Membersite.
Note that it does not solve DoS since bad server can repeatedly fail
to provide shared secret.
3) Use Phillip's suggestion of SRV records as a discovery
mechanism, instead of looking up the persona-url.
Does not solve DoS as bad server can withhold returning SRV records.
Completely agree that we need to consider these types of attacks.
Given that we have not got a WG started yet, I'm wondering if we are
getting ahead of ourselves though?
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
