Re: [VIPR] Review of draft-jennings-vipr-overview-01

[Michael Procter <[e-mail]>]

On 11 July 2011 19:54, Cullen Jennings <[e-mail]> wrote:
>
> Thee are excellent points. The first few were easy and fixed in next version but on to some of the harder issues you raised ...
>
> On May 13, 2011, at 1:37 , Michael Procter wrote:
>
>> Section 8.2
>>  The TLS-SRP uses the caller ID and called number as a "username"
[Discussion of CLI leaks of callers to a specific number]

> I think we need to protect against the attack you describe. It's been
> awhile since have looked at SRP. Perhaps hashing the username would
> solve this?

I don't think hashing would be enough.  I hashed the entire UK number
space in a few hours using a naive piece of Python and my
not-exactly-state-of-the-art computer.  Then I googled and found out
about using graphics cards for number crunching, which apparently can
do the same job in a couple of seconds.  Hashing the CLI doesn't sound
like a sufficient deterrent to me.

In fact, whatever technique used to obscure the CLI is probably only
slightly helpful as the source IP address of the validation attempt
would probably leak too much information for larger users (I accept
that smaller users will probably have fairly generic reverse IP
information and probably their ISP's info in whois).

Going a step further, even without knowing the source IP (validation
over TOR anyone?), I still think there is a worrying leak.  Spotting a
noticeable spike in competitor's sales line traffic following this ad
campaign, but not that one, is perfectly doable once you have a
statistically significant number of calls.  No doubt far more
information can be extracted given time and inspiration.

>> Section 9.2: 3rd attack
>>  "the TTL for cached routes is set to match the
>>   duration that carriers typically hold numbers."
[Description of route expiry leading to poor user experience]

> total agree. I'd like to see a better way of doing validation for video calls.

Not thought of any bright ideas here, sorry!


>> Section 9.2: 5th attack
[Discussion of falsely claiming a number by knowing the start and end
times of a call]

> again I agree. Of course the guy in the next cube could probably just
> walk over and forward the phone too. One things that can be done is
> not share the validation you learn for one phone in an enterprise with
> other phones in the enterprise.

That restriction isn't enough to stop the attack if you time the
victim making the call on their own phone, which wouldn't take too
much social engineering.  Remember that you only need to get the
timings accurate to 2 seconds, which I think sounds fairly
straightforward.

Actually, you can handle a looser tolerance if you register multiple
times.  For each registration in the DHT, the original caller will
attempt a validation, giving you another guess at the times, so you
can use your best guesses (Tb and Te) for the first go, (Tb, Te+2) for
the second, (Tb+2, Te) for the third and (Tb+2, Te+2) for the fourth.
4 registrations and you have doubled the tolerance to timing errors to
4 seconds for both call beginning and end.  More registrations would
allow you to relax the tolerances further.  You could even defeat
Hadriel's "You expect accurate call lengths?" attack like this!  And
once you have had a correct with the caller, you can use your new
accurate times to talk to the real registered owner of the number and
set up a MITM for the next few months.


Best regards,

Michael