Subject: [rtcweb] #30: Wiretapping

From: "rtcweb issue tracker" <[email-masked]>
Date: Fri, 13 Sep 2013 00:08:03 -0000

#30: Wiretapping

 In several sections of the document, the phrase "It is essential
 that the communication cannot be wiretapped [RFC2804]" is used.
 The phrase is used in Sections 3.2.1.1, 3.2.11.1, 3.2.12.1, 3.2.13.1,
 3.3.1.1 and 3.2.3.1, but not in 3.2.14.1 (which also does not
 reference F20).

 Given the recent revelations, and the discussion of SRTP/SDES at
 IETF 87, I would suggest the following:

 a. Use of more precise terminology than what is in F20.  For example,
 I think what we are asking for in many of the F20 scenarios is
 per-packet encryption and integrity protection of media,
 utilizing keys known only by the endpoints, as well as support
 for perfect forward secrecy.

 b. Inclusion of a reference to F20 in Section 3.2.14.1 (Distributed
 Music Band).  Not sure why protection against snooping wouldn't be
 relevant in this use case (there are countries where musicians
 have been severely punished).

 c. Consideration of the requirement in gateway scenarios. For gateway
 scenarios such as 3.3.1.1, the e2e key management
 requirement probably isn't realistic, so maybe we need to
 just cite F35/F36 for that case.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-rtcweb-use-
  [email-masked]          |  cases-and-
     Type:  defect                   |  [email-masked]
 Priority:  critical                 |     Status:  new
Component:  rtp-usage                |  Milestone:  milestone1
 Severity:  In WG Last Call          |    Version:  1.0
                                     |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/rtcweb/trac/ticket/30>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: "rtcweb issue tracker" <[email-masked]>
Date: Fri, 13 Sep 2013 00:08:51 -0000

#30: Wiretapping

Changes (by [email-masked]):

 * component:  rtp-usage => use-cases-and-requirements

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-rtcweb-use-
  [email-masked]          |  cases-and-
     Type:  defect                   |  [email-masked]
 Priority:  critical                 |      Status:  new
Component:  use-cases-and-           |   Milestone:  milestone1
  requirements                       |     Version:  1.0
 Severity:  In WG Last Call          |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://tools.ietf.org/wg/rtcweb/trac/ticket/30#comment:1>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Sep 2013 09:15:18 +0200

>  for perfect forward secrecy.
I think this is a too low level of detail for an use cases document. It
does belong in the security / security-arch document, where we detail
both what the requirement implies and how the requirement is implemented.

If we want to add details here, I suggest adding "against an adversary
that has access to the signalling path and/or access to one of the end
systems after the communication has occured" (which would lead to a
requirement for DTLS key exchange and PFS).

>  just cite F35/F36 for that case.
If we use the language I suggested above, noting that this spec can do
nothing to secure things beyond the gateway is probably enough ("e2e"
key management in this case would mean "end to gateway" - it's up to the
gateway and what's beyond it to protect the keys after that).

-- 
Surveillance is pervasive. Go Dark.