Subject: [VIPR] vipr-overview-06

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 12 Dec 2013 23:22:57 +0000

At the seasonal risk of raising a Ghost of Working Groups Past - for those of you still on this list, please do note the recent publication of vipr-overview-06. This document is no longer being considered as a Standards Track RFC, or even as a working group item of this now-defunct effort. It is being considered now as an individual Informational submission that documents the VIPR architecture for the benefit of posterity, but also explains why we stopped working on VIPR as a potential Standard.

If you are still interested, please do read this document and send any comments to this list. For the most part, useful comments at this point will be those that point out respects in which vipr-overview either fails to characterize the VIPR system or fails to correctly document its shortcomings. The new section 7.5 of the overview document is a good place to read up on the latter.

It would be great to see any comments before the end of the year. After that, this mailing list will formally give up the ghost.

Jon Peterson
Neustar, Inc.

---

From: Michael Procter <[email-masked]>
Date: Tue, 31 Dec 2013 20:58:54 +0000

Hi Jon,

Sorry for leaving comments until the last moment.  I've mainly read
section 7.5, as that seems to be the main area of change.

The main attack that doesn't seem to be mentioned is the one that
allows the approximate call start/end times to be used in conjunction
with multiple registrations in the RELOAD DHT to find accurate call
start/end times.  A malicious server can then use these to
authenticate itself as the caller to the called party, and perform a
MITM attack on all signalling and media for future calls.  This is
described in section 2.2 of draft-procter-vipr-privacy-concerns-00, in
the context of pranks, but it is certainly more widely applicable with
an increased number of registrations.

The reason I feel this attack should be included is that using call
start/end times is likely to play a part in any similar effort in the
future, and this is one of the attacks we should learn from.  A number
of the other attacks listed are likely to be avoided simply by
increased awareness of the risks of 'pervasive passive monitoring',
but this one is more active and should be noted for future attempts.

Best regards,

Michael