On 9/25/07, Daniel Senie <dts(_at_)senie(_dot_)com> wrote:
At 03:25 PM 9/25/2007, Pars Mutaf wrote:
On 9/25/07, *Daniel Senie* <dts(_at_)senie(_dot_)com> wrote:
At 03:02 PM 9/25/2007, Pars Mutaf wrote:
On 9/25/07, Pars Mutaf <pars(_dot_)mutaf(_at_)gmail(_dot_)com> wrote: Hello,
On 25 Sep 2007 16:33:32 -0000, John Levine < johnl(_at_)iecc(_dot_)com>
wrote: >1.
The querier user types the target user's "human name" (as if he were >
consulting a phonebook), or a pseudoynm. >2. The pairing request is
forwarded to the target phone. >3. The query, along with the querier
user's name, are displayed on the > target phone's screen.
I have a list of 250,000 people here (scraped off web sites) to whom I'd
just love to make recorded phone calls. Can I use your protocol to ask
them all if it's OK? If not, why not, and how are you going to stop me?
Using a Turing test (CAPTCHA) for example.
http://en.wikipedia.org/wiki/Captcha
When you make a request, the target phone returns a captcha. If you don't
provide the right solution, the target user won't even see your request,
it will be dropped. Captcha's difficulty can be adaptively tuned by the
target phone..
So another step should be added to the above description.
A quick addition to my previous mail:
Captcha is proposed for protecting the target user against
disturbing bogus requests.
There is also the 4th step (below) in the original mail which suggests
that user approval is needed before the phone number
(or any info you like) is returned to the querier:
4. The target user approves the request in real-time by pushing on the YES
button of the phone.
And hopefully this can all be FULLY disabled, or be disabled by default.
Otherwise, everyone will be inundated with these messages popping up, asking
you to hit the "yes" button. Count me as someone who'd never want this
protocol implemented in my phone.
You have the other problems listed above in this case (manual exchange
difficult etc.
and the other problems listed in my original mail).
Why the CAPTCHA solution is not enough for you? In my personal view, the
person who
wants to disturb you is the one who is suffering (CAPTCHAs can be made
very hard
if you wish).
Maybe it wasn't clear. Here are the steps:
The querier user makes the request.
The target phone returns a CAPTCHA.
The querier user solves the CAPTHA.
The target user sees the query displayed on the screen and approves the
request (or not).
The phone number is returned (or not).
The target phone gets pestered whether the owner of the target phone
wishes to receive or not? Does the target phone need to be in a "I want to
receive" mode, or will anyone be able to fire such a request at your phone?
"I want to receive mode" why not. This answers the other questions below?
In the worst case (where many attackers are "constantly" looking for
reachable phones):
You can enable this protocol when you need to pair your phone
with another user's phone. Because manual exchange is difficult.
Or, you can enter "I want to receive mode" when you have a new phone
or phone number, home address, etc.
pars
What I'm imaginging is every retailer bombarding every cell phone with a
request to get their contact information added to your phone.
The simple act of receiving the request for the Captcha is an annoyance.
The question is, how are you going to limit the ability for someone to annoy
someone else? Or to put it in a more blunt way, how do you avoid having
people instigate a DDoS, in the form of tons of CAPTCHA handshake requests,
or approval requests or whatever?
I must be missing something, because I can't imagine why you'd want to
create such a wonderful pathway for rendering someone's phone unusable.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf