Re: IETF solution for pairing cellular hosts

["Pars Mutaf" <pars.mutaf@xxxxxxxxx>]

On 9/25/07, Daniel Senie <dts@xxxxxxxxx> wrote:

At 03:25 PM 9/25/2007, Pars Mutaf wrote:

On 9/25/07, Daniel Senie <dts@xxxxxxxxx> wrote:

At 03:02 PM 9/25/2007, Pars Mutaf wrote:

On 9/25/07, Pars Mutaf <pars.mutaf@xxxxxxxxx> wrote:

Hello,

On 25 Sep 2007 16:33:32 -0000, John Levine < johnl@xxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf