Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06

Alissa Cooper <alissa@cooperw.in> Wed, 21 December 2016 15:50 UTC

Return-Path: <alissa@cooperw.in>
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 EB63B1296F7 for <bfcpbis@ietfa.amsl.com>; Wed, 21 Dec 2016 07:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=rsP1bSvX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=I30i4jUR
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 DX4vG_wks2kR for <bfcpbis@ietfa.amsl.com>; Wed, 21 Dec 2016 07:50:43 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574E312958C for <bfcpbis@ietf.org>; Wed, 21 Dec 2016 07:50:43 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C72B220C2C; Wed, 21 Dec 2016 10:50:42 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 21 Dec 2016 10:50:42 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=vOZI7niVFUpApSo gbVprqeuIzo0=; b=rsP1bSvXjiK9fj3xL3kVid5IXWEt2JZUFlU8ql+XOck5AhV pYupZeFEiiLcbKykEWgbreF256gMs61Dn0Jllm6e1ZGy7JVMdDJ0forBSbmvxD6J LniHadWjUN/79KxiCboi1BfZ+P4aRPqmG+zDyl7l3P9nG5pwIW+W2yUFIW7M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=vOZI7niVFUpApSogbVprqeuIzo0=; b=I30i4jURT9JP3SKkt/zm nZxrJD/SqRor979K3uXKttGO4RRxZ/2Yb4Ag0clgPfvNQBm/G2+76JzjwBsH4LGX 7iuUHPPGD578QCS/xc6JimlebLBsHaXhiyonvp8yMaWL1Te0JzgUHGfu+ayt7uhA 0Jr5RZBmi3TnGGuChPByntc=
X-ME-Sender: <xms:0qRaWPQVMfpDMcggS6VAnoc5FFspEMcpbKQz0qp3SPjCN6UY5c_bNw>
X-Sasl-enc: XhSgqhCbi64ZwWFxP3B3Sjqq0N8vrDlV89Vcre/odR6f 1482335442
Received: from sjc-alcoop-8812.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 0395C243CF; Wed, 21 Dec 2016 10:50:41 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <A1316C49-E517-49BF-A55A-145976651E63@cisco.com>
Date: Wed, 21 Dec 2016 10:51:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <83516D34-D1DA-413F-A474-46D2B555C783@cooperw.in>
References: <DDFDCD0B-AD0E-41AF-B6C8-9D29F6B10823@cooperw.in> <A1316C49-E517-49BF-A55A-145976651E63@cisco.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/Y6lpoM6GeEIHWOZZkziMtUf_O1k>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Dec 2016 15:50:45 -0000

Hi Ram,

> On Dec 21, 2016, at 1:51 AM, Ram Mohan R (rmohanr) <rmohanr@cisco.com> wrote:
> 
> Hi Alissa,
> 
> Thanks for your feedback. Please see inline
> 
> -----Original Message-----
> From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Alissa Cooper <alissa@cooperw.in>
> Date: Saturday, 10 December 2016 at 1:08 AM
> To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
> Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-sdp-ws-uri-06
> 
>    I have reviewed this document in preparation for IETF last call. I have a couple of comments to discuss before issuing the last call. I’ve also included some nits below that should be resolved together this IETF LC comments.
> 
>    Substantive comments:
> 
>    = Section 1 =
> 
>    "In most cases it is not viable for certificates signed by well known
>       authorities."
> 
> <Ram> This text was added to indicate that it is not always possible to get the certificates signed by well known authorities. 

Your response says the same thing that the document says, which doesn’t explain why this claim is being made or why it is even being discussed in this paragraph. I actually don’t really understand what the first half of the this paragraph has to do with the second half. It would make sense to me if the paragraph started with “For applications that use Session Description Protocol (SDP) …” without the first three sentences. To go through sentence by sentence:

"As defined in Section 3 of [RFC2818], when using Secure WebSockets
   the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
   [RFC6101] certificate MUST match the WebSocket connection URI host.”

First, nothing about the WebSocket connection URI is defined in RFC 2818, so that citation is misplaced. Also, why is this document stating a normative requirement about all secure websockets?

"In most cases it is not viable for certificates signed by well known
   authorities.”

This sentence is provided without qualification — why is this the case?

"Thus, there is a need to indicate the connection URI
   for the WebSocket Client.”

This doesn’t follow from the previous sentence. If it is true that certificates to be used for secure websockets are not signed by well-known authorities, why would that imply a need to express the connection URI some other way? A self-signed cert would still give a CNAME, wouldn’t it?



> 
>    I don't understand what this sentence means.
> 
>    = Section 5 =
> 
>    "If there are
>       multiple records returned for the connection URI in the "a=wss-uri"
>       or "a=ws-uri" then the clients MAY use procedures in Section 4 of
>       [RFC6555] to attempt the connection towards the server."
> 
>    I'm confused about this. Why would there be multiple URIs? This isn't explained anywhere in the document. (Furthermore, I don't understand the comment from Dan Wing that was the origin of this text, I think. I thought the point of all of this work is to take advantage of the underlying WebSocket to send BFCP messages, so wouldn't DNS resolution be handled by the HTTP stack on the client?)
> 
> <Ram> Yes this text was added based on feedback from SDP directorate. I think you have a valid point that the DNS resolution may be taken care at HTTP stack and the procedures in RFC6555 may be used at that level.   In that case this text may not fit well in here.   Do you want me to remove this from the doc  ?

If the text stays in, it needs to be clarified. Or if you think you don’t need it, it can be taken out.

> 
>    = Section 6 =
> 
>    "Consequently, it is strongly
>    RECOMMENDED that integrity protection be applied to the SDP session
>    descriptions. For session descriptions carried in SIP [RFC3261], S/
>    MIME is the natural choice to provide such end-to-end integrity
>    protection."
> 
>    Is this just suggesting S/MIME to have nice words in the text, or do you expect to see implementations using S/MIME to protect their SDP bodies?
> 
> <Ram> I have not seen many implementations use S/MIME. Most of them use SIP over TLS (even though it may not provide e2e security) in case they need to protect the SIP/SDP

Then I would suggest s/is the natural choice/is available/

Thanks,
Alissa

> 
> Will take care of the NITS below.
> 
> Thanks,
> Ram
> 
>    Nits:
> 
>    = Section 1 =
> 
>    OLD
>    As defined in Section 3 of [RFC2818], when using Secure WebSockets
>       the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
>       [RFC6101] certificate MUST match the WebSocket connection URI host.
> 
>    NEW
>    When using Secure WebSockets
>       the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
>       [RFC6101] certificate MUST match the WebSocket connection URI host (see Section 3 of [RFC2818]).
> 
>    = Section 5 =
> 
>    s/on Internet/on the Internet/   
> 
>    s/ports (80 or 443)/port (80 or 443)/
> 
>    = Section 6 =
> 
>    s/it is strongly RECOMMENDED/it is RECOMMENDED/
> 
> 
>    _______________________________________________
>    bfcpbis mailing list
>    bfcpbis@ietf.org
>    https://www.ietf.org/mailman/listinfo/bfcpbis
> 
>