Re: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt

"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Tue, 17 November 2015 09:17 UTC

Return-Path: <rmohanr@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653631B2D4E; Tue, 17 Nov 2015 01:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.086
X-Spam-Level:
X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ-p3KfLcQle; Tue, 17 Nov 2015 01:17:21 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A89F1B2D48; Tue, 17 Nov 2015 01:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4810; q=dns/txt; s=iport; t=1447751841; x=1448961441; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c3X/EepysXxwVTkAGoeU2qOEaj1qtjIGxeDO2cSIIGA=; b=fSzD/nOltjD9cAB0mZMkPnIm5LHVItkSyZvBWNkHXJzxUq5DpUHqybMU BRYFIk6vvckc65MWt2hEqT4MmggJKp3j2Aztoi/bFeTr38fgPLpZMzPuA O5ZLeqgMP0Hehk/WEPuocx4oXgqwCt3fYggHO1W0S8GVa/RASM5p+cbhe Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAgCs70pW/5BdJa1UCYM7U2kGBrw9ghoBDYFlI4VtAoFKOBQBAQEBAQEBgQqENAEBAQQ6PwwEAgEIEQMBAh8QMh0IAgQBDQWILggFA7s+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZVhH2EKgcKAYR9BZZJAYUfiAqBW0mDd45kAoNSg3EBHwEBQoQEcgELAQGDOzoBgQYBAQE
X-IronPort-AV: E=Sophos;i="5.20,307,1444694400"; d="scan'208";a="47447057"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2015 09:17:20 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tAH9HKEM016738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Nov 2015 09:17:20 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 Nov 2015 04:17:19 -0500
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.000; Tue, 17 Nov 2015 04:17:19 -0500
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org" <draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org>, "straw@ietf.org" <straw@ietf.org>
Thread-Topic: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
Thread-Index: AQHRILYtRnP8BsSoEEqoxVoa7OqN7J6goUUA
Date: Tue, 17 Nov 2015 09:17:19 +0000
Message-ID: <D270EE25.494E0%rmohanr@cisco.com>
References: <564A4B26.4020108@bell-labs.com>
In-Reply-To: <564A4B26.4020108@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [173.39.64.87]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5733618F4FCF5548AED7FB15B723950A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/XSvEDT-1VYpT-mzrs0-FNsdpJhE>
X-Mailman-Approved-At: Tue, 17 Nov 2015 20:31:36 -0800
Cc: "iesg@ietf.org" <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 09:17:23 -0000

Hi Vijay,

Thanks for your review and feedback. Please see inline

-----Original Message-----
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Date: Tuesday, 17 November 2015 at 3:01 AM
To: "draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org"
<draft-ietf-straw-b2bua-dtls-srtp.all@tools.ietf.org>
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "iesg@ietf.org"
<iesg@ietf.org>
Subject: APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt
Resent-From: <vkg@bell-labs.com>
Resent-To: <draft-ietf-straw-b2bua-dtls-srtp.all@ietf.org>
Resent-Date: Tuesday, 17 November 2015 at 3:01 AM

>I have been selected as the Applications Area Directorate early
>reviewer for this draft (for background on appsdir, please see
>http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)
>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive. Please wait for direction from your document shepherd
>or AD before posting a new version of the draft.
>
>Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt
>Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP)
>        Back-to-Back User Agents (B2BUAs)
>Reviewer: Vijay K. Gurbani
>Review Date: 2015-11-16
>IETF Last Call Date: 2015-11-17
>IESG Telechat Date: 2015-12-03
>
>Summary: This draft has minor issues, and is ready for publication as
>a Proposed Standard once these issues are resolved.
>
>I will also (strongly) suggest that the editors go over the draft for
>grammatical touches to eliminate the sort of issues present in the Nits
>section.  This will make the draft more readable and provide it the
>gravity it needs for a standards track document.
>
>Major: 0
>Minor: 3
>Nits: Many
>
>Minor:
>
>- S3.1.1, second to last paragraph (beginning with "[RFC4474] provides
>  ... the signature."): Isn't this only true if the originating UAC
>  used rfc4474 and inserted the appropriate headers.  Or is the
>  assumption that rfc4474 is always used, and therefore, a media relay
>  B2BUA must be careful and not modify the fingerprints?

Right. This is true only when RFC4474 is used.
We have re-worded the text to say the same. Here is the proposed new text:

NEW:
"When <xref target="RFC4474"/> is used forDTLS-SRTP sessions, the
fingerprint attributes are integrity protected.
Thus, under circumstances when <xref target="RFC4474"/> is used, B2BUAs
cannot terminate the DTLS-SRTP session without invalidating the signature
and
causing the session to fail.


>
>- S3.1.2, first paragraph: "The identity integrity protection
>  procedures described in Security Considerations section..."
>
>  Described in the Security Consideration section of which document?
>  The document under review or some other one (rfc7092)?

Described in section 5 (Security Consideration) of this document. I will
re-word to say the same.

>
>- S3.1.2.2: I am not sure what your takeaway is at the end of this
>  section.  You seem to be making the case that a B2BUA cannot
>  modify the RTP headers and RTCP packets.  But then you go on and
>  say that this can be mitigated by using different keys, and that
>  with "such an approach" (aside: define "such an approach"), the
>  B2BUA is not aware of the keys used to decrypt the media payload.
>  Well, the B2BUA is never aware of such keys, since they are
>  negotiated end-to-end (over the B2BUA), so I am at a loss to see
>  what is the point of this section.

The idea of the section is to highlight that with current mechanisms it is
not possible for B2BUA modify headers with out being a DTLS endpoint.
In future (with PERC) it is possible that a B2BUA can modify the
headers/RTCP packets but still have no access to the RTP payload.


>
>Nits:
>
>- Abstract: s/media plane, rather than/media plane rather than
>
>- Abstract: s/This document describes the behavior such B2BUAs can
>   adhere to/This document describes the behaviour of such B2BUAs/
>
>- S1.1: s/The fingerprint, identifies/The fingerprint identifies
>
>- S3.1.2:
>  s/There are two types of media-aware relay/There are two types of
>  media-aware relays/
>
>- S3.1.2.1: (For readability)
>  s/This kind of media aware relay/A RTP/RTCP aware media relay/
>
>- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/

Thanks. Will fix all the above Nits

Regards,
Ram

>
>  (If you want to retain "the", perhaps you may consider renaming
>  Bob to Donald!  Sorry, bad joke, I know.)
>
>Thanks,
>
>- vijay
>-- 
>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
>Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq