Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 21 Jun 2014 17:00:13 +0000

We have submitted a new draft that describes the behavior B2BUA¹s should
follow when acting on a media plane that uses DTLS-SRTP.

http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00

Comments and inputs are welcome

Regards,
Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Saturday, 21 June 2014 11:01 am
To: Ram Mohan Ravindranath <[email-masked]>, "Tirumaleswar Reddy
(tireddy)" <[email-masked]>, Victor Pascual
<[email-masked]>, Victor Pascual <[email-masked]>,
"Gonzalo Salgueiro (gsalguei)" <[email-masked]>, "Gonzalo Salgueiro
(gsalguei)" <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
<[email-masked]>, Ram Mohan Ravindranath <[email-masked]>
Subject: New Version Notification for
draft-ram-straw-b2bua-dtls-srtp-00.txt

>
>A new version of I-D, draft-ram-straw-b2bua-dtls-srtp-00.txt
>has been successfully submitted by Gonzalo Salgueiro and posted to the
>IETF repository.
>
>Name:		draft-ram-straw-b2bua-dtls-srtp
>Revision:	00
>Title:		DTLS-SRTP Handling in Session Initiation Protocol (SIP)
>Back-to-Back User Agents (B2BUAs)
>Document date:	2014-06-20
>Group:		Individual Submission
>Pages:		10
>URL:            
>http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-dtls-srtp-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-dtls-srtp/
>Htmlized:       
>http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00
>
>
>Abstract:
>   Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
>   often function on the media plane, rather than just on the signaling
>   path.  This document describes the behavior B2BUAs should follow when
>   acting on the media plane that use Secure Real-time Transport
>   Protocol (SRTP) security context setup with Datagram Transport Layer
>   Security (DTLS) protocol.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Jun 2014 09:47:27 +0000

(As co-chair)

Hi,

The draft below addresses the following STRAW delivery:

    "A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end submitted to the IESG as PS"

Currently there are no other drafts addressing the delivery, so our plan is to perform an adoption call in the near future. 

We therefor ask the community to take a look at the draft, to see whether there is anything that needs to be addressed before such adoption call is made.

Thanks!

Regards,

Christer

________________________________________
From: straw [[email-masked]] on behalf of Ram Mohan R (rmohanr) [[email-masked]]
Sent: Saturday, 21 June 2014 8:00 PM
To: [email-masked]
Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt

Regards,
Authors

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Saturday, 21 June 2014 11:01 am
To: Ram Mohan Ravindranath <[email-masked]>, "Tirumaleswar Reddy

>until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
straw mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/straw

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 11:42:46 -0400

Comments on the draft:

General point:

This draft doesn't say anything about middleboxes that *remove* the 
encryption on the media stream. Especially given the recent issues about 
surveillance, I would think the right thing to do is say MUST NOT to 
this. OTOH, I assume that there are users of SBC who explicitly desire 
this behavior. At the least it should be discussed in the security 
considerations.

Section 3.2:

ISTM that Media Aware and Media Termination deserve separate treatment.

A Media Aware relay doesn't need to encrypt - it can pass the incoming 
packets through. So it could simply observe the fingerprints as they go 
by without changing them, and then use to do decryption.

Also, doesn't this depend on how much scrutiny it gives to the packets. 
IIUC, with SRTP the RTP packet headers are not encrypted, so some basic 
level of scrutiny of the RTP can be done without any decryption.

	Thanks,
	Paul