Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 25 September 2017 20:55 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14661126C0F for <bfcpbis@ietfa.amsl.com>; Mon, 25 Sep 2017 13:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Of2aVGGD3lRa for <bfcpbis@ietfa.amsl.com>; Mon, 25 Sep 2017 13:55:41 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05781132055 for <bfcpbis@ietf.org>; Mon, 25 Sep 2017 13:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14510; q=dns/txt; s=iport; t=1506372941; x=1507582541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w16Ogds+HOaNhImjiT+YCiiTDuQzlELpt6wU5tOM2HM=; b=aLKiaWlrNXab6CAwUCWMzgt42eBvea7r+28prBXUYgimXDLuMJX/jLRW fuP06PgqtJA8eQ2c8ECAKnL7JoTdE7hRBK1MT47+tEgvMdU0gN38CLxOz BGABlzTO/bCuRS+bwqJ3U932jkkzJkCy5Fmw9xcQl4FNli98QpulV3dMB w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CVAQDlbMlZ/5JdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm8+LWRuJweDb5wSiEGIK4dQCieFFAIahB1XAQIBAQEBAQJrKIUYAQEBAQMjVhACAQgOAwMBAigDAgICHxEUCQgCBA4FiU9MAxUQp3mCJyeHEw2DWAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyuCAoM4KwuCcoJeU4FyFoJdL4IxBZhNiBY8Aodbg1yEKoR5ghOJbYcGjGaIMwIRGQGBOAFXgQ54FVsBhQccgWd2BYgTK4EFgRABAQE
X-IronPort-AV: E=Sophos;i="5.42,437,1500940800"; d="scan'208,217";a="8506957"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 20:55:40 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8PKtdf0022310 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 20:55:40 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 15:55:39 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 15:55:39 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Roman Shpount <rshpount@turbobridge.com>
CC: Tom Kristensen <2mkristensen@gmail.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>, Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis
Thread-Index: AQHS/tQqacZkSf+3+0+Qd13paCNRh6Jak8qAgGv5HgD//+/WgIAAV9qA//+vGYA=
Date: Mon, 25 Sep 2017 20:55:39 +0000
Message-ID: <B4B6DA47-A3A4-4221-969D-449E0B4E96BF@cisco.com>
References: <33AC90F8-1963-4F79-ACB2-0DB2873D5E34@cisco.com> <CAD5OKxswNRuYFt_XQZ=caDB5WQDXS27KbH3M-AxhKL9Pq0WwPA@mail.gmail.com> <CAFHv=r_AnaVtYr8PGR_E7CZarVNp_JHv-=Pv2PGRhfbR=w-YVQ@mail.gmail.com> <8B51BC6F-6DC1-4B13-A51D-5F5BA57165FC@cisco.com> <CAD5OKxuqffkEWeMgKj8k4OA_v4yebjJCY9V-ZpQmw7A7EGL5nw@mail.gmail.com>
In-Reply-To: <CAD5OKxuqffkEWeMgKj8k4OA_v4yebjJCY9V-ZpQmw7A7EGL5nw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.231.144]
Content-Type: multipart/alternative; boundary="_000_B4B6DA47A3A44221969D449E0B4E96BFciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/3RS1mrBHSG_5FGFzTNQThDynF5M>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2017 20:55:44 -0000

From: Roman Shpount <rshpount@turbobridge.com>
Date: Monday, September 25, 2017 at 3:45 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Tom Kristensen <2mkristensen@gmail.com>, Tom Kristensen <tomkrist@cisco.com>, Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4583bis

On Mon, Sep 25, 2017 at 4:30 PM, Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> wrote:
This section specifies that "This implies that unless a 'fingerprint' attribute is included in the session description, the certificate provided at the TLS-/DTLS-level MUST either be directly signed by one of the other party's trust anchors or be validated using a certification path that terminates at one of the other party's trust anchors [5]". I thought "fingerprint" attribute are required and certificate signature by trust anchor is irrelevant.

Not sure what "When using UDP, the procedure above was preferred since it adheres to [16] as used for DTLS-SRTP" means, especially since [16} is not specific to SRTP-DTLS, but specifies generic rules for all DTLS based protocols. The whole logic is circular since it proposes to follow procedures from [16] since they are compliant with procedures from [16].

TK: I'm currently trying to remember the background for this text, it was altered and added in one of the many rounds earlier on. I agree that this is not clear and a bit confusing.
[cue] After consulting the archives, it seems this was introduced in version -04 of the draft as a result of an issue raised by Gonzalo.
https://mailarchive.ietf.org/arch/msg/bfcpbis/emDvYolUyI4VjEiVuBqNoWMgz40/?qid=0e356a8b7a948f87669c6d992f6214db


The current text read like this "When DTLS is used with UDP, the requirements specified in Section 5 of [16] MUST be followed". In the following paragraph this is explained saying "When using UDP, the procedure above was preferred since it adheres to [16] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs". I am not sure why this explanation is needed, since it essentially says that procedure from DTLS-SDP draft is used since it is compatible with procedure from DTLS-SDP draft.

I think the second sentence can be rewritten to say: "When using UDP, procedure defined in [16] was selected in order to be compatible with other DTLS based protocol implementations, such as DTLS-SRTP. Furthermore, procedure defined in [16] does not overload offer/answer semantics and works for offerless SIP INVITE in scenarios with B2BUAs.

Regards.
_____________
Roman Shpount

[cue] Looks good to me, though I suggest replacing “procedure” with “the procedure” both places it appears.

Cheers,
Charles