From nobody Mon Mar 4 13:43:35 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF21310D6; Mon, 4 Mar 2019 13:43:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-rtcweb-security@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155173579996.5114.17917347453427376685.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 13:43:19 -0800 Archived-At: Subject: [rtcweb] Alissa Cooper's Yes on draft-ietf-rtcweb-security-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 21:43:20 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-rtcweb-security-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- PS seems like the appropriate status for this document given its role in the WebRTC document suite. = Section 4.1.4 = "The attacker forges the response apparently http://calling-service.example.com/ to inject JS to initiate a call to himself." --> This doesn't read correctly. = Section 4.2.4 = It seems like this section should reference draft-ietf-rtcweb-ip-handling. From nobody Mon Mar 4 19:49:36 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21211130EFF; Mon, 4 Mar 2019 19:49:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155175776713.5285.18251842172477983665.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 19:49:27 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 03:49:27 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? §7.1.4, SDP example: We just had a report against draft-ietf-mmusic-sdp-simulcast claiming that putting "t=" after "c=" is not legal. 4566 and 4566bis seem to support that. (I realize that, if that's in fact an error, we've got it all over the place.) (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. From nobody Mon Mar 4 19:55:58 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC92130F08; Mon, 4 Mar 2019 19:55:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-security@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155175814957.5184.10462812445955598264.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 19:55:49 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 03:55:50 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I disagree that this should be informative. It does have sections that have informational content, but it also has sections that serve as security considerations for WebRTC as a whole. (nit) §4.2.1: Please expand ICE on first mention. From nobody Mon Mar 4 19:59:53 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22073130EF2; Mon, 4 Mar 2019 19:59:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 19:59:45 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 03:59:45 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja that this reads more like a BCP. Was BCP status considered by the WG? (nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." §11.2: It seems like the references for STUN and TURN should be normative. From nobody Mon Mar 4 20:45:07 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88407130F30; Mon, 4 Mar 2019 20:45:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 20:45:00 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:45:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example: (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. From nobody Mon Mar 4 20:47:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740FE130F4F; Mon, 4 Mar 2019 20:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 T1r58lzhYC-N; Mon, 4 Mar 2019 20:47:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F659130F30; Mon, 4 Mar 2019 20:47:07 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x254l4JT098191 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Mar 2019 22:47:06 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551761226; bh=7QAm3uoPdCfcNCdffSp+TeGaGfv5UC2pfK+1dikj9/Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iVSs1G+RVUAxcAc8lE6mEARk4xN6Px+8T4rhE/FYFMLD8P2lN8p5MaePlmcaunhX2 6LyRMbb0mM81eJGu3eepdCRD4qwmzuI0yG9vpPd7RTC3O/MVmLTLirylSIj+Kh0Sso n6WtVhu1Fu57HWMkNWCW3oWFoYChr8dRn/Kexg0Q= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Ben Campbell , The IESG Cc: rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, draft-ietf-rtcweb-security-arch@ietf.org References: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <5513d875-4dc0-8f3f-086e-85a4b2ee5d6c@nostrum.com> Date: Mon, 4 Mar 2019 22:46:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:47:09 -0000 On 3/4/19 10:45 PM, Ben Campbell wrote: > Update: Ignore my comment about t= vs c=0. I had my order crossed; it is > correct in the example. This is true; however, t= versus a= is, indeed, backwards. /a From nobody Mon Mar 4 20:49:06 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E342130F4F; Mon, 4 Mar 2019 20:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 ZPJj2azxXXo8; Mon, 4 Mar 2019 20:49:03 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159CD130F4D; Mon, 4 Mar 2019 20:49:03 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x254mx8C098561 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Mar 2019 22:49:01 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551761342; bh=N2u9utvzYr7oa9dXdF+37T/9kaQs/u21u7NvzSVLzUo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Rr4DOpcTAvIyTRbXT5bTBI3R6S1mO8SOwEpSvr89K7grzVnrebA0EoDiuHri8jggJ Sgfhv6Ric1DUAx4QMhDrmlJKDr5M5uT13iI4CwFcEpDKPnLKRzmD3agJ4qYw4xY3wI gtvMQfJyNbXpreqmtLC4Qif+4fUFAGwKpTh84dUQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <84B447CF-0662-4CD3-B92E-AC14321B822B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AD065F97-0DBF-4E79-9B85-1DB8DFE8510D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 4 Mar 2019 22:48:53 -0600 In-Reply-To: <5513d875-4dc0-8f3f-086e-85a4b2ee5d6c@nostrum.com> Cc: The IESG , rtcweb-chairs@ietf.org, RTCWeb IETF , Sean Turner , draft-ietf-rtcweb-security-arch@ietf.org To: Adam Roach References: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> <5513d875-4dc0-8f3f-086e-85a4b2ee5d6c@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:49:05 -0000 --Apple-Mail=_AD065F97-0DBF-4E79-9B85-1DB8DFE8510D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yep, ignore my ignoring. I knew something was wrong; I just confused = myself :-) I can see why we keep messing this up, it=E2=80=99s nigh impossible to = keep the order in my head more than a few minutes. > On Mar 4, 2019, at 10:46 PM, Adam Roach wrote: >=20 > On 3/4/19 10:45 PM, Ben Campbell wrote: >> Update: Ignore my comment about t=3D vs c=3D0. I had my order = crossed; it is >> correct in the example. >=20 >=20 > This is true; however, t=3D versus a=3D is, indeed, backwards. >=20 > /a >=20 --Apple-Mail=_AD065F97-0DBF-4E79-9B85-1DB8DFE8510D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlx9/7UACgkQgFZKbJXz 1A1aXA/8CeVbM19gMEgPX6xdMGx/+ggsh6Ei/OWaNlwT0cPgsPdZ6kFlCysqDQBx NKA8L3YZMPg0K1I7X1z+Zts1QKFiAmkrBGuChB9Au5KQHUEx+yDDA2HWY2XL6iYJ enRjP4qyd9gQMLRSOKAuVOwC6/5ymI+TVd2yGAPieF/UJuTuJ7MLiNWiqwjPQXZJ UR0XXqXi9lBllG3mGkYcTs3wKBoTOkwt5Alppn8qLB1abrv6aPwlj63mq4pa9zt3 mMgkuyKYe6nk53ineLmDA1av+MLy2Ak70WD2tjiwOnfPfUlS0ZLwL0LedcQHYjiX U8Ud5U+0zS56j+sAbQJxp6Gi+d3pSU20YcXypYYjlvkxSDI4Wk99jxfTMVtHwGFY bC0LKEwDNxOx++zAUUEfnZqnjN7CeirtuGKqaNg0/7nGuMpM1fkpmXZXEgRUvZDl CYjLhZBZU9wqU/zcgeumS0Q6u374pk/0jcnaJrGFXDVPZxAguPUSsoJYhISTDU6X /BKjkxUktjB1UMOI4jCMu9FX2XMQmHHKl2C7hg32udUdHuS2V4GuJ1AdIF1wVTST ChlhLd8UVhgzgXs68byK67la3qPcfzuPL8qBxOMuam5cpsKSGWxGlQ92pVs9PgUy qrAjmrbCmiRIjhy5YzMSnBioKNXVqOdSa13XjL4YtdaBezOuJQU= =3T/J -----END PGP SIGNATURE----- --Apple-Mail=_AD065F97-0DBF-4E79-9B85-1DB8DFE8510D-- From nobody Mon Mar 4 20:51:26 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6861200D7; Mon, 4 Mar 2019 20:51:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155176147664.5301.15518510654719657686.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 20:51:16 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:51:17 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update to the Update: As Adam mentioned in email; while t= vs c=0 ordering is correct in 7.4.1, t= vs a= is not. (Capturing it here for the ballot record.) Update: Ignore my comment about t= vs c=0. I had my order crossed; it is correct in the example. I'm balloting "yes", but have a few minor comments and editorial comments: §1: - (nit) The first sentence will not age well; I gather RTCWEB will close before long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking about the W3C?) - (nit) Figure 2: It seems a bit weird to have XMPP here, but never mentioned in the text. At least, please expand the abbreviation somwhere. (It also shows up in figure 4.) (nit) §3.1, first bullet: While I don't normally object (beyond nose holding, anyway) to the use of first person in RFCs, it seems an odd choice for this sentence. I assume "we" in this sentence does not refer to the the author or the WG. §4.1: (nit) - '... button next to Bob’s name which says "Call".': s/which/that - "The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI." This is the first mention of "trusted UI". It would be helpful to elaborate on that prior to this mention. §5.1.4: - "In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints." Applied by the recipient? (consider active voice). Also, why not MUST? Don't unexpected things happen if the recipient doesn't do this? §6.2: - "Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins." (nit-ish) - The MUST NOT seems non-constraining considering the last sentence. Or am I reading that sentence wrong? (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. (nit) - ".. unlikely that browsers would have an X.509 certificate..." : Plural disagreement (assuming the browsers do not share 1 cert). (maybe nit) - "Clients MAY permit the formation of data channels without any direct user approval." Is the switch from talking about "the browser" to "Clients" intentional? §6.4: (nit) - "Note that these requirements are NOT intended..." "NOT" in all caps is likely to be confused with 2119/8174 language. §6.5: (nit) - "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [RFC8261]." Thank you for using the citation style that doesn't assume everyone has memorized the RFC numbers. But why not do the same for 8261? §7.2: (nit) - First paragraph: Can there be a citation for the W3C API spec? (My bad, the draft is correct. Comment removed.) §7.1.4, SDP example: (nit) §11: The first sentence is a fragment. §13.1 (normative references) (nit) - There's a reference to RFC 5234, but it is not cited in the text. - Is there a reason to reference 5246 rather than 8446, which obsoleted it? §13.2: - seems like the jsep reference should be normative. From nobody Tue Mar 5 01:52:55 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2075E13105D; Tue, 5 Mar 2019 01:52:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2019 01:52:48 -0800 Archived-At: Subject: [rtcweb] Alexey Melnikov's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 09:52:53 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for a well written document! My apologies for filing a procedural DISCUSS on this, but I am looking at: 7.5. Determining the IdP URI 3. The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol. Note that the separator characters '/' (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, lest an attacker be able to direct requests outside of the controlled "/.well-known/" prefix. Query and fragment values MAY be used by including '?' or '#' characters. "idp-proxy" is not registered in the IANA's registry and this document doesn't register it either. If I missed where this is registered, please point me to the right document. If I haven't, please register it in this document. From nobody Tue Mar 5 01:54:13 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E442131022; Tue, 5 Mar 2019 01:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gX38n5vEDNYC; Tue, 5 Mar 2019 01:54:08 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACC8131026; Tue, 5 Mar 2019 01:54:07 -0800 (PST) Received: from sessfw99-sesbfw99-92.ericsson.net ([192.176.1.92] helo=[10.156.247.140]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h16lw-0004TD-Nd; Tue, 05 Mar 2019 10:54:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Tue, 5 Mar 2019 10:52:01 +0100 Cc: draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, RTCWeb IETF , The IESG , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: References: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1551779647;36c597b7; X-HE-SMSGID: 1h16lw-0004TD-Nd Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-rtcweb-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 09:54:12 -0000 Hi Ekr, see below. > Am 28.02.2019 um 22:22 schrieb Eric Rescorla : >=20 >=20 >=20 > On Thu, Feb 28, 2019 at 10:00 AM Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-rtcweb-security-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I think this document is clearly informational. Other RTCweb documents = should > refer this document informatively and only reference the sec arch doc > normatively. >=20 > I don't feel strongly one way or the other. I will defer to the AD. I will wait for more feedback from other ADs and then clear my discuss = respectively. However, to be honest I also don=E2=80=99t quite fully = understand the split between this doc and the sec-arch one. But maybe = that just me... >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I would have also expected some discussion about the risks to the user = if the > browser gets corrupted, as indicated by the trust model presented in > draft-ietf-rtcweb-security-arch. Alternatively, this document could go = in the > appendix of draft-ietf-rtcweb-security-arch instead. >=20 > Hmm... We generally assume that the browser is uncorrupted. If it is, = it's pretty much game over. Can you explain more about your position.=20 My thinking here is that the security consideration should usually = mention potentially attacks. First the whole document assumes that the = browser is not corrupted but never says that. So it would help if this = document would also mention the trust model as explicitly described in = the sec-arch doc or refer to it. But then I also thought that it could = be good to say more about what =E2=80=9Egame over=E2=80=9C means. Which = information could or would be lost in danger. I understand that if an = attacker has full control over the blower it can basically display = anything, however, I was wondering if it would be possible to say more = than that. Maybe there are part that can be easier hack than others=E2=80=A6= anyway was just a thought. From nobody Tue Mar 5 06:31:44 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE02D13128F for ; Tue, 5 Mar 2019 06:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 fOnn_bGyVB38 for ; Tue, 5 Mar 2019 06:31:37 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6779131140 for ; Tue, 5 Mar 2019 06:31:34 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q128so7760186ljb.11 for ; Tue, 05 Mar 2019 06:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6wrQkrS0IhxEX6SQyT51xWOzGnfaTzXvWvt6RRV4ZME=; b=ThXeEohsZGdyD0IJczv+G+OYSbwLgL5NWdoIZi22XPC0Y2xvCZO9SA8MghAzd1TsOX GVVhMaVXNujJ851UzHb4ea9mH+2IJSBC3A1cF3yYerfw1lvnK4bIJIlB/KLzlWRASBbk U5PGAW4oF7DBEFR2W2VV5rc+aFsujMeHyceHncnQvmAcmpczMoWHnutCa+Uo2QR/9xA+ EQfbs7Mwd/HJ/kxTQRtxT/V9ZhvW54KRxJmIQcRRN+E483Cfsd8fCsoi1CWyAoj7HIR4 iHyTw6wu86y6IFpN+yOQYR39I7D5AtXhCipCI2sHTLLYT6liRJBuwzBEG0cANEMmac5d qHQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6wrQkrS0IhxEX6SQyT51xWOzGnfaTzXvWvt6RRV4ZME=; b=YVYqIrTB/j2jV4z5Fvyryrrj0kqYg6tauXclOojADPbAvwu/w9I3oT5bBfVd+7TyDf MG/RH3iUdhcEHvPAGWvFSgqB9RxoEUPSelCPMqwCL2UJ0u/cfHv3VYE3Uk+y88FI/Z2/ OO5HomtH2Hrat4u/jyaneJPsNbZYJlxIIavc/D/RIa+rUOIQWF6TMsjzHjlKb5zzAkI3 raxD1KZNznC6BHZFDygMQZInvYUw3H6S5lx/qSrh8piGZqi8LZe0YVgtHSMLyorHEW1l IMmHt3MUL0m/lUWb2VlCXXdzEFJ5F7dwOoyb+uQaxoMjO5BNfGOjColAOn4JXA2WWatu Qjvw== X-Gm-Message-State: APjAAAX+j+4g4B20tbNUM7Z++iGkImebFS5XhLiL0RkqX2L8yakZmbwV ZowH9iLSfYK7GL5G3RY8KPeIdNarTf+AHEHgcsNK3w== X-Google-Smtp-Source: APXvYqxgMSGaI1Ddp5mIRiCj998PiSATJ1T6Z8gMq8sa7gv32wTl61r19oxOc5j2jejZE+EncDC9/h5/qVpL5zN4zW4= X-Received: by 2002:a2e:a28f:: with SMTP id k15mr14173841lja.160.1551796292538; Tue, 05 Mar 2019 06:31:32 -0800 (PST) MIME-Version: 1.0 References: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Tue, 5 Mar 2019 06:30:55 -0800 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, RTCWeb IETF , The IESG , Sean Turner Content-Type: multipart/alternative; boundary="000000000000c7eb8d058359bac9" Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-rtcweb-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 14:31:41 -0000 --000000000000c7eb8d058359bac9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2019 at 1:54 AM Mirja Kuehlewind (IETF) wrote: > Hi Ekr, > > see below. > > > Am 28.02.2019 um 22:22 schrieb Eric Rescorla : > > > > > > > > On Thu, Feb 28, 2019 at 10:00 AM Mirja K=C3=BChlewind > wrote: > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-rtcweb-security-11: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think this document is clearly informational. Other RTCweb documents > should > > refer this document informatively and only reference the sec arch doc > > normatively. > > > > I don't feel strongly one way or the other. I will defer to the AD. > > > I will wait for more feedback from other ADs and then clear my discuss > respectively. However, to be honest I also don=E2=80=99t quite fully unde= rstand the > split between this doc and the sec-arch one. But maybe that just me... > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I would have also expected some discussion about the risks to the user > if the > > browser gets corrupted, as indicated by the trust model presented in > > draft-ietf-rtcweb-security-arch. Alternatively, this document could go > in the > > appendix of draft-ietf-rtcweb-security-arch instead. > > > > Hmm... We generally assume that the browser is uncorrupted. If it is, > it's pretty much game over. Can you explain more about your position. > > My thinking here is that the security consideration should usually mentio= n > potentially attacks. First the whole document assumes that the browser is > not corrupted but never says that. This is an explciit part of the RFC 3552 threat model. https://tools.ietf.org/rfcmarkup?doc=3D3552#section-3 The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. Protecting against an attack when one of the end-systems has been compromised is extraordinarily difficult. It is, however, possible to design protocols which minimize the extent of the damage done under these circumstances. So it would help if this document would also mention the trust model as > explicitly described in the sec-arch doc or refer to it. We would then have to change every document we write to say this, I should think. -Ekr But then I also thought that it could be good to say more about what =E2=80= =9Egame > over=E2=80=9C means. Which information could or would be lost in danger. = I > understand that if an attacker has full control over the blower it can > basically display anything, however, I was wondering if it would be > possible to say more than that. Maybe there are part that can be easier > hack than others=E2=80=A6 anyway was just a thought. > > > --000000000000c7eb8d058359bac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 5, 2019 = at 1:54 AM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Ekr,

see below.

> Am 28.02.2019 um 22:22 schrieb Eric Rescorla <ekr@rtfm.com>:
>
>
>
> On Thu, Feb 28, 2019 at 10:00 AM Mirja K=C3=BChlewind <ietf@kuehlew= ind..net> wrote:
> Mirja K=C3=BChlewind has entered the following ballot position for
> draft-ietf-rtcweb-security-11: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dr= aft-ietf-rtcweb-security/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I think this document is clearly informational. Other RTCweb documents= should
> refer this document informatively and only reference the sec arch doc<= br> > normatively.
>
> I don't feel strongly one way or the other. I will defer to the AD= .


I will wait for more feedback from other ADs and then clear my discuss resp= ectively. However, to be honest I also don=E2=80=99t quite fully understand= the split between this doc and the sec-arch one. But maybe that just me...=
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I would have also expected some discussion about the risks to the user= if the
> browser gets corrupted, as indicated by the trust model presented in > draft-ietf-rtcweb-security-arch. Alternatively, this document could go= in the
> appendix of draft-ietf-rtcweb-security-arch instead.
>
> Hmm... We generally assume that the browser is uncorrupted. If it is, = it's pretty much game over. Can you explain more about your position. <= br>
My thinking here is that the security consideration should usually mention = potentially attacks. First the whole document assumes that the browser is n= ot corrupted but never says that.

This is = an explciit part of the RFC 3552 threat model. https://tools.ietf.org/rfcmarkup?doc= =3D3552#section-3

   The Internet environment has a fairly well understood threat model.
   In general, we assume that the end-systems engaging in a protocol
   exchange have not themselves been compromised.  Protecting against an
   attack when one of the end-systems has been compromised is
   extraordinarily difficult.  It is, however, possible to design
   protocols which minimize the extent of the damage done under these
   circumstances.


So it would help if this document would = also mention the trust model as explicitly described in the sec-arch doc or= refer to it.

We would then have to change= every document we write to say this, I should think.

<= div>-Ekr

But then I also thought that it could be good to say more about what = =E2=80=9Egame over=E2=80=9C means. Which information could or would be lost= in danger. I understand that if an attacker has full control over the blow= er it can basically display anything, however, I was wondering if it would = be possible to say more than that. Maybe there are part that can be easier = hack than others=E2=80=A6 anyway was just a thought.


--000000000000c7eb8d058359bac9-- From nobody Tue Mar 5 12:22:42 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4F1277D2 for ; Tue, 5 Mar 2019 12:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 A85QS2rhOVJJ for ; Tue, 5 Mar 2019 12:22:39 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BFE126C15 for ; Tue, 5 Mar 2019 12:22:39 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id w18so6030146itj.4 for ; Tue, 05 Mar 2019 12:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=X4/n6GAC0E8dZLqRPQRqPk7zSBWLFbFjlz+athFGphM=; b=VP9FhyVxHzUx3VTKe4ut4at66x2cJ45ErnFutw9PHTkIPrLKCu1xHTgchcl5Qy8mAJ d4V3bDMOOkP2cx1yxtreOAW2/EoZjpZ1ZenfGllgJytYfiBekjZOHGYYyAW2K1rW1it6 U4mYXJoD7DiAmwvso6o11yTxJO/IhcVkxcE24S6E5plwgYN01aMXDcTD9tDNHyVqVM0K TCcNqRgJB5U0sBCQEdUIyCHSogoGeRwWOZjwO47aQZ7rGnKhm/SwN2KFaPePrcKAmsnU psfYMqnR/Siske6CRT4tyfKTOR0331eySsP1lgDg1N1Zf4mdyuwNcuizprYriz2lTDwY +krw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=X4/n6GAC0E8dZLqRPQRqPk7zSBWLFbFjlz+athFGphM=; b=aRgRnfxb/nWUvtQ9WJjzBr/nN90Jh+UEB1tUxfF2Mxi1rOhMH/2tBynK2zHuRoQYHR g/JoC10/K9hvL4TeRjTh54MpOcseEyHi9AZ+blcOKLNIatCuY6pbflHAtgPWuxf5+7ZB nw/ytC4KxzU82SK9Ya/dgCZ/oYQFRmyZ1kV8aBRB9mzFHss/TyDmTTKRDGydzYFqpGAw 3bWWuj2RdQfyGjKG7pMV44gbNXXKmIwRxtYt1DiFR+YlnwyxgqlGygd23XYClaHd0ZAc U4miJ8DDqdzt6KxWymjOZ9biW7WXN2UQqIe47EMmRbpEjXSjzIue4PhwmbzN3mPHK+VT Y6vg== X-Gm-Message-State: APjAAAXnfkUunC87w6wrwUWBn544I9jM8F+1J44RXgxE8NyVmopS1TIb wdeTC4ndFz5IpG/4Uw5dDud6srHopS2Fu7kWtJ9aP36JhYE= X-Google-Smtp-Source: APXvYqynqn9sK1fjBHeu6IHbaWaieTeBTZ+c1Y4wO+WAh/9fXh6XagUxatLklB8dVBnLPxJdy9McdEnCPwUYetwFCTg= X-Received: by 2002:a24:1745:: with SMTP id 66mr113620ith.96.1551817358210; Tue, 05 Mar 2019 12:22:38 -0800 (PST) MIME-Version: 1.0 From: Ted Hardie Date: Tue, 5 Mar 2019 12:22:11 -0800 Message-ID: To: RTCWeb IETF , Adam Roach , Sean Turner Content-Type: multipart/alternative; boundary="000000000000647a5f05835ea2e7" Archived-At: Subject: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:22:41 -0000 --000000000000647a5f05835ea2e7 Content-Type: text/plain; charset="UTF-8" Howdy, draft-uberti-ip-handling-ex- mdns is a very short draft describing two new modes related to draft-ietf-rtcweb-ip-handling using bits of draft-ietf-rtcweb-mdns-ice-candidates . The chairs would like to ask for a couple of reviews; given that it is four pages long, we are hopeful that it will not take much time. Please send your review to the list, thanks, Ted --000000000000647a5f05835ea2e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

draft-uberti-ip-h= andling-ex-mdns is a very short draft describing two new modes= =C2=A0 related to draft-ietf-rtcweb-ip-handling using bits of draft= -ietf-rtcweb-mdns-ice-candidates.

The chairs w= ould like to ask for a couple of reviews; given that it is four pages long,= we are hopeful that it will not take much time.

P= lease send your review to the list,

thanks,
<= div>
Ted
--000000000000647a5f05835ea2e7-- From nobody Tue Mar 5 12:58:01 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1813131D for ; Tue, 5 Mar 2019 12:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 uVKHKIElVPxp for ; Tue, 5 Mar 2019 12:57:57 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE2E1312F7 for ; Tue, 5 Mar 2019 12:57:56 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id u9so6466364pgo.7 for ; Tue, 05 Mar 2019 12:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FBMJ8ytkYrbMakmqEhLsCDgg4C954ftVZasDTlki4n0=; b=BVbDlaravvHx+rmE7bGeJce0bviZ2LRE5pWMk9PZJ1KeqhyVSwpZDQNTSkYMa6YDP1 lvlfa10cMEayZXSX6K2Vltp9I01V86oYIVG9UGr47FIXgFOW9Pw2zrWmLbbR1gFu8HDX kEQAUUwj/5MPKI59pt1w3+emxqZgAEG9b5F4cqnz95atbuzqia4whVmTQclvArTy69ec 6G2M/CBfsRrL9cNuGuClRuV9Rajth7g6Gw7kBwvVoKR1diDQfMGlJx3xc0s23gcvCQzY XQrkHZLMX6NUBgcYaEDpc6SWFi7ZO2zAQRD2s/dsJykLbBgWXyAywjYaeDgXA+J6SNeb E5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FBMJ8ytkYrbMakmqEhLsCDgg4C954ftVZasDTlki4n0=; b=NXWYUkTa3AiMOP2AeJAWyBzzoRAc6+be+KgiLHjDwmmN+YT4IxS+Yo70oLh8qer0bH 71DpI0Zm83ADVduPdggF/9ODOnony39nv8IkQKxgn3RUkv/gTtX4/90HT6rDgbhKo0Da plX76JcjUN86lEmrGOHbmDo2Kxf43MCdeBnzlPJoi7fDuP2ZS9cBLw5CyNsE5M/Q2vK7 A9tAXK9wxkBNJzLyf8wGGeUSc3b3iig4dJpHUupwW4KFGhJBKjklCuMWXhAxojeEFuYa VLSYzzUJ86vbIKYSE6OhNH3VmfzxJRjmaHNG11eH8BocNDrsNkfoOPx6D8Ups14PKIuM WKiA== X-Gm-Message-State: APjAAAXccnttExxPAjI/3vnkKiTUzLSPfXMugCEDZM3hF2Q8OD+eEP6p qFVmnsaqydZEgH7MM2mpIdjJMHTk4g0= X-Google-Smtp-Source: APXvYqx9Vs6AKRXze3J8C0bXqrb5itcwiueStWcBQakdDpVDA7LqEMEtPskjmJuWiJCxfaUeLXbwTw== X-Received: by 2002:a17:902:784c:: with SMTP id e12mr3166873pln.117.1551819476088; Tue, 05 Mar 2019 12:57:56 -0800 (PST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com. [209.85.215.181]) by smtp.gmail.com with ESMTPSA id e9sm25623659pfh.42.2019.03.05.12.57.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 12:57:55 -0800 (PST) Received: by mail-pg1-f181.google.com with SMTP id h8so6470846pgp.6 for ; Tue, 05 Mar 2019 12:57:55 -0800 (PST) X-Received: by 2002:a17:902:29cb:: with SMTP id h69mr839177plb.277.1551819474937; Tue, 05 Mar 2019 12:57:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 5 Mar 2019 15:57:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: RTCWeb IETF , Adam Roach , Sean Turner Content-Type: multipart/alternative; boundary="0000000000008f2cfc05835f20c0" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:58:00 -0000 --0000000000008f2cfc05835f20c0 Content-Type: text/plain; charset="UTF-8" I have reviewed draft-uberti-ip-handling-ex-mdns and as far as I can see it looks good. One comment that I have is that handling of RFC4941 IPv6 addresses in mode 2.1 is different from what is described in draft-ietf-rtcweb-mdns-ice-candidates . This ideally should be updated in draft-ietf-rtcweb-mdns-ice-candidates to allow skipping generation of mDNS names for RFC4941 IPv6 addresses. On the related note, draft-ietf-rtcweb-mdns-ice-candidates probably should go into ICE working group or at least be reviewed there. This draft is not RTCWeb specific and is closely related to ICE. Regards, _____________ Roman Shpount On Tue, Mar 5, 2019 at 3:22 PM Ted Hardie wrote: > Howdy, > > draft-uberti-ip-handling-ex- > mdns > is a > very short draft describing two new modes related to > draft-ietf-rtcweb-ip-handling > using bits of > draft-ietf-rtcweb-mdns-ice-candidates > . > > The chairs would like to ask for a couple of reviews; given that it is > four pages long, we are hopeful that it will not take much time. > > Please send your review to the list, > > thanks, > > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000008f2cfc05835f20c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed =C2=A0draft-uberti-ip-handling-ex-mdns and= as far as I can see it looks good.=C2=A0

One comment th= at I have is that handling of RFC4941 IPv6 addresses in mode 2.1 is differe= nt from what is described in=C2=A0draft-ie= tf-rtcweb-mdns-ice-candidates. This ideally should be updated in=C2=A0<= a href=3D"https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates= " style=3D"font-size:13.3333px">draft-ietf-rtcweb-mdns-ice-candidates= =C2=A0to allow skipping generation of mDNS names for RFC4941 IPv6 addresses= .

On the related note, draft-ietf-rtcweb-mdns-ice-candid= ates probably should go into ICE working group or at least be reviewed ther= e. This draft is not RTCWeb specific and is closely related to ICE.

Regards,
_____________
Roman = Shpount


On Tue, Mar 5, 2019 at 3:22 PM Ted Hardi= e <ted.ietf@gmail.com> wrot= e:
Howdy,

draft-uberti= -ip-handling-ex-mdns is a very short draft de= scribing two new modes=C2=A0 related to draft-ietf-rtcweb-ip-h= andling using bits of draft-ietf-rtcweb-mdns= -ice-candidates.

The chairs would like to ask = for a couple of reviews; given that it is four pages long, we are hopeful t= hat it will not take much time.

Please send your r= eview to the list,

thanks,

Ted
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000008f2cfc05835f20c0-- From nobody Tue Mar 5 13:10:45 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4926B130E5B for ; Tue, 5 Mar 2019 13:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=sB3kqLPr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jSG9meZE 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 THDR0-Y7jOOB for ; Tue, 5 Mar 2019 13:10:41 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C262131065 for ; Tue, 5 Mar 2019 13:10:40 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3FBD821AB8 for ; Tue, 5 Mar 2019 16:10:39 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Mar 2019 16:10:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type; s=fm1; bh=xuC5gp18wdwEOHtLypWRLDeMZ1uPCgm/EKe4c6+ B3aQ=; b=sB3kqLPrruA6wwaqshNM/L8CLg+accBKLb7ogxHwcqnDVUnzAhn1Rki skRrBBNXY4iWE2k1+yeTCyp9Wm6q/IR79Dk3Sur6Mxpg54koqUOPwGMJJVjgG/fO 6YS2aYLAhBnw11H5/ko6iNJvEHmO3re7UBY4J3CleJ+2ejz0ZlASlMp1S6C3x5Uc sFyZmYIgtpJPCr2gU05q2XO+rKXj/UMYq+KTPzFFfnJXS87bc8nQnGSQjupbxdFx cNjbm8ZtHzbGym10AwlzyrWqKsAb1s5HKg2zRLVXDzm5rvDOYDnTuM793cHyBsxt 7UPJPj1sU+Eb7rycXyV/O5viwBOAlsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xuC5gp18wdwEOHtLy pWRLDeMZ1uPCgm/EKe4c6+B3aQ=; b=jSG9meZE1q+gEfFQQi2Pn+YWCWwZb25PL fYlx29sup5wr2z3P23tUM6TSvU/a6DV1hIHtIiKHtLwF7tur6SMr4+jhwDDNJxZU VNoGRkhO3WObzTEBCwLo6ag0zC38PhX7/c4Xm+rdoUY24qUKLvQ+uGpS1+kBi3o2 +iLSSmoox0Zw7dDUQ7zEleereSpOxpQvqXsnI/wwdgXQYmtw3+49ICc5v9Nm1F6V 0BxHbkdko/gCyzZubqu4/ySkz2h5MBUd4eTmrbbGwgMQqcP1N7t4ZGT5orMbRGW1 N/cTaQ8b/U2YIBoqm0V8LBcBHQGHf7B3b7lewTk/HG+cN3TdxD6qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeefgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C06F97C3AB; Tue, 5 Mar 2019 16:10:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 92534000 Message-Id: <811b3bb7-8458-4790-b5af-7c4faedc133a@www.fastmail.com> In-Reply-To: References: Date: Tue, 05 Mar 2019 16:10:38 -0500 From: "Martin Thomson" To: rtcweb@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:10:43 -0000 How is it that the two drafts this rules on are only informative references? It probably needs to update IP handling. The modes this adds are good, but it specifically states that the implications aren't known. It even promises to update the draft when that information is gained. That suggests that this doc might have an uncertain future. What is the chairs' thinking about the draft? On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote: > Howdy, > > draft-uberti-ip-handling-ex- > mdns is a very short draft describing two new modes related to draft-ietf-rtcweb-ip-handling using bits of draft-ietf-rtcweb-mdns-ice-candidates . > > The chairs would like to ask for a couple of reviews; given that it is > four pages long, we are hopeful that it will not take much time. > > Please send your review to the list, > > thanks, > > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Mar 5 13:12:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D52124D68 for ; Tue, 5 Mar 2019 13:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5db6U5n8_v0o for ; Tue, 5 Mar 2019 13:12:35 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA021288BD for ; Tue, 5 Mar 2019 13:12:34 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id p17so8288480iol.7 for ; Tue, 05 Mar 2019 13:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m0IsOqG8iW8jR1WjYZECSHV4bE+afEPZ5+ArgoZYpXs=; b=RTTttHJZ+TDMC/ZiJfphYyKbywUF08XJGLqqaat6TYcUFfN5HbbFAazQ5qq8tmTik7 O2DOZqkoNzL9ej7bm9BNXxf17UtoAyHgpIpNNQreEiMAY/tE3k/AzXlhMma1hspVI7Yo nhEqE3pG5WZGjbGKbBABC66c131jjkKTcBmMhp/i8tnsVYoeA2rhyn3wiguZAOI2xU3v 9xap45lfh13xj2RSlp/RqXiFpH615BEch2DB0aIzACl0+VLMvGGlHWwwpSSANzQmwL+8 wedHq999tndvScYP9Y7wQ/EPI2kOTe8F0Z92+kjlO4CZAQlzYhqjbtVJuA1fQRC6m552 YujA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m0IsOqG8iW8jR1WjYZECSHV4bE+afEPZ5+ArgoZYpXs=; b=ogRI559vcKQMB2SOt9xuW6rcwdjkEUC3fCfAG7wmPfKz2Ruh/t21qCk0MVRze6C6wH 8bXbUy88AoKPWAij9QCDi1fHLRX1vzozXnQI7Umnf/ZliR7EIpy4v0dOirB6Hy2wIxiC n1mpFpD8SyEjHXYXYudp/ksj0FOslZ8TkW55hGmKdEgjM09hrOH7aq24dj5IS2hHDona zBg+Lh4p21gbKK2otOVW8B/sh0zPvX1rg9Da3egmrwOHCE6iZCCFgDUF9esS5y7vAUF1 2rnn0HjRjxOAhxKTO4oTi26DK1yCTftoHoggUi3cyNNB1VDStNf1fBXos7GXEqmu4s3U 6j5g== X-Gm-Message-State: APjAAAU3lCdSr+Gh4ebszyQZAcB0tDbGSiZc4/3wWnRB8nY2xnq4qDYS 6bLgrgbee7f5s8dAbOmL8r3LiLHVp6AIjFy+qunAJA== X-Google-Smtp-Source: APXvYqwri/nWAX3BDCYOlWml7wmhOPF9GIpjlWmb4Mv7ni28SfIDl+79KrGwhQWiQxHvneL2UDZsK3iU7mMcUve+mb4= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr1167842ioh.95.1551820352865; Tue, 05 Mar 2019 13:12:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 5 Mar 2019 13:12:21 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e3bc6b05835f549e" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:12:40 -0000 --000000000000e3bc6b05835f549e Content-Type: text/plain; charset="UTF-8" Roman, was there specific text in mdns-ice-candidates that you think is contradicted by ip-handling-ex-mdns? The goal was for the former document to describe the technique and the latter to describe when it should be applied. On Tue, Mar 5, 2019 at 12:58 PM Roman Shpount wrote: > I have reviewed draft-uberti-ip-handling-ex-mdns and as far as I can see > it looks good. > > One comment that I have is that handling of RFC4941 IPv6 addresses in mode > 2.1 is different from what is described in > draft-ietf-rtcweb-mdns-ice-candidates > . This > ideally should be updated in draft-ietf-rtcweb-mdns-ice-candidates > to > allow skipping generation of mDNS names for RFC4941 IPv6 addresses.. > > On the related note, draft-ietf-rtcweb-mdns-ice-candidates probably should > go into ICE working group or at least be reviewed there. This draft is not > RTCWeb specific and is closely related to ICE. > > Regards, > _____________ > Roman Shpount > > > On Tue, Mar 5, 2019 at 3:22 PM Ted Hardie wrote: > >> Howdy, >> >> draft-uberti-ip-handling-ex- >> mdns >> is >> a very short draft describing two new modes related to >> draft-ietf-rtcweb-ip-handling >> using bits >> of draft-ietf-rtcweb-mdns-ice-candidates >> >> . >> >> The chairs would like to ask for a couple of reviews; given that it is >> four pages long, we are hopeful that it will not take much time. >> >> Please send your review to the list, >> >> thanks, >> >> Ted >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000e3bc6b05835f549e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roman, was there specific text in mdns-ice-candidates that= you think is contradicted by ip-handling-ex-mdns? The goal was for the for= mer document to describe the technique and the latter to describe when it s= hould be applied.

On Tue, Mar 5, 2019 at 12:58 PM Roman Shpount <roman@telurix.com> wrote:
I have revi= ewed =C2=A0draft-uberti-ip-handling-ex-mdns and as far as I can see it look= s good.=C2=A0

One comment that I have is that handling o= f RFC4941 IPv6 addresses in mode 2.1 is different from what is described in= =C2=A0draft-ietf-rtcweb-= mdns-ice-candidates. This ideally should be updated in=C2=A0draft-ietf-rtcweb-mdns-ice-candidat= es=C2=A0to allow skipping generation of mDNS names for RFC4941 IPv6 add= resses..

On the related note, draft-ietf-rtcweb-mdns-ice= -candidates probably should go into ICE working group or at least be review= ed there. This draft is not RTCWeb specific and is closely related to ICE.<= /div>

Regards,
_____________
Roman = Shpount


On Tue, Mar 5, 2019 at 3:22 PM Ted Hardi= e <ted.ietf@gmai= l.com> wrote:
Howdy,

draft-uber= ti-ip-handling-ex-mdns is a very short draft = describing two new modes=C2=A0 related to draft-ietf-rtcweb-ip= -handling using bits of draft-ietf-rtcweb-md= ns-ice-candidates.

The chairs would like to as= k for a couple of reviews; given that it is four pages long, we are hopeful= that it will not take much time.

Please send your= review to the list,

thanks,

<= div>Ted
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000e3bc6b05835f549e-- From nobody Tue Mar 5 13:13:44 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BBC128CE4 for ; Tue, 5 Mar 2019 13:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qPCgLJUFuRG3 for ; Tue, 5 Mar 2019 13:13:41 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35811288BD for ; Tue, 5 Mar 2019 13:13:41 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x4so8317594ion.2 for ; Tue, 05 Mar 2019 13:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4FAruVKIi16KvmBGo044T0X2ynmtZvulgDkDBly/xdQ=; b=nfZSPyXJr+aYI+LDhIMiCDfWhIDddffLBq7AieP5NMDCgOJ4je4Lm9tlYvBf/5nxFR PR6n65gbiUGGHAkKlsvsEWh94aV3rf8f0/fC+JqTIzFuv6UL168Dp7nlhs87OMGX6HgE fjo+K0S9BTWueblcXAATczMP7SngY68x380le1MZxcDvJhPZzpRVWhCmdEGxVseZCsCO zYwKuEPegDCDbmUqnK/fMU7XkNe6YjgeyTxcgI4Fk1X4aj9YJlD2Ed2QAoD5vroBqfdY eaz3cLPZlhZnQcJeJ1WKolSJb9UqFZHL0CW512LChwNP4DE7u8LgWE/EWanm3QYmlsHt 3tig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4FAruVKIi16KvmBGo044T0X2ynmtZvulgDkDBly/xdQ=; b=ZTc2C5z8h5BJyIya6SQnwBLKVO19shifjpW2TQTtMy/ekbXSz47TL9jK3KIc/clX8k V1PVrmp6/8Lyx+lIo7aaf7N1aGlGR2fPuqtkon8srayChNGQRyx4wQH9vmXne8W3YHR3 AYVBahrE7poijPsO4TDOmqgA1wB3u4ajwVuR9YVUkPzvEEhIV/AaF2S9lNvr0vBBfqT/ ZlxDXkvWwZseW+qnocwbd0TT06NFKZ7YGxZTg3w0XaGh263hI1ze5YsGbui8Arf+c5vI +Wx073Otx/frWxbqUddChGRYzqnYaYttukynwI0nreDn2swK48eFz0XTTQ7Wl/BKTHcg mAnA== X-Gm-Message-State: APjAAAVHBVTA1ScNT8Dz7txHGKQxZptfYzI72fakW+2ZYY/+e3ywCbPZ f9TBuXxEnwsXROn7TstzDOFiMZfSj9YEIH3mb2EgdgaE X-Google-Smtp-Source: APXvYqx5TLp//FKui4+akmC/PJkDeSFZjinLhdD3aXKT5ElPeBFM9TrWWtfZ0mtvJeuM/V22Rqfl1/tY3d2emtTU+qY= X-Received: by 2002:a5d:9418:: with SMTP id v24mr1189593ion.181.1551820420734; Tue, 05 Mar 2019 13:13:40 -0800 (PST) MIME-Version: 1.0 References: <811b3bb7-8458-4790-b5af-7c4faedc133a@www.fastmail.com> In-Reply-To: <811b3bb7-8458-4790-b5af-7c4faedc133a@www.fastmail.com> From: Justin Uberti Date: Tue, 5 Mar 2019 13:13:29 -0800 Message-ID: To: Martin Thomson Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000ef576305835f58e5" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:13:43 -0000 --000000000000ef576305835f58e5 Content-Type: text/plain; charset="UTF-8" Regarding information about implications, we expect to be able to share initial data within the next several weeks. On Tue, Mar 5, 2019 at 1:10 PM Martin Thomson wrote: > How is it that the two drafts this rules on are only informative > references? It probably needs to update IP handling. > > The modes this adds are good, but it specifically states that the > implications aren't known. It even promises to update the draft when that > information is gained. That suggests that this doc might have an uncertain > future. What is the chairs' thinking about the draft? > > On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote: > > Howdy, > > > > draft-uberti-ip-handling-ex- > > mdns > is a > very short draft describing two new modes related to > draft-ietf-rtcweb-ip-handling < > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of > draft-ietf-rtcweb-mdns-ice-candidates < > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>. > > > > The chairs would like to ask for a couple of reviews; given that it is > > four pages long, we are hopeful that it will not take much time. > > > > Please send your review to the list, > > > > thanks, > > > > Ted > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000ef576305835f58e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regarding information about implications, we expect to be = able to share initial data within the next several weeks.

On Tue, Mar 5, 201= 9 at 1:10 PM Martin Thomson <mt@low= entropy.net> wrote:
How is it that the two drafts this rules on are only informative= references? It probably needs to update IP handling.

The modes this adds are good, but it specifically states that the implicati= ons aren't known. It even promises to update the draft when that inform= ation is gained.=C2=A0 That suggests that this doc might have an uncertain = future. What is the chairs' thinking about the draft?

On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote:
> Howdy,
>
> draft-uberti-ip-handling-ex-
> <https://datatracker.ietf.= org/doc/draft-uberti-ip-handling-ex-mdns/>mdns <https://datatracker.ietf.org/doc/draft-uberti-ip-ha= ndling-ex-mdns/> is a very short draft describing two new modes rela= ted to draft-ietf-rtcweb-ip-handling <ht= tps://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits = of draft-ietf-rtcweb-mdns-ice-candidates <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice= -candidates/>.
>
> The chairs would like to ask for a couple of reviews; given that it is=
> four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000ef576305835f58e5-- From nobody Tue Mar 5 13:15:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0977130E5B for ; Tue, 5 Mar 2019 13:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T5ZMoMiddkCE for ; Tue, 5 Mar 2019 13:15:36 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D421288BD for ; Tue, 5 Mar 2019 13:15:36 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id e186so8323693ioa.0 for ; Tue, 05 Mar 2019 13:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gh+ZEXk/6yXDvb9e019Uo0J6R/NeXPHK3+7WeN5KjHM=; b=TzsTny3x9ko5U8yZ8vmUyKIIJjZxcPpz2GRIrAAkSXXtWMXgmJTLJ2ZzWKzuiVx9tN Anrygv2Xo7hL+qbrLIAplVGYIw9KCW7mJaWhmipC1rc8zO0xBNPCHGlEzSDdQ6Yop6oE 3boJ0jX01AXkArmRuHs1doD1YECfhhpIemRpPIva56FLp19Lms5NJ7wHBppFh3IoZvhU cjtbHFXtq47ECh8IsiOFP6ofOlPKAbdLMjSg4xKC+y2M7dM/pew1d2bUzV7lF2X9ETqu wPpcZeUE94rzr5hcBL8mkiy5x9NQh0aBPPyBf4+owBWkJM2WjwR+nXhqlYz2bIU987Xv XnYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gh+ZEXk/6yXDvb9e019Uo0J6R/NeXPHK3+7WeN5KjHM=; b=ZL9jIWErN2qJLsq6kisbJC1yN/b2VEL5PxpAycd2tstDis3nyXL67WPj8kB/ucNdRR sz+uQDRCZjQO8rrzqeEiyBZqO7sxDo9lTr6xJGpVDkUrE23qn61hxV+0hitS4jaoNqJW cISf4FRdABJwK0bMwz+dxa6k/sYXAOwMUgJfnLdYJzIIHEKmsk//6cOaQXtrqg7/+vPH DLx1IzonLLZThYEK+VS4sL9X+WbCD2o7urMDLwgc+hqNSRWRA0VDQTqO9mw4WDekhWAl dP8upJKAbc0OBhJbnmfsRQDkj1dXMUPMPI9tAq7tZdo4g0lrC/+gF3IuqLOvQwG/f5zU xk8w== X-Gm-Message-State: APjAAAVjKg3aWf4yIJ11UjqpbxnJqAKDBD6CBLqLZ+Nie764zj4O7vZv DAfAgdlCbEhS4XuDtRzvag7m62ZGfX3K/6epM0M= X-Google-Smtp-Source: APXvYqygwYLD5l4PR3eGmsvCpyjK/ifL5rxgJ37DCX6C7F0O/ARjrjsW7Dj+NCXlzjBSRr5r4C1ikryrx67sFfS60jc= X-Received: by 2002:a6b:c543:: with SMTP id v64mr1338947iof.6.1551820535368; Tue, 05 Mar 2019 13:15:35 -0800 (PST) MIME-Version: 1.0 References: <811b3bb7-8458-4790-b5af-7c4faedc133a@www.fastmail.com> In-Reply-To: <811b3bb7-8458-4790-b5af-7c4faedc133a@www.fastmail.com> From: Ted Hardie Date: Tue, 5 Mar 2019 13:15:09 -0800 Message-ID: To: Martin Thomson Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c4123b05835f5fc5" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:15:39 -0000 --000000000000c4123b05835f5fc5 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 1:10 PM Martin Thomson wrote: > How is it that the two drafts this rules on are only informative > references? It probably needs to update IP handling. > > The modes this adds are good, but it specifically states that the > implications aren't known. It even promises to update the draft when that > information is gained. That suggests that this doc might have an uncertain > future. What is the chairs' thinking about the draft? > > Traditionally, Experimental is the best fit for docs with that characteristic. Ted > On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote: > > Howdy, > > > > draft-uberti-ip-handling-ex- > > mdns > is a > very short draft describing two new modes related to > draft-ietf-rtcweb-ip-handling < > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits of > draft-ietf-rtcweb-mdns-ice-candidates < > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/>. > > > > The chairs would like to ask for a couple of reviews; given that it is > > four pages long, we are hopeful that it will not take much time. > > > > Please send your review to the list, > > > > thanks, > > > > Ted > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000c4123b05835f5fc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 5, 2019 at 1:10 PM Martin Tho= mson <mt@lowentropy.net> wro= te:
How is it that the two drafts this rules on are only informa= tive references? It probably needs to update IP handling.

The modes this adds are good, but it specifically states that the implicati= ons aren't known. It even promises to update the draft when that inform= ation is gained.=C2=A0 That suggests that this doc might have an uncertain = future. What is the chairs' thinking about the draft?


Traditionally, Experimental is the bes= t fit for docs with that characteristic.

Ted
On Wed, Mar 6, 2019, at 07:22, Ted Hardie wrote:
> Howdy,
>
> draft-uberti-ip-handling-ex-
> <https://datatracker.ietf.= org/doc/draft-uberti-ip-handling-ex-mdns/>mdns <https://datatracker.ietf.org/doc/draft-uberti-ip-ha= ndling-ex-mdns/> is a very short draft describing two new modes rela= ted to draft-ietf-rtcweb-ip-handling <ht= tps://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling> using bits = of draft-ietf-rtcweb-mdns-ice-candidates <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice= -candidates/>.
>
> The chairs would like to ask for a couple of reviews; given that it is=
> four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000c4123b05835f5fc5-- From nobody Tue Mar 5 13:32:11 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E1130F70 for ; Tue, 5 Mar 2019 13:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 FGIv0u9-ODWq for ; Tue, 5 Mar 2019 13:32:08 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A3D131065 for ; Tue, 5 Mar 2019 13:32:07 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id v21so6676887pfm.12 for ; Tue, 05 Mar 2019 13:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c7SXzrJDoKUtOYj2T/JJPfW5Po4lzVrRPiznZvEZIXk=; b=iMeY/GYjB/WwosUv9q0vOCn0A2sqADXNWAyrY5k1eySuz+8bl3sfeZtEJ8cc0/L4/k Fv6J0AbLv2y7pfRnjoHV7mdVVdBKmypF5zoCs4yeYU44eFXh/HRF2MUAma4E5a2H9wxg bv3zBuOOe/mzvkYmw4ejsI3RzJjdxjuA7530DnWcEu7wsF88A56Xj88Zr6U0hGT78hKF svI/25loRY7LKFgKVmWRzN16VRrbilRA6EZ283hAIFj2YLqoR/+KyUDnoq/V5QGRHQiz U48ifdWAoq5+DsgvHEbttqy7yQ5RZrj8EyKPytPVmCcyGqsHAI5KxAPbRgEb+1CC4fNa HhMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c7SXzrJDoKUtOYj2T/JJPfW5Po4lzVrRPiznZvEZIXk=; b=ubwWsXswM1aDbPXMAJKmbFHJIjht6bdRAyR2gOZzxwDOXDxL66pp+n0JVE25n2hggL FyQPwlPa83sUsFjbM8tj4QVRuYRNemZ/xD9JM3fI6/oP0AJF6PkdqNy4pHlWydqllKhh I4orjJlA/jDPXcnD82TEha+W24hfJxOkyBHFhKX/aHbsgPX3bzLy+QsEk1WhsiTQdOUy AF5ILhvWq8CX2nAv4FTDDRNNN6ilNt9oFh2erjGLgLA7Zd6Kobk+wOBtqseTAL3QaMN4 JrMoOKcFfcus1yYlHMjtYZw47yqHekaIh4NIOdXZlwDkfNZ9xAKaDkJJboCZu4dO4g7n SI3Q== X-Gm-Message-State: APjAAAU6NM/dvCLFyBnMbNi5PHBssOqozqi8K0MIOI2AIXWV2z7gOQ98 atiY1Hsac7qTBQn/8NYdxa/bz1JtT8s= X-Google-Smtp-Source: APXvYqzxznlS6F4qZFdssjRTLIbfcCmtRMtoCxdLDufN6GeSLiiA6tYQZcozFL0yR6NlYLaCaDLDOg== X-Received: by 2002:a63:cc03:: with SMTP id x3mr3173801pgf.121.1551821526983; Tue, 05 Mar 2019 13:32:06 -0800 (PST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id x1sm13208438pge.73.2019.03.05.13.32.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 13:32:06 -0800 (PST) Received: by mail-pf1-f182.google.com with SMTP id n125so6684240pfn.5 for ; Tue, 05 Mar 2019 13:32:06 -0800 (PST) X-Received: by 2002:a62:4389:: with SMTP id l9mr4027808pfi.170.1551821526022; Tue, 05 Mar 2019 13:32:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 5 Mar 2019 16:31:55 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d041e405835f9a02" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:32:10 -0000 --000000000000d041e405835f9a02 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 4:12 PM Justin Uberti wrote: > Roman, was there specific text in mdns-ice-candidates that you think is > contradicted by ip-handling-ex-mdns? The goal was for the former document > to describe the technique and the latter to describe when it should be > applied. > According to Section 3.1 of ietf-rtcweb-mdns-ice-candidates ( https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02#section-3.1) all host candidates are replaced with mDNS names. Based on draft-uberti-ip-handling-ex-mdns, RFC4941 IPv6 addresses in mode 2.1 can be skipped and left as is. Some language likely need to be added to ietf-rtcweb-mdns-ice-candidates section 3.1 to specify that mDNS encoding is optional, at least for RFC4941 IPv6 address. Furthermore, mdns-ice-candidates section 3.1 specifies that mDNS names can be re-used. These re-used mDNS names could be used for fingerprinting. For your draft, it is probably a good idea to limit re-use only to the same browser session. Regards, _____________ Roman Shpount --000000000000d041e405835f9a02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue,= Mar 5, 2019 at 4:12 PM Justin Uberti <juberti@google.com> wrote:
=
Roman, w= as there specific text in mdns-ice-candidates that you think is contradicte= d by ip-handling-ex-mdns? The goal was for the former document to describe = the technique and the latter to describe when it should be applied.
=C2=A0
According to Section 3.1 of ietf-rtcweb-md= ns-ice-candidates (https://tools.ietf.org/html/draft-ietf= -rtcweb-mdns-ice-candidates-02#section-3.1) all host candidates are rep= laced with=C2=A0mDNS names. Based on draft-uberti-ip-handling-ex-mdns,=C2= =A0=C2=A0RFC4941 IPv6 addresses in mode 2.1 can be skipped and left as is. So= me language likely need to be added to=C2=A0ietf-rtcweb-mdns-ice-can= didates section 3.1 to specify that mDNS encoding is optional, at least for= =C2=A0RFC4941 IPv6 address.

Furthermore, mdns-ice-candidates section 3.1 specifies th= at mDNS names can be re-used. These re-used mDNS names could be used for fi= ngerprinting. For your draft, it is probably a good idea to limit re-use on= ly to the same browser session.
=
Regards,
_____________
Roman Shpount
--000000000000d041e405835f9a02-- From nobody Tue Mar 5 13:40:36 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4511312E3 for ; Tue, 5 Mar 2019 13:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cpyH8zFxVhNI for ; Tue, 5 Mar 2019 13:40:28 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A515A1310DF for ; Tue, 5 Mar 2019 13:40:27 -0800 (PST) Received: (qmail 14748 invoked from network); 5 Mar 2019 21:40:25 -0000 X-APM-Authkey: 255286/0(159927/0) 2024 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Mar 2019 21:40:25 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 2985618A0587; Tue, 5 Mar 2019 21:40:25 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rpEcqXNDtWF8; Tue, 5 Mar 2019 21:40:25 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E801718A0152; Tue, 5 Mar 2019 21:40:24 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: westhawk In-Reply-To: Date: Tue, 5 Mar 2019 21:40:24 +0000 Cc: RTCWeb IETF , Adam Roach , Sean Turner Content-Transfer-Encoding: quoted-printable Message-Id: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> References: To: Ted Hardie X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:40:35 -0000 On first reading it seems like there might be a conflation of private IP = addresses and local IP addresses. the [ip-handling] document uses the term 'Private local IP addresses=E2=80= =99 where as this document uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any explanation (I can find) of the difference. Surely this would mean that a standalone device (say a public kiosk) = assigned a=20 single routable public IP would mask that address with mdns. Tim. =20 > On 5 Mar 2019, at 20:22, Ted Hardie wrote: >=20 > Howdy, >=20 > draft-uberti-ip-handling-ex-mdns is a very short draft describing two = new modes related to draft-ietf-rtcweb-ip-handling using bits of = draft-ietf-rtcweb-mdns-ice-candidates. >=20 > The chairs would like to ask for a couple of reviews; given that it is = four pages long, we are hopeful that it will not take much time. >=20 > Please send your review to the list, >=20 > thanks, >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 5 19:08:24 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBD6129441 for ; Tue, 5 Mar 2019 19:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8o5pPfyE_2kZ for ; Tue, 5 Mar 2019 19:08:20 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BA71277CC for ; Tue, 5 Mar 2019 19:08:20 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id v2so7365118ith.3 for ; Tue, 05 Mar 2019 19:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qDE2j4ykHC7hXFKJsukAt0nGYwCTNmGzivy/hIgZkzA=; b=W/77EID4guGJjdn0/BX0baXgw4gRyNxvnDunuw1xbSOaPugJBf7hFdcRoz5RdgRpIJ OL7I1D71CQ4WcS1qOHt79NIW3nrK1m0rzqbSbKkqCm9mCNg6A82e8rtl0EDsC5So2G4M SnmXndh80iPkzYlUTn+pGUu+3PytA3nSLMp7YwKqoXE+tFiVvLZ2dytA4GOIjejE57YH coeG73E4W87DdoTVNAzPnbGZxErwqWqTQwd0VHpdoD/6AAFC6A3eGZfvhMgpIhCIKngR cOdwuKz4VEPYyc2JG4jeBJWjLKaT0QntDRkIecjlCftJlcRsKcFso8TUUAfCSMmMYhgo fMkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qDE2j4ykHC7hXFKJsukAt0nGYwCTNmGzivy/hIgZkzA=; b=M5wpGiliGqECXC5JCjWxS0Chv3nwxn7njZJWjbvQnC+4c94AsMymH3BePvmEwMODJT 4iIR2nrWdMydPDoBFdwjz21Zvd2cOH098T/BQxyecwk+7/9ItvfqZyOP/hCFnMgsXYPL xFBfA0WHASN16EWGTH18Vi3VwtUC8i8QslJ3fcaeNesnI+JJf3Ad8OE1ysvyx+cgUWVm nsUZb5sfYEqpb1kt0HBkVfIpI18ff0yHXDvjqPVV1LT/Gblchj3n7QPOtJkSQXDy68U0 uW4KMi0filHcpUhfAg2Y2GAg10sD/MVSUjAorOINm/UCUxUzIAFNzrCTGBOEmob5ZFWG ZQgw== X-Gm-Message-State: APjAAAV9Zl3GWb2mHStdvbM6T8IhLECPMF0g8y9h45wm58K9Rl5fCZPU ajgGbL4uSbmylLcIrmzyYB5nFo9PX4xttfkIRoEYIQ== X-Google-Smtp-Source: APXvYqymfE/aLBtih2gJVE59fnsR7ZzqRDbjPVeD1rP4H+SiCo8wBiDXi+ki1dmOHZsM5xCR7++A0I8WRUJdsnag+Ik= X-Received: by 2002:a24:ccc5:: with SMTP id x188mr875037itf.123.1551841699480; Tue, 05 Mar 2019 19:08:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 5 Mar 2019 19:08:08 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003f3c7f0583644d7e" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 03:08:23 -0000 --0000000000003f3c7f0583644d7e Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 1:32 PM Roman Shpount wrote: > On Tue, Mar 5, 2019 at 4:12 PM Justin Uberti wrote: > >> Roman, was there specific text in mdns-ice-candidates that you think is >> contradicted by ip-handling-ex-mdns? The goal was for the former document >> to describe the technique and the latter to describe when it should be >> applied. >> > > According to Section 3.1 of ietf-rtcweb-mdns-ice-candidates ( > https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02#section-3.1) > all host candidates are replaced with mDNS names. Based on > draft-uberti-ip-handling-ex-mdns, RFC4941 IPv6 addresses in mode 2.1 can > be skipped and left as is. Some language likely need to be added to ietf-rtcweb-mdns-ice-candidates > section 3.1 to specify that mDNS encoding is optional, at least for RFC4941 > IPv6 address. > This has been addressed in the editor's copy of the mdns-ice-candidates draft - see https://rtcweb-wg.github.io/mdns-ice-candidates/draft-ietf-rtcweb-mdns-ice-candidates.html#rfc.section.3.1 . > Furthermore, mdns-ice-candidates section 3.1 specifies that mDNS names can > be re-used. These re-used mDNS names could be used for fingerprinting. For > your draft, it is probably a good idea to limit re-use only to the same > browser session. > I believe this is covered by https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02#section-5.3 . --0000000000003f3c7f0583644d7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Tue, Mar 5, 2019 at 1:32 PM Roman Shpount <roman@telurix.com> wrote:
On Tue, Mar 5, 2019 at 4:12 PM Justin Uberti <juberti@google.com>= wrote:
Roman, was there specific text in mdns-= ice-candidates that you think is contradicted by ip-handling-ex-mdns? The g= oal was for the former document to describe the technique and the latter to= describe when it should be applied.
=C2=A0
According to Section 3.1 of ietf-rtcweb-mdns-ice-candidates (https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-= ice-candidates-02#section-3.1) all host candidates are replaced with=C2= =A0mDNS names. Based on draft-uberti-ip-handling-ex-mdns,=C2=A0=C2=A0RFC4941= IPv6 addresses in mode 2.1 can be skipped and left as is. Some language li= kely need to be added to=C2=A0ietf-rtcweb-mdns-ice-candidates sectio= n 3.1 to specify that mDNS encoding is optional, at least for=C2=A0RFC4941 IPv6 address.

This has been addressed in the edi= tor's copy of the mdns-ice-candidates draft - see=C2=A0https://rtcweb-wg.github.io/mdns-ice-candidates= /draft-ietf-rtcweb-mdns-ice-candidates.html#rfc.section.3.1.
= =C2=A0
Furthermore, mdns-ice-candidates section 3.1 specifies that mDNS name= s can be re-used. These re-used mDNS names could be used for fingerprinting= . For your draft, it is probably a good idea to limit re-use only to the sa= me browser session.
--0000000000003f3c7f0583644d7e-- From nobody Tue Mar 5 19:34:28 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73891130E30 for ; Tue, 5 Mar 2019 19:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OAbXnniyAYe5 for ; Tue, 5 Mar 2019 19:34:24 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9DB127AC2 for ; Tue, 5 Mar 2019 19:34:24 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id z131so7421228itf.5 for ; Tue, 05 Mar 2019 19:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cjni4tYyHcIYoU9P4TSgufu1KYgWczRQfXmf+TGL8cE=; b=ClEO/GOGpW+f4stCt1bLu/unA2uAVT1H1pXcHxO2C9+Ad5CE+/VLcv5nRJHC+6L1Zx ISNR5uCy3c9a/xCYWtJ/P5G1MbTRrhossg+tVzLX/ItWtT9PXPHVpFFFrLmYPAJRpN/n lzCAUtXv8RkbgkYMFM4sXnx0vXdAwcv8PinZ8Gm0uukunYPVd/gevH3bCbUwH3l/pNRU GY1sjVBoS5x7IEYfmGRITAjaKdiuOs6YwJXfW45i/igj29t6Fbf8sbNfhZ6dj/oqT7G/ MmijDdDY4Tnou0s081ADwL47DL69B5WdDbDHFw/6tZWBWLqsRarmniRS+1mOxzYokpsm +FtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cjni4tYyHcIYoU9P4TSgufu1KYgWczRQfXmf+TGL8cE=; b=Pmq+SafC0CaVNWOmBYfNiKVm1DORD8L6OdDEHrRFqPbhy3S0dIX0Nu2riQS4nlctCq Li7x0vhl8PL+D6OllynPur8jX01y2AXbVtNxzaDmsfZf+pFGFZQvYBj9qlBVzRWjD7JC llN6unofMCHW9m/MbDT+2PNtmMDoZvv96gmfj1DRZPV2is/Q+wEpMaZFSbTh/lRhYe7w NRmOXlWPvRpKo3faNZkl9lBOiFaXam52J0vf7r17dBhkO1COt5M/BbwYrpG3ty6gA+V+ RrrGkd/JY0Bn0bru8vE3RhGmHAKFm+tTeR3ckPVFrpdt9JNKxTaIWCNPWgwPB7MSgqOa cu3Q== X-Gm-Message-State: APjAAAVLKDxlBhADDQag3aP7FF770Jq3T8G/70oDhAWG3S1XGZxMod+Q JwXFnJ4JbOrEjNKC2g13W/0p0hPjVyqeHU4cdT26ow== X-Google-Smtp-Source: APXvYqwtcsPxI4ppWFg5tGiiJgQF1guAjaTSsPtYrR8Q022L6uPjqUcuk4jLHTdxmxbxgFVC+ohIbpVw4OOwH/C7lU8= X-Received: by 2002:a24:ccc5:: with SMTP id x188mr910178itf.123.1551843263583; Tue, 05 Mar 2019 19:34:23 -0800 (PST) MIME-Version: 1.0 References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> In-Reply-To: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> From: Justin Uberti Date: Tue, 5 Mar 2019 19:34:12 -0800 Message-ID: To: westhawk Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000797c8d058364aab2" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 03:34:27 -0000 --000000000000797c8d058364aab2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We'll always mask any local addresses with mDNS, since we don't know if they're public or not. We will also provide a srflx candidate with the actual address should STUN tell us that information. Agree though we should be consistent on terminology, will look into what the best option is there. On Tue, Mar 5, 2019 at 1:40 PM westhawk wrote: > On first reading it seems like there might be a conflation of private IP > addresses and local IP addresses. > the [ip-handling] document uses the term 'Private local IP addresses=E2= =80=99 > where as this document > uses "private IP addresses=E2=80=9D in the introduction but then uses "Th= e local > IPv4 address=E2=80=9D without any > explanation (I can find) of the difference. > > Surely this would mean that a standalone device (say a public kiosk) > assigned a > single routable public IP would mask that address with mdns. > > Tim. > > > > > > > On 5 Mar 2019, at 20:22, Ted Hardie wrote: > > > > Howdy, > > > > draft-uberti-ip-handling-ex-mdns is a very short draft describing two > new modes related to draft-ietf-rtcweb-ip-handling using bits of > draft-ietf-rtcweb-mdns-ice-candidates. > > > > The chairs would like to ask for a couple of reviews; given that it is > four pages long, we are hopeful that it will not take much time. > > > > Please send your review to the list, > > > > thanks, > > > > Ted > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000797c8d058364aab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We'll always mask any local addresses with mDNS, since= we don't know if they're public or not. We will also provide a srf= lx candidate with the actual address should STUN tell us that information.<= div>
Agree though we should be consistent on terminology, wil= l look into what the best option is there.

On Tue, Mar 5, 2019 at 1:40= PM westhawk <thp@westhawk.co.uk> wrote:
On= first reading it seems like there might be a conflation of private IP addr= esses and local IP addresses.
the [ip-handling] document uses the term 'Private local IP addresses=E2= =80=99 where as this document
uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any
explanation (I can find) of the difference.

Surely this would mean that a standalone device (say a public kiosk) assign= ed a
single routable public IP would mask that address with mdns.

Tim.





> On 5 Mar 2019, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> draft-uberti-ip-handling-ex-mdns is a very short draft describing two = new modes=C2=A0 related to draft-ietf-rtcweb-ip-handling using bits of draf= t-ietf-rtcweb-mdns-ice-candidates.
>
> The chairs would like to ask for a couple of reviews; given that it is= four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000797c8d058364aab2-- From nobody Tue Mar 5 20:44:00 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6FC130EBE for ; Tue, 5 Mar 2019 20:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 GKbjq28ml1GG for ; Tue, 5 Mar 2019 20:43:55 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453FB130EB8 for ; Tue, 5 Mar 2019 20:43:54 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id h8so7314353pgp.6 for ; Tue, 05 Mar 2019 20:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IEXM92oGhg2B6vMyJgnV1gCLD/lGmNr/gUsWOpXW0Sc=; b=O07O0/yryKQNSSB19R/MahkxdI31Fgamf9D8c5zCQEJL/qpdyd8LlLVjctgxm8T5jJ gPLGHlKD86e1RdjOmDNIkETjIS64idCi9A5obR/kfGHIWKWa0d28HxPRy3UsGfpgdjUM bqHy8xGlcCmlahR5kfnKNa5wIcQax9KrLU258= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IEXM92oGhg2B6vMyJgnV1gCLD/lGmNr/gUsWOpXW0Sc=; b=skslfWgZpyQ62IJdrbnmNFBlMv9acjXQ/m3S5uKxlIv/GZPkw6kSBdlDc2sAMFiLG0 VcZ83oQd7GuguBPPbcTEobHNuTKIi32iq0dMrl7Y6XjnwoNsQbU8FQgIX+qsGDKlendA TUDPuq1zeJGQBmQd7jXodRGfvO0w6b45lOpc1bqYvzC/FRXFFvvOJXPCanFPXrBruAnC CVQgRUQpqj8gU8BR3FOC4zIgECfW/Nm8fxtpVTWFzcevpMwUDAiNt+6ZvpB1osj6f1rH CzrMD7waIKKo+ERNZ2p5lCFMkoz2ZPfXIAaecZwrxg7zZcxhwAesQhiHdeUct2Sxqg9a pwYw== X-Gm-Message-State: APjAAAVd1RSErwdnUe4cj17ghkdymINo3utb1k8CmVqwEoNeAjVnKLGU 2KsW479zUTY69MrtyduMdCSYuYP7XLQ= X-Google-Smtp-Source: APXvYqzYIX5Qoao2eHC30k7X6RxOouaIdQPIg666xWlWvTAAEDkih6MISHyeyHDLWY1/DXt8muA3dQ== X-Received: by 2002:a17:902:2a2b:: with SMTP id i40mr3245019plb.236.1551847433089; Tue, 05 Mar 2019 20:43:53 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:e07d:f33e:2143:e1f5? ([2601:647:4600:3f31:e07d:f33e:2143:e1f5]) by smtp.gmail.com with ESMTPSA id h3sm591814pgv.38.2019.03.05.20.43.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 20:43:52 -0800 (PST) From: Nils Ohlmeier Message-Id: <17370418-5B43-43E2-A96B-CF03E627BE0F@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_66A3443F-672B-479C-95BE-A848F9D27EFA" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 20:43:50 -0800 In-Reply-To: To: RTCWeb IETF References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 04:43:59 -0000 --Apple-Mail=_66A3443F-672B-479C-95BE-A848F9D27EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed draft-uberti-ip-handling-ex-mdns and in general it = looks. One part is not clear enough to me though:=20 - section 3.1 uses the term =E2=80=9Cpreferred interface=E2=80=9D for = first time (I did not find this term in draft-rtcweb-ip-handling) and = it=E2=80=99s not clear to me what it means. - section 3.2 does not use the term interfaces at all, but instead talks = about IP addresses instead. I=E2=80=99m guessing section 3.2 implicitly refers to all IP addresses = from all interface. It would help to make that explicit. Since =E2=80=9Cpreferred interface=E2=80=9D seems to be used first in = the draft I think needs to be defined somewhere. Alternatively the term =E2=80=9Cpreferred interface=E2=80=9D in section = 3.1 could get replaced with terms referring to IP addresses. Best regards Nils Ohlmeier > On 5Mar, 2019, at 12:22, Ted Hardie wrote: >=20 > Howdy, >=20 > draft-uberti-ip-handling-ex- = mdns = is = a very short draft describing two new modes related to = draft-ietf-rtcweb-ip-handling = using bits = of draft-ietf-rtcweb-mdns-ice-candidates = .= >=20 > The chairs would like to ask for a couple of reviews; given that it is = four pages long, we are hopeful that it will not take much time. >=20 > Please send your review to the list, >=20 > thanks, >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_66A3443F-672B-479C-95BE-A848F9D27EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have reviewed draft-uberti-ip-handling-ex-mdns and in general it = looks.

One part is = not clear enough to me though: 
- section 3.1 = uses the term =E2=80=9Cpreferred interface=E2=80=9D for first time (I = did not find this term in draft-rtcweb-ip-handling) and it=E2=80=99s not = clear to me what it means.
- section 3.2 does not = use the term interfaces at all, but instead talks about IP addresses = instead.

I=E2=80= =99m guessing section 3.2 implicitly refers to all IP addresses from all = interface. It would help to make that explicit.
Since= =E2=80=9Cpreferred interface=E2=80=9D seems to be used first in the = draft I think needs to be defined somewhere.
Alternatively the term =E2=80=9Cpreferred interface=E2=80=9D = in section 3.1 could get replaced with terms referring to IP = addresses.

Best = regards
  Nils Ohlmeier

On 5Mar, = 2019, at 12:22, Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

draft-uberti-ip-handling-ex-mdns is a very short draft describing two new = modes  related to draft-ietf-rtcweb-ip-handling using bits of draft-ietf-rtcweb-mdns-ice-candidates.

The chairs would like to = ask for a couple of reviews; given that it is four pages long, we are = hopeful that it will not take much time.

Please send your review to the = list,

thanks,

Ted
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_66A3443F-672B-479C-95BE-A848F9D27EFA-- From nobody Tue Mar 5 21:49:06 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9259C12D4EF for ; Tue, 5 Mar 2019 21:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 o0iMluKpD-S6 for ; Tue, 5 Mar 2019 21:49:01 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B40F12D4E7 for ; Tue, 5 Mar 2019 21:49:01 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id v2so7763420ith.3 for ; Tue, 05 Mar 2019 21:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SSJGdHDS72qEHyleu0aIL5XR0K6rgRhycjRpR/a3xPU=; b=tdYXyE15QIVnLmPj96o+Crn+iwZx+UnOJ6Tofe3p5r6fXMpHDbrv+HR7Y/zBCkMRxh W3RR1U5XbvPhOa3HIF+FlEeP6p8Ku6hPJoT56B8sunVzi2F979zuo7S3h7ci3+Uy44JL No3j2a4FEscFk1JYDJYmDsgBoGguPBLyZ0vjhsjbZewtqkZSbB3iYq8OPKsJNPGdCFiK yxlZIfEcG+Z5HDkaWC+ZQWX8jwAP7kwKs2axDjQSCeGmS5QZeo5aX9NWsW7SGIpcMihG 0EA8wqISEdJJ4MtfbwYi9UFJE5P2vsFT1t/98pYzRthGpr1bEZPWDhKKNZqehsw5BIUE OmMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SSJGdHDS72qEHyleu0aIL5XR0K6rgRhycjRpR/a3xPU=; b=bQVCe06N+0zGW6Xh2gECZxIQI1PmT8JQtKzSr9W/tr4vhDtkW/U4/V7fFLago4Hthr 68HdPz4QHKST2VHaAJzCHCqxs+hpBpN3WTilNQGZ4ccYKmtDtaZpWMLp2vpnI34xUdHH GQu7xA0bIdLz85Nm6OCbfBrPu5EqHfeTcbQQTEcYLzOU0GpJCU1Iho9Wmda8NOkYi1ym WepUeP//hzuhFPKAd+y0YO8ngYNDCQxmr71+rtDCzqAKy0oYNrkR17b1JfB9gfoNocIh JS4rWLyYFMnujKtVcsESsI5FQKpLUp/W/6+zBIvwGEDGGFTB1bYR64SFjNzrijFSPbTx 9ttQ== X-Gm-Message-State: APjAAAVBVDGCJW6HwGpV13w2CMmuRIgim3kjPLFE5b4xgtIxBRAJim0C uNt9L92bsUTRxQxsSaZJyucqI/EaN31BWm2u2H1Rvg== X-Google-Smtp-Source: APXvYqzSRs9W3YgLx5RW+Z/7WWt0fhJXSbPlxAbA5MGJUVyy8JIT95vs0c4WVARByyE3NLciwYStJp/x4otAFakNLCM= X-Received: by 2002:a02:313:: with SMTP id y19mr3306000jad.88.1551851340348; Tue, 05 Mar 2019 21:49:00 -0800 (PST) MIME-Version: 1.0 References: <17370418-5B43-43E2-A96B-CF03E627BE0F@mozilla.com> In-Reply-To: <17370418-5B43-43E2-A96B-CF03E627BE0F@mozilla.com> From: Justin Uberti Date: Tue, 5 Mar 2019 21:48:48 -0800 Message-ID: To: Nils Ohlmeier Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000e33fd20583668b65" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 05:49:05 -0000 --000000000000e33fd20583668b65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 5, 2019 at 8:44 PM Nils Ohlmeier wrote: > I have reviewed draft-uberti-ip-handling-ex-mdns and in general it looks. > > One part is not clear enough to me though: > - section 3.1 uses the term =E2=80=9Cpreferred interface=E2=80=9D for fir= st time (I did > not find this term in draft-rtcweb-ip-handling) and it=E2=80=99s not clea= r to me > what it means. > Yes, I should have said "interface associated with the default route", to be consistent with ip-handling. > - section 3.2 does not use the term interfaces at all, but instead talks > about IP addresses instead. > > I=E2=80=99m guessing section 3.2 implicitly refers to all IP addresses fr= om all > interface. It would help to make that explicit. > Technically correct; however, in Mode 2.* only the addresses from the 'default' interface are provided, so for clarity the document should reiterate that fact (and that they are all replaced with mDNS names). > Since =E2=80=9Cpreferred interface=E2=80=9D seems to be used first in the= draft I think > needs to be defined somewhere. > Alternatively the term =E2=80=9Cpreferred interface=E2=80=9D in section 3= .1 could get > replaced with terms referring to IP addresses. > Open to ideas here; "interface associated with the default route" is kind of verbose. > > Best regards > Nils Ohlmeier > > On 5Mar, 2019, at 12:22, Ted Hardie wrote: > > Howdy, > > draft-uberti-ip-handling-ex- > mdns > is a > very short draft describing two new modes related to > draft-ietf-rtcweb-ip-handling > using bits of > draft-ietf-rtcweb-mdns-ice-candidates > = . > > The chairs would like to ask for a couple of reviews; given that it is > four pages long, we are hopeful that it will not take much time. > > Please send your review to the list, > > thanks, > > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000e33fd20583668b65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 5, 2019 at 8:44 PM Nils O= hlmeier <nohlmeier@mozilla.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">I have reviewed draft-uberti-ip-ha= ndling-ex-mdns and in general it looks.

One part is not = clear enough to me though:=C2=A0
- section 3.1 uses the term =E2= =80=9Cpreferred interface=E2=80=9D for first time (I did not find this term= in draft-rtcweb-ip-handling) and it=E2=80=99s not clear to me what it mean= s.


Since =E2=80=9Cpreferred interface=E2=80=9D seems to be us= ed first in the draft I think needs to be defined somewhere.
Alte= rnatively the term =E2=80=9Cpreferred interface=E2=80=9D in section 3.1 cou= ld get replaced with terms referring to IP addresses.

Open to ideas here; "interface associated with = the default route" is kind of verbose.=C2=A0

Best regards
=C2=A0 Nils Ohlmeier


Howdy,

draft-uberti-ip-handling-ex-mdns = is a very short draft describing two new modes=C2=A0 related to draft-ietf-rtcweb-ip-handling using bits of draft-ietf-rtcweb-mdns-ice-candidates.

The c= hairs would like to ask for a couple of reviews; given that it is four page= s long, we are hopeful that it will not take much time.

Please send your review to the list,

thanks,=

Ted
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000e33fd20583668b65-- From nobody Wed Mar 6 00:45:15 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94845130ED1 for ; Wed, 6 Mar 2019 00:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 APzw9EUiqUWd for ; Wed, 6 Mar 2019 00:45:11 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF5B130EBF for ; Wed, 6 Mar 2019 00:45:10 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id 10so9608840eds.7 for ; Wed, 06 Mar 2019 00:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:cc:to:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hQFQ4/MD5ugZ2IsXYXNGSVTBkQu13uIRkz06t1qbi8o=; b=OkdYiECBRD2ope5fGLRgBoyR8O9dcDXstOB4g0EScxb0V0Zg7ov0jZsnPNEiaRxUdO ijC5kuvxQGrOCansERuQU8thcPKJy6/JhByPS6m/PBpgwTJFxy+cULkDE+B1/4EAXNOy RdclCYew6Q6QqqRsgOR5Wms9jofh8KIGCiZWtb0tWkXYFHjxRBfvzswyHwcwocjOfrla fHZYMIb16rjbsk1SsZ2vEqsqZMDGD/fanYwVRbboBMFX8F3NkE321go0RRdD613FIjZm 7LJYMEGqsTo7YREFWXMGBkqSC7mGrm4+tXKdED0Ba+B6zPVh4MOqr+UmfRJWdthParz6 k9Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:cc:to:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hQFQ4/MD5ugZ2IsXYXNGSVTBkQu13uIRkz06t1qbi8o=; b=aOw4qj1WL8FJabiWUijYLWCff+3aW/fWxKfYhyi+HMJIiI6eK6v6DUQDssiicpWfyo ExovC70DAMg4ZzkgvMbr5Sd0GAjitNa+negYdY9QJhKNsoQYqFWtXB9Hx99Xrb2Dr8gn FsUf1PJwYxXXX/r9BdWWI3tW5TzyNnlgOgs1WTLmujsrBtZuB+Y1m9Ncf4vnlsfKmz/p I1/9H4LazOUKIjeltoLigrE0M2RjJd1rlfr+TVs16HoX2WrUaGQAPqGu/cMCFGQs0DOM +oEkLnhbEkck4G7N9XABzKHxoQarglXgxBNzTVQwU6TkDsDYxnCPixVXILt2loJWLI1d 7NZg== X-Gm-Message-State: APjAAAUoNU4NZw6StIBl6vq3wABZPyJVmp/G86YCBwvNSqInGJQN+H7s 8Rz/ryrbPVF82vvYo12WpCccGAse X-Google-Smtp-Source: APXvYqzKo0NF6bDA/1z4rQyKkoa2u+z1ap5aWxNyVwQruHWN16wEox9VAR4GiAgL6ONX3tawsTyo1A== X-Received: by 2002:a50:b1cd:: with SMTP id n13mr22888737edd.224.1551861908752; Wed, 06 Mar 2019 00:45:08 -0800 (PST) Received: from [192.168.11.149] ([185.41.76.142]) by smtp.gmail.com with ESMTPSA id i20sm215608ejv.26.2019.03.06.00.45.08 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 00:45:08 -0800 (PST) References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> Cc: rtcweb@ietf.org To: Justin Uberti From: Lennart Grahl Openpgp: preference=signencrypt Message-ID: <3a0ca676-e43a-d45c-b82c-22287a764a79@gmail.com> Date: Wed, 6 Mar 2019 09:45:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 08:45:13 -0000 On 06.03.19 04:34, Justin Uberti wrote: > We'll always mask any local addresses with mDNS, since we don't know if > they're public or not. We will also provide a srflx candidate with the > actual address should STUN tell us that information. IIRC that would mean a publicly reachable local IP address would still be masked with mDNS first. Once the STUN server's answer arrives, a srflx candidate with the exposed IP address must be handed out. Is that assumption correct? Cheers Lennart From nobody Wed Mar 6 02:11:18 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25412D4EA for ; Wed, 6 Mar 2019 02:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ifgy6OyAt0s0 for ; Wed, 6 Mar 2019 02:11:14 -0800 (PST) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA36E127598 for ; Wed, 6 Mar 2019 02:11:13 -0800 (PST) Received: (qmail 15577 invoked from network); 6 Mar 2019 10:11:10 -0000 X-APM-Authkey: 255286/0(159927/0) 395 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 6 Mar 2019 10:11:10 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id B1EDD18A069F; Wed, 6 Mar 2019 10:11:10 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BeOqXuQIKLur; Wed, 6 Mar 2019 10:11:10 +0000 (GMT) Received: from [172.20.10.2] (79.cust.gb.ggsn1.truphone.com [185.99.25.79]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7A9CA18A016B; Wed, 6 Mar 2019 10:11:09 +0000 (GMT) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BD09B6E4-8A68-4418-B5F2-A6B8E5914711" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 10:11:01 +0000 In-Reply-To: Cc: Ted Hardie , RTCWeb IETF To: Justin Uberti References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 10:11:17 -0000 --Apple-Mail=_BD09B6E4-8A68-4418-B5F2-A6B8E5914711 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Mar 2019, at 03:34, Justin Uberti wrote: >=20 > We'll always mask any local addresses with mDNS, since we don't know = if they're public or not. We will also provide a srflx candidate with = the actual address should STUN tell us that information. So the =E2=80=98always=E2=80=99 should be conditional on how the = addresses are =E2=80=98found=E2=80=99? Perhaps a definition of Local IP addresses would help: =E2=80=9CLocal IP addresses means addresses discovered by interrogating = the operating system for a list of available interfaces and their associated IP addresses=E2=80=9D=20= Plus a clarification that =E2=80=9Cthese rules do not apply to addresses = that are subsequently found via STUN or ICE - note that this may cause an address to be listed twice - = once as a host candidate with a masked mdns and a second time with it=E2=80=99s IP address as a reflex candidate=E2=80= =9D (I=E2=80=99ve a feeling there is section of the ICE RFC that talks about = eliminating reflex candidates that duplicate host candidates=20 but can=E2=80=99t find it) Tim. =20 >=20 > Agree though we should be consistent on terminology, will look into = what the best option is there. >=20 > On Tue, Mar 5, 2019 at 1:40 PM westhawk > wrote: > On first reading it seems like there might be a conflation of private = IP addresses and local IP addresses. > the [ip-handling] document uses the term 'Private local IP = addresses=E2=80=99 where as this document > uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any > explanation (I can find) of the difference. >=20 > Surely this would mean that a standalone device (say a public kiosk) = assigned a=20 > single routable public IP would mask that address with mdns. >=20 > Tim. >=20 >=20 >=20 >=20 >=20 > > On 5 Mar 2019, at 20:22, Ted Hardie > wrote: > >=20 > > Howdy, > >=20 > > draft-uberti-ip-handling-ex-mdns is a very short draft describing = two new modes related to draft-ietf-rtcweb-ip-handling using bits of = draft-ietf-rtcweb-mdns-ice-candidates. > >=20 > > The chairs would like to ask for a couple of reviews; given that it = is four pages long, we are hopeful that it will not take much time. > >=20 > > Please send your review to the list, > >=20 > > thanks, > >=20 > > Ted > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_BD09B6E4-8A68-4418-B5F2-A6B8E5914711 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6 Mar 2019, at 03:34, Justin Uberti <juberti@google.com> = wrote:

We'll always mask any local addresses with mDNS, = since we don't know if they're public or not. We will also provide a = srflx candidate with the actual address should STUN tell us that = information.

So = the =E2=80=98always=E2=80=99 should be conditional on how the addresses = are =E2=80=98found=E2=80=99?
Perhaps a definition of Local IP = addresses would help:
=E2=80=9CLocal IP addresses means = addresses discovered by interrogating the operating system = for
a list of available interfaces and their associated IP = addresses=E2=80=9D 

Plus a = clarification that =E2=80=9Cthese rules do not apply to addresses that = are subsequently found via
STUN or ICE - note that this may = cause an address to be listed twice - once as a host candidate with a = masked mdns
and a second time with it=E2=80=99s IP address as = a reflex candidate=E2=80=9D

(I=E2=80=99= ve a feeling there is section of the ICE RFC that talks about = eliminating reflex candidates that duplicate host = candidates 
but can=E2=80=99t find it)

Tim.  


Agree though we should = be consistent on terminology, will look into what the best option is = there.

On Tue, Mar 5, 2019 at 1:40 PM westhawk = <thp@westhawk.co.uk> wrote:
On first reading it seems like there = might be a conflation of private IP addresses and local IP addresses.
the [ip-handling] document uses the term 'Private local IP addresses=E2=80= =99 where as this document
uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any
explanation (I can find) of the difference.

Surely this would mean that a standalone device (say a public kiosk) = assigned a
single routable public IP would mask that address with mdns.

Tim.





> On 5 Mar 2019, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> draft-uberti-ip-handling-ex-mdns is a very short draft describing = two new modes  related to draft-ietf-rtcweb-ip-handling using bits = of draft-ietf-rtcweb-mdns-ice-candidates.
>
> The chairs would like to ask for a couple of reviews; given that it = is four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=

= --Apple-Mail=_BD09B6E4-8A68-4418-B5F2-A6B8E5914711-- From nobody Wed Mar 6 06:41:44 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF67126DFA; Wed, 6 Mar 2019 06:41:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Eric Rescorla To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155188329644.5174.17334517016853007042.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 06:41:36 -0800 Archived-At: Subject: [rtcweb] Eric Rescorla's Recuse on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 14:41:37 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Recuse When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am an author From nobody Wed Mar 6 07:03:13 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3E1277D7; Wed, 6 Mar 2019 07:03:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Eric Rescorla To: "The IESG" Cc: rtcweb@ietf.org, Sean Turner , draft-ietf-rtcweb-ip-handling@ietf.org, sean@sn3rd.com, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 07:03:05 -0800 Archived-At: Subject: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:03:06 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3744 COMMENTS S 3. > > 1. If the client is multihomed, additional public IP addresses for > the client can be learned. In particular, if the client tries to > hide its physical location through a Virtual Private Network > (VPN), and the VPN and local OS support routing over multiple > interfaces (a "split-tunnel" VPN), WebRTC will discover not only This might be simpler if you said "route traffic over" rather than "support routing" Also, do you want to say "may discover" because the guidelines below would potentially stop that. S 6.2. > addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to > route WebRTC traffic the same way as it would HTTP traffic. STUN and > TURN will work as usual, and host candidates can still be determined > as mentioned below. > > 6.2. Determining Host Candidates This is framed a little confusingly, because all host candidates are suitable in mode 1. Perhaps add "In modes XXX..." From nobody Wed Mar 6 07:40:31 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3AF1275E9; Wed, 6 Mar 2019 07:40:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Alissa Cooper To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155188682137.5077.17601261340644016842.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 07:40:21 -0800 Archived-At: Subject: [rtcweb] Alissa Cooper's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:40:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." alice@example.org is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's." From nobody Wed Mar 6 07:41:36 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE281275E9; Wed, 6 Mar 2019 07:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=RqGYtdt2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hr1koPD+ 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 j0hPJqc1s7xf; Wed, 6 Mar 2019 07:41:16 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94FE1277D6; Wed, 6 Mar 2019 07:41:16 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DE7EA26824; Wed, 6 Mar 2019 10:41:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 06 Mar 2019 10:41:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=a uwESmY8YHqyWD7p7Z3cPVgLnDUeKLKSzgqDrmggw5M=; b=RqGYtdt2EqFdt+WUF 3PU/H2MFBoij9MLI5weJdQgL+64jD0KZLHidd/QBC17/XGFNEePpeWl1tZighdAv N4p0rDu1tS5zUtlGTAvsA+m29S2c8a7uq+HnaZZpX/U9Rj4Z8LAlNCm2Kfm/QBtW YRWjFbCjX/Su5teVVXtjRWzbIHhPfmvFc+yAXPWmUIZqbEmhxEp2cZwO+yDvlq4S t8iCyC+9YU5n0k6QTEIwTF1q4qeBbd1PIZmZfujbeyv9FHSFoUwejRaHW8AIuv5R OVvI0ocvAPcx7ik7T9jNyUzD+SAKpoNJzdlyK08MwHtFvuO8FGoKEf3O0zJxWoC+ 6B06g== DKIM-Signature: v=1; a=rsa-sha256; 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=auwESmY8YHqyWD7p7Z3cPVgLnDUeKLKSzgqDrmggw 5M=; b=hr1koPD+Q29DrQdOvVdEc2wMKJn8f1QyfItlU/4OtpiqgLu1O4Da7xknM 3MrP7mIcOHCYGyPFjm8HK75Y2iXBH/qJh9h5kLENTgZfmY97cppQKCd37WXz+Wyw H6xIczK7aS97//L75PISnoU69/IDNqiREhKq4Uwymmyii54s6woFbzJGOLiwhJvB h9XuUROzR0OkhNvgsH4NgpBXnwLTBI7EcC4fiYFHnHYfQs4mNMDtl0S7Ic5GHrDd 4OAHiUWr5Uc68y74NvboS8NDsttCn9TiIDnJYvJ7m/PdCnijoeR6gC8K+fioPX0B KI4Vvcv/cvlBdper1hqnrbhsZ7A6w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeeigddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpegvvhhilhdrohhrghdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghdpvgigrghm phhlvgdrohhrghenucfkphepudejfedrfeekrdduudejrdejgeenucfrrghrrghmpehmrg hilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhi iigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 7FB83E46AB; Wed, 6 Mar 2019 10:41:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: Date: Wed, 6 Mar 2019 10:41:13 -0500 Cc: General Area Review Team , draft-ietf-rtcweb-security-arch.all@ietf.org, rtcweb@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <154973824800.29421.10047365396889314189@ietfa.amsl.com> To: Sean Turner , Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Genart last call review of draft-ietf-rtcweb-security-arch-18 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:41:19 -0000 Russ, thank you for your review. Sean, thank you for your responses. I = entered a Yes ballot. The use of =E2=80=9Csettings=E2=80=9D reads ok to me. Alissa > On Feb 20, 2019, at 10:09 PM, Sean Turner wrote: >=20 > I generated PR for these: > https://github.com/rtcweb-wg/security-arch/pull/85 >=20 >> On Feb 9, 2019, at 13:50, Russ Housley wrote: >>=20 >> Reviewer: Russ Housley >> Review result: Almost Ready >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >> . >>=20 >> Document: draft-ietf-rtcweb-security-arch-18 >> Reviewer: Russ Housley >> Review Date: 2019-02-07 >> IETF LC End Date: 2019-02-15 >> IESG Telechat date: unknown >>=20 >> Summary: Almost Ready >>=20 >>=20 >> Major Concerns: >>=20 >> Section 4.1 says "... preferably over TLS ...", but it does not tell >> what the consequences are if TLS is not used. Since this is the >> security architecture, I would expect these consequences to be >> described. >=20 > There is s9.1 that addresses this :) >=20 >> Section 4.2: Please add a sentence or two that defines Interactive >> Connectivity Establishment (ICE) data and non-ICE data. >=20 > Since s4.2 of this document points to s4.2 of security-arch and = there=E2=80=99s an entire subsection on ICE I am hoping that the = references are enough. >=20 >> Section 6.5 includes a contradiction. One place it says, " MUST NOT >> negotiate cipher suites with NULL encryption", and another place it >> says, "if Null ciphers are used ...". Please make these consistent. >=20 > I deleted the display requirements section because I think the = prohibiting on negotiating NULL drives the display requirement. >=20 >> Section 6.5 requires implementation of certificate fingerprints or a >> Short Authentication String (SAS). Please add a sentence to tell how >> they are used to provide out-of-band verification. Without such a >> sentence, it is easy to imagine an implementation with a UI that is >> too awkward to actually get the information on the screen while the >> call is in progress. >=20 > Would something like this work: >=20 > These are compared by the peers to authenticate one another. >=20 >> Section 10: since this is a standards track document, the IESG should >> be responsible for this new codepoint, not the document author. >=20 > changed >=20 >> Minor Concerns: >>=20 >> Section 3.1 uses https://www.evil.org/ as an example. However, this = is >> a registered domain. It would be better to follow the IESG statement = on >> examples: https://www6.ietf.org/iesg/statement/examples.html. >=20 > I was really hoping a Dr. Evil included their info the DNS. It = wasn=E2=80=99t there. > I changed to http://example.org >=20 >> Section 6.2 uses customerservice@ford.com as an example. Of course, >> ford.com is a registered domain. It would be better to follow the = IESG >> statement on examples (the URL is above). >=20 > Changed it to customerservice@example.org >=20 >> Section 7 uses Poker Galaxy as an example. Of course, this is a = real >> web site. It would be better to follow the IESG statement on examples >> (the URL is above). It seems best to use the same names here as are >> used in Section 7.2. >=20 > I changed to =E2=80=9Ca poker site=E2=80=9D to match that phrase, = which is used in the 1st para of that section. >=20 >> Nits: >>=20 >> Section 1 includes: "... SDP-based like SIP." Please add a reference >> for SDP. >=20 > I have to admit that I=E2=80=99d probably be confused if there was a = reference to SDP after "SDP-based like SIP [RFC4566]=E2=80=9D and it = reads a little awkward if we do "SDP-based [RFC4566[ like SIP. RFC 4566 = is referred to in s3 when the SDP attribute is defined and there=E2=80=99s= a reference tor SIP, which also refers to SDP, earlier. I tend think = the reader won=E2=80=99t be that confused ;) >=20 >> Section 4.1: s/ permissions till later/ permissions until later/ >=20 > Fixed >=20 >> Section 4.4: please add a reference for STUN. >=20 > The reference is a sentence later. >=20 >> Section 6.2: s/(though see Section 6.3/(See Section 6.3/ >=20 > fixed >=20 >> Section 6.4: please do not enclose the note is '[' and ']'. Avoid >> confusion with reference syntax. One solution is to put the note at >> the end of the paragraph. >=20 > fixed (I just remove the [ ]). >=20 >> Section 6.4: s/non-turn candidates/non-TURN candidates/ >=20 > fixed >=20 >> Section 6.5: the phrase "Implementations MUST implement" seems = awkward. >> Perhaps "Implementations MUST support". This appears several places. >=20 > fixed >=20 >> Section 6.5 ought to begin with "All data channels MUST be secured = via >> DTLS." This appears half way through the section, but the material = that >> comes before is really in support of this sentence. >=20 > Eh - when I read that I thought - generic requirements and then ones = for media and the data channels. >=20 >> Section 8.1 discusses "@", but the discussion of "user" >> (note the quotes) and the discussion of domain (note the absense of >> quotes) are using different conventions. Please use quotes in both >> places or neither place. >=20 > I think I fixed this. >=20 >> There are places in this document where "settings" is confusing. It = is >> unclear whether the word is referring to configuration settings or it >> is referring to an environment or situation. Please look at each use >> of this word and consider alternatives. >=20 > I=E2=80=99ll leave this for ekr. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Mar 6 09:34:08 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC87212D4E9 for ; Wed, 6 Mar 2019 09:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 vB9YXgaFYxVH for ; Wed, 6 Mar 2019 09:34:05 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3927C12796B for ; Wed, 6 Mar 2019 09:34:05 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id d25so9152503pfn.8 for ; Wed, 06 Mar 2019 09:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Jz0wz73fCz/JZJs0gxJZBNhDGiMvJQMqnOqvchy7xng=; b=ISxraV8PN71CmGoShQ9KxwfZdEA3f3st/7l614gUiO9iydz5nUJxiMuCz1loFnQxT6 njxMDLolqabpOG7SJWoYqpJyW2Q8+w3uHtd5DqdJQmMrYSKnGnCzJUoQQdnP76JCFzFn R5g9rrCCGt+s+/pYix/xih/aRpDTKXhSlx9Ls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Jz0wz73fCz/JZJs0gxJZBNhDGiMvJQMqnOqvchy7xng=; b=t0OvevEGO7YRqsoIJAoDr402Wuaph+g7cRds0x/zIM0ufQsY8Nk1Wg9MwI5qhdPsfL mCeJtZ1ON5bn1Ml/KC2Unypsbu72YmNyb+sGzeqm+f9lRQvf7UHLV7G4+BdL334jfpRK gV9mWO2u1PmcdD8QGL74rUtd0X5Fgl2keXmE94mHy1Dtn1FfUg8lH/mpooaJq/OfS6WX n+sCwC0q1t/Te3mdyW4uUsuQJnf8SgZ3DQG5Sk2Qc8rObc4lVa0HyGdWhPMQa2umSmcq ePYPsvepalu7OL36cWE5NF1NqSQbkJe61lT7Mj3vT7+uUzYMB1FGylb9NBanaPIYYDrt EUFA== X-Gm-Message-State: APjAAAXW5NEvUG8kZlSjHg8ZQwvFqapRMDFepuubr+XQ+odVBBuiXgts NnwmQiGDcvdcqYK1wd2IZV9lKg== X-Google-Smtp-Source: APXvYqzVU/VYjVSdVRlFVpA0v7rYs+FB9QRJYllvaTzJqJ/IRrzurwrWQHN4Bv+R0EpICEKAiFTdOg== X-Received: by 2002:a65:4203:: with SMTP id c3mr7318624pgq.271.1551893644261; Wed, 06 Mar 2019 09:34:04 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:142a:bdda:606e:3d5c? ([2601:647:4600:3f31:142a:bdda:606e:3d5c]) by smtp.gmail.com with ESMTPSA id s1sm2737042pgv.30.2019.03.06.09.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 09:34:03 -0800 (PST) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4A5C051D-9513-4F0F-8432-C251E5F05176" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 09:34:02 -0800 In-Reply-To: Cc: Justin Uberti , RTCWeb IETF To: westhawk References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 17:34:08 -0000 --Apple-Mail=_4A5C051D-9513-4F0F-8432-C251E5F05176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6Mar, 2019, at 02:11, westhawk wrote: >=20 >=20 >=20 >> On 6 Mar 2019, at 03:34, Justin Uberti > wrote: >>=20 >> We'll always mask any local addresses with mDNS, since we don't know = if they're public or not. We will also provide a srflx candidate with = the actual address should STUN tell us that information. >=20 > So the =E2=80=98always=E2=80=99 should be conditional on how the = addresses are =E2=80=98found=E2=80=99? > Perhaps a definition of Local IP addresses would help: > =E2=80=9CLocal IP addresses means addresses discovered by = interrogating the operating system for > a list of available interfaces and their associated IP addresses=E2=80=9D= =20 Isn=E2=80=99t this the definition of a host candidate? That would have been my interpretation of local addresses any way. > Plus a clarification that =E2=80=9Cthese rules do not apply to = addresses that are subsequently found via > STUN or ICE - note that this may cause an address to be listed twice - = once as a host candidate with a masked mdns > and a second time with it=E2=80=99s IP address as a reflex = candidate=E2=80=9D >=20 > (I=E2=80=99ve a feeling there is section of the ICE RFC that talks = about eliminating reflex candidates that duplicate host candidates=20 > but can=E2=80=99t find it) Yes it has. It might be hidden in one of the sections about peer = reflexive candidates. Nils >=20 > Tim. =20 >=20 >>=20 >> Agree though we should be consistent on terminology, will look into = what the best option is there. >>=20 >> On Tue, Mar 5, 2019 at 1:40 PM westhawk > wrote: >> On first reading it seems like there might be a conflation of private = IP addresses and local IP addresses. >> the [ip-handling] document uses the term 'Private local IP = addresses=E2=80=99 where as this document >> uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any >> explanation (I can find) of the difference. >>=20 >> Surely this would mean that a standalone device (say a public kiosk) = assigned a=20 >> single routable public IP would mask that address with mdns. >>=20 >> Tim. >>=20 >>=20 >>=20 >>=20 >>=20 >> > On 5 Mar 2019, at 20:22, Ted Hardie > wrote: >> >=20 >> > Howdy, >> >=20 >> > draft-uberti-ip-handling-ex-mdns is a very short draft describing = two new modes related to draft-ietf-rtcweb-ip-handling using bits of = draft-ietf-rtcweb-mdns-ice-candidates. >> >=20 >> > The chairs would like to ask for a couple of reviews; given that it = is four pages long, we are hopeful that it will not take much time. >> >=20 >> > Please send your review to the list, >> >=20 >> > thanks, >> >=20 >> > Ted >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb = >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_4A5C051D-9513-4F0F-8432-C251E5F05176 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6Mar, 2019, at 02:11, westhawk <thp@westhawk.co.uk> = wrote:



On 6 Mar 2019, at 03:34, Justin Uberti <juberti@google.com> = wrote:

We'll always mask any local addresses with mDNS, = since we don't know if they're public or not. We will also provide a = srflx candidate with the actual address should STUN tell us that = information.

So the =E2=80=98always=E2=80=99 should = be conditional on how the addresses are =E2=80=98found=E2=80=99?
Perhaps a definition of Local IP addresses would = help:
=E2=80=9CLocal IP addresses means addresses = discovered by interrogating the operating system for
a list of available interfaces and their associated IP = addresses=E2=80=9D 

Isn=E2=80=99t this the definition of a host = candidate?
That would have been my interpretation of local = addresses any way.

Plus a clarification that =E2=80=9Cthese = rules do not apply to addresses that are subsequently found = via
STUN or ICE - note that this may cause an = address to be listed twice - once as a host candidate with a masked = mdns
and a second time with it=E2=80=99s IP address = as a reflex candidate=E2=80=9D

(I=E2=80=99ve a feeling there is = section of the ICE RFC that talks about eliminating reflex candidates = that duplicate host candidates 
but can=E2=80=99= t find it)

Yes it has. It might be hidden in one of the sections = about peer reflexive candidates.

  Nils


Tim.  

Agree though we should be consistent = on terminology, will look into what the best option is = there.

On Tue, Mar 5, 2019 at 1:40 PM westhawk = <thp@westhawk.co.uk> wrote:
On first reading it seems like there = might be a conflation of private IP addresses and local IP addresses.
the [ip-handling] document uses the term 'Private local IP addresses=E2=80= =99 where as this document
uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any
explanation (I can find) of the difference.

Surely this would mean that a standalone device (say a public kiosk) = assigned a
single routable public IP would mask that address with mdns.

Tim.





> On 5 Mar 2019, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> draft-uberti-ip-handling-ex-mdns is a very short draft describing = two new modes  related to draft-ietf-rtcweb-ip-handling using bits = of draft-ietf-rtcweb-mdns-ice-candidates.
>
> The chairs would like to ask for a couple of reviews; given that it = is four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_4A5C051D-9513-4F0F-8432-C251E5F05176-- From nobody Wed Mar 6 11:08:54 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5171224E8; Wed, 6 Mar 2019 11:08:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Benjamin Kaduk To: "The IESG" Cc: draft-ietf-rtcweb-security@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 11:08:47 -0800 Archived-At: Subject: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:08:47 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-security-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow. Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I mostly only have editorial comments, though there are a few that are more content-ful. Section 1 As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. Section 3 Huang et al. [huang-w2sp] summarize the core browser security guarantee as: Users can safely visit arbitrary web sites and execute scripts provided by those sites. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. Note that for non-HTTPS traffic, a network attacker is also a Web attacker, since it can inject traffic as if it were any non-HTTPS Web site. Thus, when analyzing HTTP connections, we must assume that traffic is going to the attacker. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker." (A thought experiment might be to consider whether wss:// traffic counts as "HTTPS traffic".) Section 3.1 It might be appropriate to provide some example references in place of "extensive research". Section 4.1 In either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. [...] nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). 00000000000000000000000000000000000000000000000000000000000000000000By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. [...] nit: "local" is perhaps overly restricting, depending on interpretation Section 4.1.1 Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. Section 4.1.3 Now that we have seen another use case, we can start to reason about nit: I'm confused by "another" here. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an iframe on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. Section 4.1.4 3. The attacker forges the response apparently http://calling- service.example.com/ to inject JS to initiate a call to himself. seem to be missing a word or two here. which contain untrusted content. If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. nit: "If any page" is more emphatic, I think. Section 4.2 Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? Section 4.2.1 There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?). And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. Section 4.2.2 A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). Where TCP is used the risk is substantial due to the potential presence of transparent proxies and therefore if TCP is to be used, then WebSockets style masking MUST be employed. nit: "employed" to obfuscate what, exactly? Section 4.2.3 refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about. Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications? (E.g., a WebRTC client calling some other sort of video chat system?) leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats is less severe. nit: "threat is" Section 4.2.4 Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. Is "answered" supposed to be some interaction with the controlling site? In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor [http://www.torproject.org] or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. [...] Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. Section 4.3.1 [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). The signaling channel/calling service can be used to authenticate this mechanism. To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? Section 4.3.2.1 Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. nit: "browser to use trusted UI" Section 4.3.2.3 It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? Section 4.3.2.4 I.e., I must be able to verify that the person I am calling has engaged a secure media mode (see Section 4.3.3). In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections. This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) Section 9.2 The coordinates for [OpenID] don't seem quite right. From nobody Wed Mar 6 11:29:15 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AE513120D; Wed, 6 Mar 2019 11:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 XnOKlYSClVqM; Wed, 6 Mar 2019 11:29:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391F413120B; Wed, 6 Mar 2019 11:29:07 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26JSxJ2079174 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 13:29:05 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551900546; bh=yaVoPuLdWUsSQGHdgWo7uVOzAxCvcsjg4W82M+ACqlM=; h=From:Subject:To:Cc:References:Date:In-Reply-To; b=MxFSxoW/u2/u2YsUWhBDKmbgk7d9eLuCeCju5PN8cmSFke3BHP3h0DA0tAW4trDmV JRNZWAcwx4ZzTkAk+FrS0oKSxdoitVnTDFyGUkXWnbc0EnUYfQWg9neirW6pIWQM0o lZlWNSJXhan7+6TgIIYCYH03/+QYL+S41jZdtUhk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at From: Adam Roach To: Datatracker on behalf of Benjamin Kaduk , The IESG Cc: draft-ietf-rtcweb-security@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org, sean@sn3rd.com References: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> Message-ID: <83e273b7-09b8-6560-097b-9410c2f8f9fd@nostrum.com> Date: Wed, 6 Mar 2019 13:28:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:29:08 -0000 I wanted to quickly respond to the two discuss questions you have. On 3/6/19 1:08 PM, Datatracker on behalf of Benjamin Kaduk wrote: > Mutually-verifiable "secure mode" seems to require that the peer's browser be included in > the TCB, which is a bit hard to swallow. Are we comfortable wrapping that in alongside > "we trust the peer to not be malicious"? You are correct that this is part of the assumption of the model, and the reason it makes any sense at all is that the "attacker" of concern here is a web app. To mount an attack with the current assumptions, a malicious app would need to somehow compel a user to install a malicious browser platform prior to using its app. Another way of thinking about this is: unless we are going to require the validated use of a crytographically secured operating system with signed, secure audio and video drivers that require HDCP, running on Trusted Computing hardware, then we need to draw a line somewhere, beyond which the media is considered in a "safe enough" environment. > It's not clear how much benefit we can get from *optional* third-party identity providers; > won't the calling service have the ability to silently downgrade to their non-usage even if > both calling peers support it? The notion here is that the web browser itself provides indicia that mean "this media is secure and being sent only to " in a way that web pages cannot. So you are correct that it's up to the web app to opt-in to this feature; but whether they do so is user-visible. So, e.g., if you host a service that claims its media cannot be intercepted (e.g., in the style of Signal, Wire, or WhatsApp), users can trivially verify whether such a claim is true. /a From nobody Wed Mar 6 11:32:38 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2361C13120E; Wed, 6 Mar 2019 11:32:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Alissa Cooper To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155190075113.14093.15331394358094926932.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 11:32:31 -0800 Archived-At: Subject: [rtcweb] Alissa Cooper's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:32:31 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. From nobody Wed Mar 6 11:33:53 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAFA1224E8; Wed, 6 Mar 2019 11:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=dZQ9NfBy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vTUxdgJf 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 C0M_ccqHroak; Wed, 6 Mar 2019 11:33:38 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D20128B36; Wed, 6 Mar 2019 11:33:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 23D1021D72; Wed, 6 Mar 2019 14:33:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 06 Mar 2019 14:33:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=o wiLVsV9nIMmpJ3IKgsMCheV1QyBKoMt650aXqWpPz8=; b=dZQ9NfByn9Wl5GHOz 7I5EGQtkxlVIMZS0q/rpE12j8rnbIk7vDkehhgD9Qu6MZJFsO6P+NlnsWBIVCHBY fwDrLQOo0S40EsKziGcX5TF7gaQzq3kyR1scHjj5qsfDOtJPnVXLsKu07xEPPd8X quMic6GzSqBgx2F5Ru8CFfZ7C1pAjeyirsPz37nDSW7sDLumunS8ZMEfTpmY0REv HifaZHiNCwY3VJpwTvnO/YZtQE7sKjidInfrwAUdACWj1vVU9eCVkbdf/euA/24S LUbh79lyuhqnt31CVaDcRMzr7eCtiVJM4RPVdEcbMpt8y/mJWIZjfPv34dTR2ccN t7xGA== DKIM-Signature: v=1; a=rsa-sha256; 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=owiLVsV9nIMmpJ3IKgsMCheV1QyBKoMt650aXqWpP z8=; b=vTUxdgJfStEx5LDm9BkA6tbv1xj7PnAMXn4DiuvkUIzg6ZSNiYF56r7Jx /nWGoWpo6eKvgTVc4/vULYq8nq598JqrSO5JZ2idPA8Ft96z8H9pYmILhJKmfBLp khGUDbSDdKPepCjC9Fe57jZ9DKBcD9pGPLTMTEIWpORHI2jfvuAwJJr3SgTi7FWc I+TLrGDkvBm2EgFJeqFSCmtjEtno/YcWOVsr5P8b3o48WWGfFu67CFwi6+BiWZ9F /ZjbitqJGumUc45MjF5ETHgIleNVNHLbFD9kqa2OjgDkm4rW6oQxJAacY/mgUQ9T 6zrqyYxDsubYzi1Y/BzBX5fxqzO2Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeeigdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdejgeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 81C9E10310; Wed, 6 Mar 2019 14:33:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155138469731.28638.15165601679967743186@ietfa.amsl.com> Date: Wed, 6 Mar 2019 14:33:35 -0500 Cc: General Area Review Team , draft-ietf-rtcweb-ip-handling.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D16ADDF-228A-485E-B9FC-67B279BC6385@cooperw.in> References: <155138469731.28638.15165601679967743186@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [Gen-art] Genart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:33:41 -0000 Vijay, thanks for your review. I entered a No Objection ballot and = pointed to your review therein. Alissa > On Feb 28, 2019, at 3:11 PM, Vijay Gurbani = wrote: >=20 > Reviewer: Vijay Gurbani > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-rtcweb-ip-handling-?? > Reviewer: Vijay K. Gurbani > Review Date: 2019-02-28 > IETF LC End Date: 2019-02-15 > IESG Telechat date: 2019-03-07 >=20 > Summary: Ready as a proposed standard with 1 minor comment and some = nits. =20 > In the enumeration below, "Sn" stands for "Section n". >=20 > Major issues: >=20 > Minor issues: > - S8: Perhaps a short sentence like the following one is a bit more > descriptive than the current text in the section. (Please feel free = to > use your editorial discretion to disregard this comment, just that it > does not hurt to be explicit in standard documents. At least that is = my > opinion.) >=20 > This document has described leak of IP address privacy when WebRTC > engages in peer-to-peer connections. This document suggests > mitigations against the leak of this privacy in the form of > four different modes of WebRTC communications that explicitly guide > the WebRTC developer in making an informed choice on how private = the > peer-to-peer communication should be. >=20 > Nits/editorial comments:=20 > - S3: s/private physical\/virtual/private physical or virtual/ > - S3: > OLD: > ...exposed upwards to the web application, so that they can be > communicated to the remote endpoint for its checks. > NEW: > ...provided to the web application so they can be communicated to > the remote endpoint for connectivity checks. > - S3: s/concerns, #1/concerns, the first/ > (Similarly for other places where you have #2, etc. Better to be > pedantic and minimize colloquialism when writing RFCs.) > - S4: s/As a result, we want to avoid blunt solutions/As a result, the > preference is to avoid blunt solutions/ > (Reason: Pronouns like "We" are fine for academic paper, but perhaps > avoided in RFCs.) > - S6.2: > - s/sent to the web application host/sent to the remote web = application host/ > - s/and TCP get the same routing/and TCP get the same routing = treatment/ >=20 > Thanks! >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 6 11:34:30 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646A61312E6; Wed, 6 Mar 2019 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 3-pZDTalrwl1; Wed, 6 Mar 2019 11:34:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A412613125F; Wed, 6 Mar 2019 11:34:14 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26JYBNv080060 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 13:34:13 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551900854; bh=bb+GF/xvPmvmBdnu5dxlsvkE2sv4otu9TxTssD1KEvU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TTyIewyVH+CMEWzVxIxDzs4OcUSmjAKfqiLm7JAfyO7gx909OyjW0JgypUgtgEuHR s0QeeE1pyWU3L9FJ/ZLscsWSK5c+ReslbqPZfbCFuCzraKC9QRE38IT0l5Qd4Dvyf5 9RSokWn+pdeZBFqeT3SoFG/leYeQpvrrpGbLDApA= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: "Mirja Kuehlewind (IETF)" , Eric Rescorla Cc: draft-ietf-rtcweb-security@ietf.org, RTCWeb IETF , The IESG , rtcweb-chairs@ietf.org References: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 6 Mar 2019 13:34:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-rtcweb-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:34:24 -0000 On 3/5/19 3:52 AM, Mirja Kuehlewind (IETF) wrote: > Hi Ekr, > > see below. > >> Am 28.02.2019 um 22:22 schrieb Eric Rescorla : >> >> >> >> --------------------------------------------------------------------- >> >> I think this document is clearly informational. Other RTCweb documents should >> refer this document informatively and only reference the sec arch doc >> normatively. >> >> I don't feel strongly one way or the other. I will defer to the AD. > > I will wait for more feedback from other ADs and then clear my discuss respectively. However, to be honest I also don’t quite fully understand the split between this doc and the sec-arch one. But maybe that just me... One additional point regarding the publication status of this document to consider is that it is intended to inform not just IETF efforts in this space, but W3C efforts as well. From that inter-SDO collaboration perspective, I believe having it clear the higher bar of Standards Track is an important signal regarding the level of consensus and review it has received. /a From nobody Wed Mar 6 11:37:35 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10F128B36; Wed, 6 Mar 2019 11:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 PWiZD556ThHe; Wed, 6 Mar 2019 11:37:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE2F1275F3; Wed, 6 Mar 2019 11:37:28 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26JbJi1080570 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 13:37:20 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551901041; bh=AxflgBu55NZAtnOTwVP8RPUuYWxLW7POz9nE2yvGETE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QVTCDSTBG7AFmaWqXkw7bjopoo6n6ETLjAg43B/mxpU5+YsJlcjRlhVCTIlJnMlbs 21K+1JWuUkbgJVhu1i6M5mHH1rvAmSCK6d6ddpLWUfOiR60lZ86eK1lbIwmI72m/71 HrR2+MGQGLPvjYSy5Fv2r7Fz/VZnybhvh9TCRpCc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Alexey Melnikov , The IESG Cc: rtcweb-chairs@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, draft-ietf-rtcweb-security-arch@ietf.org References: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <2c600fc6-ca2c-2cd5-f677-6edcd0a6f3b7@nostrum.com> Date: Wed, 6 Mar 2019 13:37:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Alexey Melnikov's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:37:30 -0000 On 3/5/19 3:52 AM, Alexey Melnikov wrote: > My apologies for filing a procedural DISCUSS on this, but I am looking at: > > 7.5. Determining the IdP URI > > 3. The path, starting with "/.well-known/idp-proxy/" and appended > with the IdP protocol. Note that the separator characters '/' > (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, > lest an attacker be able to direct requests outside of the > controlled "/.well-known/" prefix. Query and fragment values MAY > be used by including '?' or '#' characters. > > "idp-proxy" is not registered in the IANA's > > registry and this document doesn't register it either. If I missed where this > is registered, please point me to the right document. If I haven't, please > register it in this document. > Good catch! Thanks. /a From nobody Wed Mar 6 11:44:33 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A51275F3; Wed, 6 Mar 2019 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 RypgCWW40Y5w; Wed, 6 Mar 2019 11:44:24 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810101.outbound.protection.outlook.com [40.107.81.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EF91224E8; Wed, 6 Mar 2019 11:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vGOZK8hji9lXG3xZmThLlKHhvFowvSXchF/8Xagofoo=; b=AaaoKnVEw1h9AiNnVX6evEO/zEexBWH2s8teJa+EEWiBF2wYppoyYDr7pOsBibSMw0FLaYg4Q9ymKgE98Tb8xHi5fbL5ly9iYzJbmKpX8+4Y+GUbZtOTZNiKrIGlATUo+eS74pu7fzKo0uB/bjzoPqO+jUbUx68Otm/FZHr570k= Received: from BYAPR01CA0049.prod.exchangelabs.com (2603:10b6:a03:94::26) by MWHPR01MB3294.prod.exchangelabs.com (2603:10b6:300:fd::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.17; Wed, 6 Mar 2019 19:44:22 +0000 Received: from CO1NAM03FT017.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::204) by BYAPR01CA0049.outlook.office365.com (2603:10b6:a03:94::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1665.16 via Frontend Transport; Wed, 6 Mar 2019 19:44:22 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT017.mail.protection.outlook.com (10.152.80.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Wed, 6 Mar 2019 19:44:21 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x26JiHgJ006246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Mar 2019 14:44:19 -0500 Date: Wed, 6 Mar 2019 13:44:16 -0600 From: Benjamin Kaduk To: Adam Roach CC: Datatracker on behalf of Benjamin Kaduk , The IESG , , , , Message-ID: <20190306194416.GO9824@kduck.mit.edu> References: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> <83e273b7-09b8-6560-097b-9410c2f8f9fd@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <83e273b7-09b8-6560-097b-9410c2f8f9fd@nostrum.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(376002)(396003)(2980300002)(199004)(189003)(229853002)(53546011)(15650500001)(8676002)(53416004)(26005)(54906003)(23726003)(486006)(106466001)(246002)(11346002)(88552002)(476003)(956004)(426003)(8936002)(126002)(446003)(186003)(33656002)(316002)(47776003)(106002)(336012)(104016004)(50466002)(2906002)(786003)(16586007)(58126008)(36906005)(76176011)(305945005)(7696005)(55016002)(26826003)(97756001)(6246003)(14444005)(66574012)(478600001)(356004)(6666004)(5660300002)(4326008)(6916009)(1076003)(86362001)(46406003)(75432002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR01MB3294; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6267bc7b-df7c-47ec-aaae-08d6a26c2162 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:MWHPR01MB3294; X-MS-TrafficTypeDiagnostic: MWHPR01MB3294: X-Microsoft-Exchange-Diagnostics: 1; MWHPR01MB3294; 20:u6cLkL/Y8WXB1q+L7TmseBMT6vt3QpyErEecuz8Rqbe7IwODp9RapmGlw+XQv/0YaskCjjcZ8vDRAW5fuYFS9dhZoXQKCUvWOLCceYPj0wAboZZIDFTzBOFWBaG4wR82DlEcWzapVEzZmO0tlJciS+6rMYCMQV1FcfGKUNLCquXBmsVN2PNUang20RegHM+zJhFIcNLHQDMOxNOOTb4JJJV0ER5Wm8TGcmiOCy0Z3vvic4ClMmxRxzA7O7sw6nFEL465bNCbtT73kTjqKayLDuYQcedeV7mq+1wQ1goZ0pS6E9BWAsDoQndy/JyFdTwts18Zqqk6YCIZR650qjzVMkuzBdlBgCoMY97FNvhfl6rBUC4oMqDTIF9KjeCWnhIIOTorymdackgnlsizhS2TYRcXT4S/i9GJ05qD+fhulmSXcFLGnmIasAsr3K3UQYn1ly59h7i6f2w9/l4yMgcugTnLSLlYkCGvwxHm6DCswaOnt/YdVN1sFqSrxrWRtL+MkhUaMbSulCiueud/RSXIMBckfCjjnKTgTqalYCzxvT90iunITUp75oi7G5UR3MfM1bkXZMhvQc1e4cguS+2XsB1QFKGV2V8NIykL+dY+/fE= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0968D37274 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR01MB3294; 23:nifqUe37qStcrExbc3QgjQVFI/Qh+YdIdZNQ6P7Tw?= =?us-ascii?Q?T/sAoUZLeZjumQMe2h/1GFtX8Y9CsmYtisFpGv/x6ccdbvlY2b8iYnLw+cH8?= =?us-ascii?Q?gzAPPaCSB/p3HDLQmvY8ukch8OdVkENIsGneyu2k7tkys415yio6JwceKQBM?= =?us-ascii?Q?nTF0FMwqZNRRZ64lN7lXw0GjEAJ2w9YRsdEMlWUdZKkG3oSZgnh9o/i/x9/5?= =?us-ascii?Q?pn2U81bAsGuj2EFT/RAJg63Fd72++sDy6Q0zmR3DVXzDiR64TKEldCQllyG0?= =?us-ascii?Q?OBAmZJUWklHC0wW1DC/4tCGluWRBmNw6ePpw1l4d/pn1O8Y8RO+TfbLQDKGY?= =?us-ascii?Q?VSANXYDDh9273+5Vpsgh0cVhCpzMLKWIFKWM9Y7tKzMr1UibAW4abRAWUFvh?= =?us-ascii?Q?8TTzJSMjwJlmB0fTz59CNx6CQ2ZfCrl5co+iN97ylJ4WR3OFmgSW3swOd+jD?= =?us-ascii?Q?4Wy7FoMtXnY2TUidLDflhFri/RDRi6x1b3NYV2qVLXycijfd+33jrveT0do1?= =?us-ascii?Q?NJRbpqNzAVHBXw2WRuwT/MjGWBc8Z1fQKFH2AMGYEJl7vF3FlmwN+k68bWtE?= =?us-ascii?Q?n645VaCZJIfUYKTQ1CPpsl/xvYy8bfwHL2zTIFVQnXL784bMS2+n5E7mvcch?= =?us-ascii?Q?ZuiGRts4vthQIrau0Yu2+xCFxYdg/KrBTwqn2v0lSjqwEDCi5fc1qy2OtrcH?= =?us-ascii?Q?AlZoqReTTXhsjL8mPThqT8uu+nJrCkpydmOEjVrQ7HHOfTZtxcKcavdMCQYB?= =?us-ascii?Q?42YcX9lG1GLgdE9dArYLIkd4YHqczj3LmpgtZYKQib9doZDZcIb4O5MzsFQA?= =?us-ascii?Q?RCRmiR+h1YyL2ZjT3xtHSj7W3fG25p+EikcJxd7ORw+rlTxMpT7NIrd767Z7?= =?us-ascii?Q?JOWSgl1XVGy5hpiORVoI53s3KjxT1JJFNvW3VO6n5tVdaAumsrPKRYHwnLUy?= =?us-ascii?Q?7yGuyca6M5P/HbOIsZuiwsuzJf2Tme5lGVUELkACGqxj5Rmp2QKSGrlcBALO?= =?us-ascii?Q?tMuv2oxVnKml1PSCjxcMyoK1M5D6aRWEdabauKPctMaXglMoP4aTOxOGXwzH?= =?us-ascii?Q?El23AueUPq8S9V+Xq7tEvT6WfyBZFvVb74iH8dzXr0B/6sjGpQBAd6j2TnAJ?= =?us-ascii?Q?q+wy6W2b8c5nzmBSoSknUnHQJzWqSQlNspPoPxBvy8dKGlYu4suyTiYT3iDC?= =?us-ascii?Q?JW4PGfliuErKPRYVw6Ogbs3TBKC0o04aMXkV8MKONgMBTZqITyTl33S1mwRO?= =?us-ascii?Q?CdxT1FvRv0whf+fmNLi4Zsu/LM2EZrMU1SVc7Q8pM681UXxO2o65pU38Kjhu?= =?us-ascii?B?Zz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: UFpMDwG7sjoRZaphM7T41X8lxx/m8K6RH/qocyKUyE+OnUF2ErnSCowKsJTKZlUzlYes0EH+rBfcjrwBY1kdqM6CFtE9qfJfknCmRUl3TuThZREkkX5rgo4VlAKHtYx32Q1F1igUgTcrwNxiFWfdM/pjfu6QFYGJyaNGXPU+dzpQ53QTycmfvEP8rYaIM2PZSipTI0cyUu34l44CwA7t5SoTuMjF+8+jhFRHoDHvi84ZG97RP0V5Xja2ieNTfmLuF7qwYDTvCVQviT0CmL5JDMxrToAQVa1qb1OVKx5SYPIzPu2afD+xdO6Mi+zF44VOBUzK7k2y79lInhaERwXl7bIqZmsHbl7/nIDf0pzOKOwdsVMsZ8foSzBv3tPIFBTzlkBqB009y8dTTYyrwsscyq4Giv/6PpNQjPa6ek5eErE= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2019 19:44:21.4788 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6267bc7b-df7c-47ec-aaae-08d6a26c2162 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB3294 Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-11: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 19:44:27 -0000 On Wed, Mar 06, 2019 at 01:28:53PM -0600, Adam Roach wrote: > I wanted to quickly respond to the two discuss questions you have. Thanks; that's enough to clear my Discuss, though I do request that these points be made more clearly in the document itself. -Benjamin > On 3/6/19 1:08 PM, Datatracker on behalf of Benjamin Kaduk wrote: > > Mutually-verifiable "secure mode" seems to require that the peer's browser be included in > > the TCB, which is a bit hard to swallow. Are we comfortable wrapping that in alongside > > "we trust the peer to not be malicious"? > > > You are correct that this is part of the assumption of the model, and > the reason it makes any sense at all is that the "attacker" of concern > here is a web app. To mount an attack with the current assumptions, a > malicious app would need to somehow compel a user to install a malicious > browser platform prior to using its app. > > Another way of thinking about this is: unless we are going to require > the validated use of a crytographically secured operating system with > signed, secure audio and video drivers that require HDCP, running on > Trusted Computing hardware, then we need to draw a line somewhere, > beyond which the media is considered in a "safe enough" environment. > > > > It's not clear how much benefit we can get from *optional* third-party identity providers; > > won't the calling service have the ability to silently downgrade to their non-usage even if > > both calling peers support it? > > > The notion here is that the web browser itself provides indicia that > mean "this media is secure and being sent only to identity>" in a way that web pages cannot. So you are correct that it's > up to the web app to opt-in to this feature; but whether they do so is > user-visible. So, e.g., if you host a service that claims its media > cannot be intercepted (e.g., in the style of Signal, Wire, or WhatsApp), > users can trivially verify whether such a claim is true. > > /a > From nobody Wed Mar 6 15:37:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625721310DF for ; Wed, 6 Mar 2019 15:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 d2mp4G28Uv19 for ; Wed, 6 Mar 2019 15:37:20 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4A813110D for ; Wed, 6 Mar 2019 15:37:18 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p17so11809525iol.7 for ; Wed, 06 Mar 2019 15:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8JWHF4wzSQVqr0rXCZYKlFUf75DbPDA+uFFezlBlclk=; b=wW22+xnfdm4/rlX9EpnLiBasXQOW0N+g3aOuvSdDcKl/UAWokVM+qiCIG8TvaRGCRS MTQRXSnKIuI2o3JJx5qTDfrVCZXp2q6zAlOuEJphAJbfNjVPlJRNNywB8D8Q/1gloQ3e 4ran3x1lxw3HvMWUej9sCYTpBtpare8HoIF0M07usX6NIfVxl7vW3PvbKNYdZRybIChC /o1T7hR74JLyfdU1s/R74Ha0XbMZ87Glt8jYEk4RTVDevYn5EsLlkXkfdC6ywH6F4ayH rR4W5rpeC0LmVD5SuiDmNpSm8F91g2w65XPs1UzRotpoPxy9av+wEjXdN1pnh18CpNDl 79eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8JWHF4wzSQVqr0rXCZYKlFUf75DbPDA+uFFezlBlclk=; b=lhU29sHkl7YGV57d9Oi1vB+vhKZx1+TR6eo4lG71e81thySI71MsbGO8HwOhBhrfp7 ws7LKTZ4mPaXDY32u0ich0QyqqVy9LdZA3bk9i5XmQhy4Oo7yh4G23MyqGP64ONhqCTd OIWSoJymnwxj+LU8VwHCyYzT8k9KYzMRaqf7BUbGlb92LPdIfQUbMpdSRytjJGUkRiur EYO6IYNIW4Q7/f900u46hvA6AbQqTWYAvoeX/8rPs4mfa/AnjuVu1aHRIX6diVVdh6uD 97jBuGOKDYXKPTRXp67vdugdRpgChvK+iOk+ubaLpJrZ/bzsZVCbIZgaopp3xKw5ZhA9 INQA== X-Gm-Message-State: APjAAAX1tEvG3s6EYgF6qoSKpUfOsaZPUmihASB2rzUNRPob+Qufg89Y QD/EPYrYaeH0AhGkJLUKqroLkkjKDb5VkIdREaAAKg== X-Google-Smtp-Source: APXvYqxAektGHliYc8/tkUZbb4ehoPR5OpTKIuJ+CPUzcn8hQbJsMXqQSvqTpp/EvOSbwckA9Hez6ywWFQHIyz+JLq8= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr4359086ioh.95.1551915437400; Wed, 06 Mar 2019 15:37:17 -0800 (PST) MIME-Version: 1.0 References: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> In-Reply-To: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:37:07 -0800 Message-ID: To: Ben Campbell Cc: The IESG , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e98da058375781f" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:37:22 -0000 --0000000000005e98da058375781f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2019 at 7:59 PM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-ip-handling-11: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Mirja that this reads more like a BCP. Was BCP status > considered by the WG? > I don't think it was explicitly discussed. We have been treating this document similarly to the other recommendation documents for WebRTC, e.g. the recommended audio codecs in https://tools.ietf.org/html/rfc7874; these docs are all Standards Track. > > (nit) =C2=A73: Please expand "RTMFP" on first mention. > > (nit) =C2=A75.2: "Mode 1 MUST only be used when user consent has been pro= vided" > Please consider "... MUST NOT be used unless user consent has been > provided." > > =C2=A711.2: It seems like the references for STUN and TURN should be norm= ative. > It wasn't clear to me that STUN and TURN meet the bar of "required to implement this RFC". Open to other points of view here though. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000005e98da058375781f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 4, 2019 = at 7:59 PM Ben Campbell <ben@nostrum.= com> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-rtcweb-ip-handling-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Mirja that this reads more like a BCP. Was BCP status consider= ed by the WG?

I don't think it was = explicitly discussed. We have been treating this document similarly to the = other recommendation documents for WebRTC, e.g. the recommended audio codec= s in https://tools.ietf.org= /html/rfc7874; these docs are all Standards Track.

(nit) =C2=A73: Please expand "RTMFP" on first mention.

(nit) =C2=A75.2: "Mode 1 MUST only be used when user consent has been = provided"
Please consider "... MUST NOT be used unless user consent has been pro= vided."

=C2=A711.2: It seems like the references for STUN and TURN should be normat= ive.

It wasn't clear to me that STU= N and TURN meet the bar of "required to implement this RFC". Open= to other points of view here though.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000005e98da058375781f-- From nobody Wed Mar 6 15:44:22 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7A81310ED; Wed, 6 Mar 2019 15:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Rcatxi8aP1rR; Wed, 6 Mar 2019 15:44:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338CC12F1A2; Wed, 6 Mar 2019 15:44:19 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x26NiDMx021466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 17:44:14 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551915855; bh=X/yFqDf+AT4hWRUzcuwV4zmfsX57vNWKwMBpypvFcEY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=J0AQdjlsvw/XEsED3SIyYy4tXwAb0CQWAEG2n4cpIQwVo0fWyk+JoVstZmPWAuOXQ lRf9LpSLWT9cfM8kOjMobevtsdmkNwP8NBYeKXXAXIwIGLGk/zDMKCVHeL4hbIFlp4 NkUItVcuE3UEBlpK4aCFNgeekSZE2LoP/fSWrKWI= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <65AC0812-0A88-42AD-8645-AC3318E60F8B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6F824338-3390-47FE-B095-D3D86AB8277A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 17:44:06 -0600 In-Reply-To: Cc: The IESG , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb-chairs@ietf.org To: Justin Uberti References: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:44:21 -0000 --Apple-Mail=_6F824338-3390-47FE-B095-D3D86AB8277A Content-Type: multipart/alternative; boundary="Apple-Mail=_72927D29-0A11-4ECD-BEEE-2C762F3AEEA7" --Apple-Mail=_72927D29-0A11-4ECD-BEEE-2C762F3AEEA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 6, 2019, at 5:37 PM, Justin Uberti wrote: >=20 >=20 >=20 > On Mon, Mar 4, 2019 at 7:59 PM Ben Campbell > wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-ip-handling-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with Mirja that this reads more like a BCP. Was BCP status = considered by the WG? >=20 > I don't think it was explicitly discussed. We have been treating this = document similarly to the other recommendation documents for WebRTC, = e.g. the recommended audio codecs in https://tools.ietf.org/html/rfc7874 = ; these docs are all Standards = Track. It=E2=80=99s not a show stopper from my perspective, especially if we = are talking about recommendations to W3C. >=20 > (nit) =C2=A73: Please expand "RTMFP" on first mention. >=20 > (nit) =C2=A75.2: "Mode 1 MUST only be used when user consent has been = provided" > Please consider "... MUST NOT be used unless user consent has been = provided." >=20 > =C2=A711.2: It seems like the references for STUN and TURN should be = normative. >=20 > It wasn't clear to me that STUN and TURN meet the bar of "required to = implement this RFC". Open to other points of view here though. =C2=A77 contains says applications SHOULD deploy a TURN server; that=E2=80= =99s enough to make TURN normative. It=E2=80=99s less clear for STUN, = but I think it passes the =E2=80=9Cnecessary to fully implement or = _understand_=E2=80=9D bar. Ben. --Apple-Mail=_72927D29-0A11-4ECD-BEEE-2C762F3AEEA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 6, 2019, at 5:37 PM, Justin Uberti <juberti@google.com> = wrote:



On Mon, Mar 4, 2019 at 7:59 PM Ben Campbell <ben@nostrum.com> = wrote:
Ben Campbell has entered the following ballot = position for
draft-ietf-rtcweb-ip-handling-11: Yes

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/=



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I agree with Mirja that this reads = more like a BCP. Was BCP status considered by the WG?

I don't think it was explicitly discussed. We have been = treating this document similarly to the other recommendation documents = for WebRTC, e.g. the recommended audio codecs in https://tools.ietf.org/html/rfc7874; these docs are all = Standards Track.

It=E2=80=99s not a show stopper from my = perspective, especially if we are talking about recommendations to = W3C.


(nit) =C2=A73: Please expand "RTMFP" on first mention.

(nit) =C2=A75.2: "Mode 1 MUST only be used = when user consent has been provided"
Please consider "... = MUST NOT be used unless user consent has been provided."
=C2=A711.2: It seems like the references for STUN and TURN = should be normative.

It wasn't clear to me that STUN and = TURN meet the bar of "required to implement this RFC". Open to other = points of view here though.

=C2=A77 contains says applications SHOULD deploy a = TURN server; that=E2=80=99s enough to make TURN normative. It=E2=80=99s = less clear for STUN, but I think it passes the =E2=80=9Cnecessary to = fully implement or _understand_=E2=80=9D bar.

Ben.


= --Apple-Mail=_72927D29-0A11-4ECD-BEEE-2C762F3AEEA7-- --Apple-Mail=_6F824338-3390-47FE-B095-D3D86AB8277A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyAW0YACgkQgFZKbJXz 1A3hZxAAksI7dNuiVfzGfXwhPjfx1NlFXxRv1eoHFSSStRBstGCnVMtvXy1ED/JR yRbCiu1s3H1hiP/eThRnwzYTnnYREnNYUbWdCJBavCTqchJ0Jqv0iuTLjo9ALQeu 8WJq9cnmlQTLWt0/+Xz6TNKFgwo0hiJ/l3tYSd3Drr7oDt7BwO8o03zqaXKH1Qnw EXYtv8huQaMfcmghxwFCnx3UXBvzxdip8jdzTfIYL/AydOAqhZOti0A0Dk9wg8/2 pkVbWoYtg5ER6JmTLC38H8bZwrbkeHPX7MLPSoDq3M2NudWn0rRbFwo5QC6i5LiB IqhJ5tGQLq06iNwdcH6vC/KKuwwkvu9C1vHkoiC+Bwd7QMmzPjBsQqoVSOLfhzD4 1HOV/hgDeAsRipHh5aX+SAoji0As29LGoa90eOfSJJCktwfAJyZwMJgYWRUz2Vik biSYlznyzOIPPMj83okgeuacDWcD/+o+jP2g4R8uyrzVsmRSVu8K2R+fNgMTiPpO 2oY+mrzHxii69s/y0NV/VNkK39wZra1KvWy7GLMJCX5YDedCsIYjZJt6Kkp8njgA bgrfw8Sg4jUoTiyTF5oT2JOBMgQGXqRDk+9Gcnbc16Qt2eJ/g2NezxpkPcW6nEGl +zwPikH7qLjCZyESgHLDizAmXNDfPYaJiQoV+KELqK0B/ZbRI1E= =GsOE -----END PGP SIGNATURE----- --Apple-Mail=_6F824338-3390-47FE-B095-D3D86AB8277A-- From nobody Wed Mar 6 15:45:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8312008A for ; Wed, 6 Mar 2019 15:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CRJRRiJE7Frh for ; Wed, 6 Mar 2019 15:45:15 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8F213110D for ; Wed, 6 Mar 2019 15:45:14 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id p196so11816965iod.9 for ; Wed, 06 Mar 2019 15:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EYf7a1tkguXfM3/avo7+qBjJij/MvhwxajDnaVPByCM=; b=AxosyoT8VgkWkmbLL+HPw84tzWFXKZfvQD0BTg9Y1DsItI0VGIbvGUZEr4l6ZNg1zm Ip1/YhJvhbGKDbMdP76LDWW+JLjcZDlkgYFBDBXG18iu2TrtmceGNh6UTsD4PWMahKQF tpe/y3UgnkJsOwWpzCbuD59+QOGhaaI9xveiF6pZGLSQpXhZVrn/ezbhMBZ5/1oEwY0h QMFBhb+Pj4/vvu4He6JNOXB6vUhsakH4yXe/ADruCiGzBkEaKNwolLQHoJw4TeihShUs qeaQp+/h6TfciKzhGfb5xVXrUGV7mExUd/A6yYSV8AU78U9ZfQuKcj237CIRqxfNf5/9 x2iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EYf7a1tkguXfM3/avo7+qBjJij/MvhwxajDnaVPByCM=; b=nbR4F2w2fMWN3kieNbJ4uBFGe9Lkw8FNG3v686zabyQnKRROjODQq+4No2GlE9UQj8 cFIYocc426OJTH611AtkvFDcSiFk2hnV7VC+Lu9/hS9cMnxYEqUt6oUa3+pzqjXzmXdT ozwSsmlsn0QCK96b46Exz2QKtoCSvEN4MPLSSu6rCp+k/vKccisoGFxyKivQZTjBAdtz GJTnGrvs6oWVT5NfvNXnUaoNJtKR4C845bCDWLkeBUmZ6HIc695rFl3k7djmOkcWdITZ L8bgIGGZuZHqpZ0ES1barWdFZ7Q0zfZYMEM1rUvMjmE3q6m5G48E1dNwr9EpGlYRiNnR nE8A== X-Gm-Message-State: APjAAAUV2TFAcitdMMn+tGdcEzEN9q01cC2Vcp4/X4V0UFCIgihdy4lF gXJakRGxFk8V8BJPYmpD600FgYCQvZ9Za6R6xPdlig== X-Google-Smtp-Source: APXvYqzan18HaV/yO7WTu9HBebM5ijR4/jHCPulTWyG8ewDrK+F7FEIvXFtkLlgI5/YHcgJAmrtsUpi0xhKtsCjYSFY= X-Received: by 2002:a5e:df01:: with SMTP id f1mr4707262ioq.101.1551915913899; Wed, 06 Mar 2019 15:45:13 -0800 (PST) MIME-Version: 1.0 References: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com> In-Reply-To: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:45:02 -0800 Message-ID: To: Datatracker on behalf of Eric Rescorla Cc: The IESG , draft-ietf-rtcweb-ip-handling@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c54729058375945c" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:45:19 -0000 --000000000000c54729058375945c Content-Type: text/plain; charset="UTF-8" On Wed, Mar 6, 2019 at 7:03 AM Datatracker on behalf of Eric Rescorla < ietf-secretariat-reply@ietf.org> wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-rtcweb-ip-handling-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3744 > > > > COMMENTS > S 3. > > > > 1. If the client is multihomed, additional public IP addresses for > > the client can be learned. In particular, if the client tries > to > > hide its physical location through a Virtual Private Network > > (VPN), and the VPN and local OS support routing over multiple > > interfaces (a "split-tunnel" VPN), WebRTC will discover not only > > This might be simpler if you said "route traffic over" rather than > "support routing" > > Also, do you want to say "may discover" because the guidelines below > would potentially stop that. > This is the problem statement section; I think it is expected that the proposed guidelines would invalidate some of the problem definition. That said, I could get behind switching 'will' to 'can', as is used in S3, category #2. > > > S 6.2. > > addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to > > route WebRTC traffic the same way as it would HTTP traffic. STUN > and > > TURN will work as usual, and host candidates can still be determined > > as mentioned below. > > > > 6.2. Determining Host Candidates > > This is framed a little confusingly, because all host candidates are > suitable in mode 1. Perhaps add "In modes XXX..." > This seems like a good addition. --000000000000c54729058375945c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 7:03 AM Datatr= acker on behalf of Eric Rescorla <ietf-secretariat-reply@ietf.org> wrote:
Eric Rescorla has entered the f= ollowing ballot position for
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3744


COMMENTS
S 3.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 1.=C2=A0 If the client is multihomed, additional p= ublic IP addresses for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client can be learned.=C2=A0 In = particular, if the client tries to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hide its physical location through a= Virtual Private Network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (VPN), and the VPN and local OS supp= ort routing over multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interfaces (a "split-tunnel&quo= t; VPN), WebRTC will discover not only

This might be simpler if you said "route traffic over" rather tha= n
"support routing"

Also, do you want to say "may discover" because the guidelines be= low
would potentially stop that.

This is th= e problem statement section; I think it is expected that the proposed guide= lines would invalidate some of the problem definition.=C2=A0

=
That said, I could get behind switching 'will' to 'c= an', as is used in S3, category #2.=C2=A0


S 6.2.
>=C2=A0 =C2=A0 =C2=A0 addresses (0.0.0.0 for IPv4, :: for IPv6), which a= llows the OS to
>=C2=A0 =C2=A0 =C2=A0 route WebRTC traffic the same way as it would HTTP= traffic.=C2=A0 STUN and
>=C2=A0 =C2=A0 =C2=A0 TURN will work as usual, and host candidates can s= till be determined
>=C2=A0 =C2=A0 =C2=A0 as mentioned below.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A06.2.=C2=A0 Determining Host Candidates

This is framed a little confusingly, because all host candidates are
suitable in mode 1. Perhaps add "In modes XXX..."

This seems like a good addition.
--000000000000c54729058375945c-- From nobody Wed Mar 6 15:49:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B512F1A2 for ; Wed, 6 Mar 2019 15:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LbQoPLsx4Zft for ; Wed, 6 Mar 2019 15:49:28 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F771310F7 for ; Wed, 6 Mar 2019 15:49:28 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id d125so6485115ith.1 for ; Wed, 06 Mar 2019 15:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M/Yycqz2JgtbjWoC2VoxcAsmmJ90e62tyOEXKbnYqU4=; b=szwaJWhhLzGmHfi8dSb8LuNCO15IxVcYX8ULzB9cyajfnMZIGsTI3FeM7IINMrrYkk f4nxD5kltlM9yiBKCDRgVoBuPkkmMfQfs0Ly0Bmn2Q/dI8TVcQoCuWyOGcP5uh15zUMa 4wGoIz0fy2AGDZHWbxmxwYzIGexr03f+FYHGiuPwv+jQZKZfmMN/PbdqrwVVNZoJBvgU 7g6lKp3WbOHjCXk/YfOQTjbi0vmN2lSoyPdkdajKiD/WUrhddfep278+X0wgh7y0Royg hpRJkoHWG4rzFrGBcfvz2Lpu5My8VBZwpWMUuneuXjJaUCmPqW22Ng4leVKvdsOwLMqt uJUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M/Yycqz2JgtbjWoC2VoxcAsmmJ90e62tyOEXKbnYqU4=; b=L2pt4yCe/zTmKFiQUl0s8kVVtUAGc1ActTNFMQrMXeYl+AbisXjt4VlgEBOnHjPc3i nQuHw9Yo2ueCmWdZhPNafDJTiY6057HdkM1Soe2kU3R/3HsIuj00tsLJ5nNEC4622HsY +vOCfULEoRei1TR2ND3opVoiO7eKolalibPS09CTe0WHACrap8EAjZsf3EMXW0VU+gbC EtRYt2VilN0PyZWTWBDBellCKNWWvA4hzHk2So6yy7L5QYQq/tonUKlOndZkg5fO61ez VSU2ISW8U/EcuBxKnuK9hE9tIAaaD5q5vLoiiOdn5DgAg3BcEF5uvFGHBE+ooFSvO0ej oNuA== X-Gm-Message-State: APjAAAX9S/fg8CO90eVDJof9+sT4gY5EqeOLTPRBuFBu+lR7LnOiM2/s 1wR2ODP51Dghqs6lq/yEO2/oq3S6R9PtcOcXImpbRA== X-Google-Smtp-Source: APXvYqw8QeH6B2lQmG5OIOXRSfv/EE7pFnjh48ZdRQXnGmfuIYK6mywQzX8Whsftn4upBYnClbf+5JxDOKA0Pc67VAQ= X-Received: by 2002:a24:ccc5:: with SMTP id x188mr3653913itf.123.1551916167261; Wed, 06 Mar 2019 15:49:27 -0800 (PST) MIME-Version: 1.0 References: <155138469731.28638.15165601679967743186@ietfa.amsl.com> In-Reply-To: <155138469731.28638.15165601679967743186@ietfa.amsl.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:49:14 -0800 Message-ID: To: Vijay Gurbani Cc: gen-art@ietf.org, draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF , IETF discussion list Content-Type: multipart/alternative; boundary="000000000000df7d24058375a3c2" Archived-At: Subject: Re: [rtcweb] Genart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:49:31 -0000 --000000000000df7d24058375a3c2 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 28, 2019 at 12:13 PM Vijay Gurbani wrote: > Reviewer: Vijay Gurbani > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-rtcweb-ip-handling-?? > Reviewer: Vijay K. Gurbani > Review Date: 2019-02-28 > IETF LC End Date: 2019-02-15 > IESG Telechat date: 2019-03-07 > > Summary: Ready as a proposed standard with 1 minor comment and some nits. > In the enumeration below, "Sn" stands for "Section n". > > Major issues: > > Minor issues: > - S8: Perhaps a short sentence like the following one is a bit more > descriptive than the current text in the section. (Please feel free to > use your editorial discretion to disregard this comment, just that it > does not hurt to be explicit in standard documents. At least that is my > opinion.) > > This document has described leak of IP address privacy when WebRTC > engages in peer-to-peer connections. This document suggests > mitigations against the leak of this privacy in the form of > four different modes of WebRTC communications that explicitly guide > the WebRTC developer in making an informed choice on how private the > peer-to-peer communication should be. > Sure - happy to add text of this sort if we think it would be valuable. > > Nits/editorial comments: > - S3: s/private physical\/virtual/private physical or virtual/ > - S3: > OLD: > ...exposed upwards to the web application, so that they can be > communicated to the remote endpoint for its checks. > NEW: > ...provided to the web application so they can be communicated to > the remote endpoint for connectivity checks. > - S3: s/concerns, #1/concerns, the first/ > (Similarly for other places where you have #2, etc. Better to be > pedantic and minimize colloquialism when writing RFCs.) > OK. > - S4: s/As a result, we want to avoid blunt solutions/As a result, the > preference is to avoid blunt solutions/ > (Reason: Pronouns like "We" are fine for academic paper, but perhaps > avoided in RFCs.) > :-) > - S6.2: > - s/sent to the web application host/sent to the remote web application > host/ > - s/and TCP get the same routing/and TCP get the same routing treatment/ > > OK. --000000000000df7d24058375a3c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 28, 2019 at 12:13 PM Vija= y Gurbani <vijay.gurbani@gmai= l.com> wrote:
Reviewer: Vijay Gurbani
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-rtcweb-ip-handling-??
Reviewer: Vijay K. Gurbani
Review Date: 2019-02-28
IETF LC End Date: 2019-02-15
IESG Telechat date: 2019-03-07

Summary: Ready as a proposed standard with 1 minor comment and some nits.= =C2=A0
In the enumeration below, "Sn" stands for "Section n".<= br>
Major issues:

Minor issues:
- S8: Perhaps a short sentence like the following one is a bit more
=C2=A0 descriptive than the current text in the section.=C2=A0 (Please feel= free to
=C2=A0 use your editorial discretion to disregard this comment, just that i= t
=C2=A0 does not hurt to be explicit in standard documents.=C2=A0 At least t= hat is my
=C2=A0 opinion.)

=C2=A0 =C2=A0 This document has described leak of IP address privacy when W= ebRTC
=C2=A0 =C2=A0 engages in peer-to-peer connections.=C2=A0 This document sugg= ests
=C2=A0 =C2=A0 mitigations against the leak of this privacy in the form of =C2=A0 =C2=A0 four different modes of WebRTC communications that explicitly= guide
=C2=A0 =C2=A0 the WebRTC developer in making an informed choice on how priv= ate the
=C2=A0 =C2=A0 peer-to-peer communication should be.
Sure - happy to add text of this sort if we think it would be = valuable.

Nits/editorial comments:
- S3: s/private physical\/virtual/private physical or virtual/
- S3:
=C2=A0 OLD:
=C2=A0 ...exposed upwards to the web application, so that they can be
=C2=A0 communicated to the remote endpoint for its checks.
=C2=A0 NEW:
=C2=A0 ...provided to the web application so they can be communicated to =C2=A0 the remote endpoint for connectivity checks.
- S3: s/concerns, #1/concerns, the first/
=C2=A0 =C2=A0(Similarly for other places where you have #2, etc.=C2=A0 Bett= er to be
=C2=A0 =C2=A0pedantic and minimize colloquialism when writing RFCs.)

OK.
=C2=A0
- S4: s/As a result, we want to avoid blunt solutions/As a result, the
=C2=A0 =C2=A0preference is to avoid blunt solutions/
=C2=A0 =C2=A0(Reason: Pronouns like "We" are fine for academic pa= per, but perhaps
=C2=A0 =C2=A0avoided in RFCs.)

:-)
=C2=A0
- S6.2:
=C2=A0 =C2=A0- s/sent to the web application host/sent to the remote web ap= plication host/
=C2=A0 =C2=A0- s/and TCP get the same routing/and TCP get the same routing = treatment/

OK.=C2=A0
--000000000000df7d24058375a3c2-- From nobody Wed Mar 6 15:50:35 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D420F12F1A2 for ; Wed, 6 Mar 2019 15:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qFrpPiYjHsV2 for ; Wed, 6 Mar 2019 15:50:25 -0800 (PST) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D4F1310F7 for ; Wed, 6 Mar 2019 15:50:22 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id x4so11860693ion.2 for ; Wed, 06 Mar 2019 15:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wjijptUNQRHbRVaymO9/O1vDJCNMENw/vW3tx5RG9MM=; b=GbmD1YeFKTb1vktF+Zv6JL4jL4VCh6fzcqNV9zo4rOB3lF/CcVy84rT+F69ISLnsXp SFY1tIrz+Z31uGm4Sf8m2Vz0m8tXVy0BXIQ67aE0pVv0BzH/lKkt0foRQkf7lT9diiYO gGbhERdrSLw3f3TMYM0jRAVmEn+1nkGsXMlwHp9i0J3Gd72weiasoi6JrhwEvVDR1Ots owlg0++76aJIVcjHQ/Or83d13N5oXuctE6NnjjuV5dKYkD2W6y/rFwDnTno5LkjwyQ6a mwKS5gt4UBpS4VZS43WEMcbduSWoydptydm19HdNDoLiGc88HkzepTnEUY012sqgPzsI Mq3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wjijptUNQRHbRVaymO9/O1vDJCNMENw/vW3tx5RG9MM=; b=V/p6NQRQheINRn18xpvHVdiGGIamiRIUnEc6njTZdDJr+Y+yZlJJqYVKqkk45E7wbj WHBppHWSeABrYp34xefSYus9fZMZlMRzhB9OQh0+jnbbdxvjQVRvBl968eqI00J4vWva PJiUBZnO0t9c0SC9yoQK6BIZZJgVCno00knKaIsLkxwTo9pBFj2PBhS77/JNu6OxeCRl FA9mUWSwth7KaJ+jTYyKeeHjTt+apY4c63ufKkOvbK9f/tYSIP/EJyvaum9LSveqUVwY 28+aNRt21MGDCGZtm6yJVpnfQCEeUcG6Ds5cfYsdM7BlcAstEG+ZpqweHE7lTI79zmKn wV1g== X-Gm-Message-State: APjAAAV3B2pwVTZI81fPeIEe3MLO/q7nkguYNZcGwW3x9QWR53z20uZv i3WxEvz7/i3XflgZGTsG3R1txTWCuQR5HMJhRheaoQ== X-Google-Smtp-Source: APXvYqwvLUTzjw6tiwUCjlHVHgjjG8vTy9bMF54bm00CSvsbUf4sb4YZmOI94hu5h7O0xhrbBAtWqvyNiqMBdiNOjFk= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr4385745ioh.95.1551916221269; Wed, 06 Mar 2019 15:50:21 -0800 (PST) MIME-Version: 1.0 References: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> <65AC0812-0A88-42AD-8645-AC3318E60F8B@nostrum.com> In-Reply-To: <65AC0812-0A88-42AD-8645-AC3318E60F8B@nostrum.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:50:08 -0800 Message-ID: To: Ben Campbell Cc: The IESG , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000017610b058375a7c3" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:50:28 -0000 --00000000000017610b058375a7c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2019 at 3:44 PM Ben Campbell wrote: > > > On Mar 6, 2019, at 5:37 PM, Justin Uberti wrote: > > > > On Mon, Mar 4, 2019 at 7:59 PM Ben Campbell wrote: > >> Ben Campbell has entered the following ballot position for >> draft-ietf-rtcweb-ip-handling-11: Yes >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I agree with Mirja that this reads more like a BCP. Was BCP status >> considered by the WG? >> > > I don't think it was explicitly discussed. We have been treating this > document similarly to the other recommendation documents for WebRTC, e.g. > the recommended audio codecs in https://tools.ietf.org/html/rfc7874; > these docs are all Standards Track. > > > It=E2=80=99s not a show stopper from my perspective, especially if we are= talking > about recommendations to W3C. > > >> (nit) =C2=A73: Please expand "RTMFP" on first mention. >> >> (nit) =C2=A75.2: "Mode 1 MUST only be used when user consent has been pr= ovided" >> Please consider "... MUST NOT be used unless user consent has been >> provided." >> >> =C2=A711.2: It seems like the references for STUN and TURN should be nor= mative. >> > > It wasn't clear to me that STUN and TURN meet the bar of "required to > implement this RFC". Open to other points of view here though. > > > =C2=A77 contains says applications SHOULD deploy a TURN server; that=E2= =80=99s enough > to make TURN normative. It=E2=80=99s less clear for STUN, but I think it = passes the > =E2=80=9Cnecessary to fully implement or _understand_=E2=80=9D bar. > Fair enough. --00000000000017610b058375a7c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 3:44 PM Ben Ca= mpbell <ben@nostrum.com> wrote= :


On = Mar 6, 2019, at 5:37 PM, Justin Uberti <juberti@google.com> wrote:



On Mon, Mar 4, 2019 at 7:59 PM Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the fo= llowing ballot position for
draft-ietf-rtcweb-ip-handling-11: Yes
When responding, please keep the subject line intact and reply to all
e= mail addresses included in the To and CC lines. (Feel free to cut this
i= ntroductory paragraph, however.)


Please refer to=C2=A0https://www.ietf.org/iesg/statement/discuss-criteria.htm= l
for more information about IESG DISCUSS and COMMENT positions.
=

The document, along with other ballot positions, can be found here:=
https://datatracker.ietf.org/doc/= draft-ietf-rtcweb-ip-handling/



-------------------------= ---------------------------------------------
COMMENT:
--------------= --------------------------------------------------------

I agree wit= h Mirja that this reads more like a BCP. Was BCP status considered by the W= G?

I don't think it was explicitly = discussed. We have been treating this document similarly to the other recom= mendation documents for WebRTC, e.g. the recommended audio codecs in=C2=A0https://tools= .ietf.org/html/rfc7874; these docs are all Standards Track.
=

It=E2=80=99s not a show stopper from= my perspective, especially if we are talking about recommendations to W3C.=


(nit) =C2= =A73: Please expand "RTMFP" on first mention.

(nit) =C2=A7= 5.2: "Mode 1 MUST only be used when user consent has been provided&quo= t;
Please consider "... MUST NOT be used unless user consent has be= en provided."

=C2=A711.2: It seems like the references for STUN= and TURN should be normative.

It wasn&= #39;t clear to me that STUN and TURN meet the bar of "required to impl= ement this RFC". Open to other points of view here though.
=

=C2=A77 contains says applications S= HOULD deploy a TURN server; that=E2=80=99s enough to make TURN normative. I= t=E2=80=99s less clear for STUN, but I think it passes the =E2=80=9Cnecessa= ry to fully implement or _understand_=E2=80=9D bar.

Fair enough.
=C2=A0
--00000000000017610b058375a7c3-- From nobody Wed Mar 6 15:52:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F92A12F1A2 for ; Wed, 6 Mar 2019 15:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 NdNiH3p4qJOo for ; Wed, 6 Mar 2019 15:52:37 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20D12008A for ; Wed, 6 Mar 2019 15:52:36 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id x9so11828883iog.12 for ; Wed, 06 Mar 2019 15:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9EczDv/FiIywRx5CXgsaao7rZ1cN12zHu/X9/gNh9nQ=; b=OTzL+TlGD3SFlD200LZxkik2xhWmriCzd6e2u2nVNrTZlVkukmu4S2Jakl2k5gZhJK tMfrLneaCRf2I/q9a/WFzpZoaHQE20TwUQlXKNtgSIObpboLccaCEevK30BV1ZsaI3Jq AY+GkZyEmAjFT919lowRbS4lOlS+rL6S2vLP8t/kaWuYOVenHbYwm14Uif2vOSd8+09l 3xxff1kgUq1/Gyyo1kVPiVCOlt24vrsveBKrqkgN4nZ3qRBJgjE1Ij5MFP1BIkeiIZwf qRzEnZnoa/FYyuMvkpmbjNkSA3qLVjN94bSMJoO3uiUrD/vxy74ZbDWpI0jfBscZaLdR 1YdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9EczDv/FiIywRx5CXgsaao7rZ1cN12zHu/X9/gNh9nQ=; b=THAasudQYjMfiIscufgEX3x3uu5nDFWLKc2d2MSlBtBZ2VDY8wzyb7lWSE/jKKxGnX wYR4dnYC9IhldQVP+CIjfkyllRW3CFAk4Rg32Qh/N9AGI8M4f6ZKoqJcL0sUTIlLD5ne rJ5VTAy6bJkqkttqS1xNn7wO/3uTmllarwA92u0hvZzaEHPTr3IqtRcVc6Unx4RlSNpe zrwLl92ug3wT27J5Smrf/rW20nU2HB2RRSoUslqc9N+BWwZR+ehiwaagsW6IlDvgYID8 mnePL8FKSTH1Ai96G7wIwx1rGlAovznSMYFc6xIXVTOsJiXVUvjz3hSLq14XmRfYMICF n5Ww== X-Gm-Message-State: APjAAAVuUDSdG6OlEUmjO3tNXvHDVPG4kB2bZ0bpU7MGqpXm3yHlHZvk VUb3aaRhpFbRUGv+Typ0z9uccUdSWLmE9BmIi3LaI0JI X-Google-Smtp-Source: APXvYqxmkCLIl3Vmn9wojaREAjIjGmaEim6MCNwejHulpAh4ySqtjW9nZLgzL5DQ3xoqiHiJJOaNHtlftSTVMAmpvp8= X-Received: by 2002:a5e:df01:: with SMTP id f1mr4724256ioq.101.1551916355863; Wed, 06 Mar 2019 15:52:35 -0800 (PST) MIME-Version: 1.0 References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> <3a0ca676-e43a-d45c-b82c-22287a764a79@gmail.com> In-Reply-To: <3a0ca676-e43a-d45c-b82c-22287a764a79@gmail.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:52:24 -0800 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000001d1c1b058375afe0" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:52:39 -0000 --0000000000001d1c1b058375afe0 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 6, 2019 at 12:45 AM Lennart Grahl wrote: > On 06.03.19 04:34, Justin Uberti wrote: > > We'll always mask any local addresses with mDNS, since we don't know if > > they're public or not. We will also provide a srflx candidate with the > > actual address should STUN tell us that information. > > IIRC that would mean a publicly reachable local IP address would still > be masked with mDNS first. Once the STUN server's answer arrives, a > srflx candidate with the exposed IP address must be handed out. Is that > assumption correct? > Exactly correct. --0000000000001d1c1b058375afe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 12:45 AM Lenna= rt Grahl <lennart.grahl@gmail= .com> wrote:
On 06.03.19 04:34, Justin Uberti wrote:
> We'll always mask any local addresses with mDNS, since we don'= t know if
> they're public or not. We will also provide a srflx candidate with= the
> actual address should STUN tell us that information.

IIRC that would mean a publicly reachable local IP address would still
be masked with mDNS first. Once the STUN server's answer arrives, a
srflx candidate with the exposed IP address must be handed out. Is that
assumption correct?

Exactly correct.=C2= =A0
--0000000000001d1c1b058375afe0-- From nobody Wed Mar 6 15:55:48 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF11274D0 for ; Wed, 6 Mar 2019 15:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 P65xCpNOwHPI for ; Wed, 6 Mar 2019 15:55:43 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA80612008A for ; Wed, 6 Mar 2019 15:55:43 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id p18so11839255ioh.5 for ; Wed, 06 Mar 2019 15:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lkIOujBZxkP8ZXrELYw16z/ea0Aj4lIeTW6VlXVKsPc=; b=PudHGAV92G/PIvgLxe/lY6paKNHFgHyUt1unUB54PiP/S7Wx9rdlivkSID36N3xlFx 6wB1CHMqPM4iHRiOddg7qzDNsCZm2SxoyjrPLqb7uGObOP387GsQtD5qMH84wXE3Lmfm sYzOf+CA0gIUv942NBL7tw1ITRFRbMpCfzF+2UjXXDop4zs991kK9jAcVCp3gS/TGa5+ 7fXRcxyRGdgeg8akbh+FQqShVEKWpYeQHjbjgRoyjWtGxrDwjBLtsRPeWXpS10ZVTUPW cIa1WPJGLzFInBVvGqzCHvfni98z9WawxVZx5iu72cs8qi79VWIEU6COYwc0RGgviehv 4FiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lkIOujBZxkP8ZXrELYw16z/ea0Aj4lIeTW6VlXVKsPc=; b=E5qCXx/3bYBeGQA0XfDU8jXK4eihDfh0zVPVshrFzCawjtigSsPpAZDkTSFPnTFRwS Cd8OWjfGJgwNbmSvPaTq0MJuA6LSm7MfP3owCJx72L+74XAf/sd/ZWlyAhFouJq+4TKG AoQLOmSzgimFw2tECSBFEnmFeZONKt+U1OlVp3ChSk9y1eCzmTzi/tfhizczVz1xYpm5 6AqCjyc+N25jBRksZdJLz207YyFqkX2J3urTQZy0HgNLjF7qwGVRMTCIZd6c9HYeQ3HE lCEF52kKVs7NsysdD26xLj8kFcAjTDjsDGUFY18ektDSDJPdGJyiGASJrns7eOgKdvS8 xvyQ== X-Gm-Message-State: APjAAAVxN+EgM1MHBAt8DPwJwJXgkXSKD05G/w6nbPYD9Tyb4XTeucUB mQLJ2DNSEOrqdx3DoTEzy7UOcF7sjkRiYGb/1FcvEg== X-Google-Smtp-Source: APXvYqwr+4ZEK2+gaW6br50nKzskF15eSSPuNndY6W2MIQhT8n5S2MNcBpOEWGawZAc7UdP6QncA5234XIJZBcoPz1o= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr4396419ioh.95.1551916542730; Wed, 06 Mar 2019 15:55:42 -0800 (PST) MIME-Version: 1.0 References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Wed, 6 Mar 2019 15:55:31 -0800 Message-ID: To: westhawk Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000407c0f058375ba7f" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:55:46 -0000 --000000000000407c0f058375ba7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2019 at 2:11 AM westhawk wrote: > > > On 6 Mar 2019, at 03:34, Justin Uberti wrote: > > We'll always mask any local addresses with mDNS, since we don't know if > they're public or not. We will also provide a srflx candidate with the > actual address should STUN tell us that information. > > > So the =E2=80=98always=E2=80=99 should be conditional on how the addresse= s are =E2=80=98found=E2=80=99? > Perhaps a definition of Local IP addresses would help: > =E2=80=9CLocal IP addresses means addresses discovered by interrogating t= he > operating system for > a list of available interfaces and their associated IP addresses=E2=80=9D > > Plus a clarification that =E2=80=9Cthese rules do not apply to addresses = that are > subsequently found via > STUN or ICE - note that this may cause an address to be listed twice - > once as a host candidate with a masked mdns > and a second time with it=E2=80=99s IP address as a reflex candidate=E2= =80=9D > Perhaps this could be simplified by simply referring to 'host' IP addresses, where 'host' has the same meaning (i.e. local interface) as in ICE. > > (I=E2=80=99ve a feeling there is section of the ICE RFC that talks about > eliminating reflex candidates that duplicate host candidates > but can=E2=80=99t find it) > There is, but I content it does not apply here, since these srflx candidates will contain a different (non-hostname) address. > > Tim. > > > Agree though we should be consistent on terminology, will look into what > the best option is there. > > On Tue, Mar 5, 2019 at 1:40 PM westhawk wrote: > >> On first reading it seems like there might be a conflation of private IP >> addresses and local IP addresses. >> the [ip-handling] document uses the term 'Private local IP addresses=E2= =80=99 >> where as this document >> uses "private IP addresses=E2=80=9D in the introduction but then uses "T= he local >> IPv4 address=E2=80=9D without any >> explanation (I can find) of the difference. >> >> Surely this would mean that a standalone device (say a public kiosk) >> assigned a >> single routable public IP would mask that address with mdns. >> >> Tim. >> >> >> >> >> >> > On 5 Mar 2019, at 20:22, Ted Hardie wrote: >> > >> > Howdy, >> > >> > draft-uberti-ip-handling-ex-mdns is a very short draft describing two >> new modes related to draft-ietf-rtcweb-ip-handling using bits of >> draft-ietf-rtcweb-mdns-ice-candidates. >> > >> > The chairs would like to ask for a couple of reviews; given that it is >> four pages long, we are hopeful that it will not take much time. >> > >> > Please send your review to the list, >> > >> > thanks, >> > >> > Ted >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --000000000000407c0f058375ba7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 2:11 AM westha= wk <thp@westhawk.co.uk> wro= te:


On 6 Mar 2019, at 03:34, Justin Uberti <juberti@google.com> wrote:

We'll always mask any local addresses with mDNS, since we don'= ;t know if they're public or not. We will also provide a srflx candidat= e with the actual address should STUN tell us that information.
=

So the =E2=80=98always=E2=80=99 should be = conditional on how the addresses are =E2=80=98found=E2=80=99?
Per= haps a definition of Local IP addresses would help:
=E2=80=9CLoca= l IP addresses means addresses discovered by interrogating the operating sy= stem for
a list of available interfaces and their associated IP a= ddresses=E2=80=9D=C2=A0=C2=A0

=
(I=E2=80=99ve a feeling there is section of the ICE RFC that tal= ks about eliminating reflex candidates that duplicate host candidates=C2=A0=
but can=E2=80=99t find it)
There is, but I content it=C2=A0does not apply here, since the= se srflx candidates will contain a different (non-hostname) address.

Tim. =C2=A0


Agree though we = should be consistent on terminology, will look into what the best option is= there.

On Tue, Mar 5, 2019 at 1:40 PM westhawk <thp@westhawk.co.uk> wrote:
=
On first reading it= seems like there might be a conflation of private IP addresses and local I= P addresses.
the [ip-handling] document uses the term 'Private local IP addresses=E2= =80=99 where as this document
uses "private IP addresses=E2=80=9D in the introduction but then uses = "The local IPv4 address=E2=80=9D without any
explanation (I can find) of the difference.

Surely this would mean that a standalone device (say a public kiosk) assign= ed a
single routable public IP would mask that address with mdns.

Tim.





> On 5 Mar 2019, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Howdy,
>
> draft-uberti-ip-handling-ex-mdns is a very short draft describing two = new modes=C2=A0 related to draft-ietf-rtcweb-ip-handling using bits of draf= t-ietf-rtcweb-mdns-ice-candidates.
>
> The chairs would like to ask for a couple of reviews; given that it is= four pages long, we are hopeful that it will not take much time.
>
> Please send your review to the list,
>
> thanks,
>
> Ted
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--000000000000407c0f058375ba7f-- From nobody Wed Mar 6 15:58:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AE71274D0 for ; Wed, 6 Mar 2019 15:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8lcN_9HRX-8Y for ; Wed, 6 Mar 2019 15:57:58 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C661310F7 for ; Wed, 6 Mar 2019 15:57:56 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id x3so11852839ior.6 for ; Wed, 06 Mar 2019 15:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ojoD2laanefPYNo91m1ZSxGvJvETtgtQvp/x1iVjMj0=; b=gFXFna4XVL1nri0xfSO+h2QZA6C4QDDNsLEKjTeumhXLaWalHjrFq642r8B1TTfgJj 7T0yL2oSGQXo506m2/MG15Ff24Te6FqlTXwHAxwE/nvHjTgBQZMLur5ROowTocVAl3fR cNUugS3GS4IhbMfIez742A/Mwf1bWxs40yC3PqmLOg9FPmL/KLX+8xZYuTPKWBhiGE5b H3/zTX77kwisNjLFw5ApIOi5F9L9PWeSVs6zm+UWVo5Vh2KSzItBEp8kPAXxb+x4ka0R BrPmAvgABb+Th7h6mCwpBA8mt/iTKagnu+E2lSTlo/J/zuuhsoRSeTlLbL8GgoocAw3D ijNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ojoD2laanefPYNo91m1ZSxGvJvETtgtQvp/x1iVjMj0=; b=fOdBLLdyuFBPtItOy5JzYcCsvErbveBdariZUa0p3HbAueHcWS4367FIG4NnbH8MMC KkpqrwiVnXWjRbVXgAXYEyHXxx6raF5wh4dlgp22en63HZWvZlrcZN9Zg1ArH+ilDeYo XReP66s8tpq7fmjpE9yeNeywM9Cb3fYV6wFKecLmkJ/8usNxHe9AuUwpGPk6x4hPv3B3 dY1OkvHPU+HcXBjM4rm2OJHazuwjj7qnX+1c5+j+j25x4UcFAz9WvodCceDm8JpHN5Fx +xwQcFcuscpodpho0Bo1dNzZ08oP3q2Q3yv/gU20irvxGjKFBq5uHmtGAA6oWNVpc8u7 ilhA== X-Gm-Message-State: APjAAAVlY4g9L+DCTMp8SZH4LNHhZxYHp/cBlApJ/sClgDqpDvnCS1mI SwyTBfo7dZxwhi3Z3fczsc6cD8fhvqnxLUYfbGT0sA== X-Google-Smtp-Source: APXvYqz/JDT0oe97ZynvHWl4rnsEs6n4p/K4FcqDkZARiqBUC/76NM1jvUKxvST6zJCbY9rKy3coXwX2IKuTyu1jLtw= X-Received: by 2002:a5e:df01:: with SMTP id f1mr4735033ioq.101.1551916676001; Wed, 06 Mar 2019 15:57:56 -0800 (PST) MIME-Version: 1.0 References: <155042612497.4083.2465692313767522646@ietfa.amsl.com> <7214C146-4B65-429E-AA90-4ED9E2654472@strayalpha.com> In-Reply-To: <7214C146-4B65-429E-AA90-4ED9E2654472@strayalpha.com> From: Justin Uberti Date: Wed, 6 Mar 2019 15:57:44 -0800 Message-ID: To: Joe Touch Cc: tsv-art@ietf.org, RTCWeb IETF , IETF discussion list , draft-ietf-rtcweb-ip-handling.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000321426058375c2ca" Archived-At: Subject: Re: [rtcweb] [Tsv-art] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 23:58:00 -0000 --000000000000321426058375c2ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 5:33 PM Joe Touch wrote: > You could just add =E2=80=9CUnix=E2=80=9D or =E2=80=9CUnix-like=E2=80=9D = to before =E2=80=9Cconnect=E2=80=9D, or refer to > these calls as =E2=80=9Cbind()=E2=80=9D and =E2=80=9Cconnect()=E2=80=9D. > > It is important that these are the semantics of Unix-like sockets; other > APIs may not have a corresponding mechanism. Further, the UDP source > address might change later (i.e., in TCP the =E2=80=9Cconnect=E2=80=9D al= ways forces a > static source IP address selected at the initiation of the TCP connection= ; > in UDP, there=E2=80=99s no need for this to happen only once at the time = the > =E2=80=9Cconnect()=E2=80=9D is issued. > Sounds good. --000000000000321426058375c2ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 5:33 PM Joe T= ouch <touch@strayalpha.com&g= t; wrote:
You could just add =E2=80=9CUnix=E2=80= =9D or =E2=80=9CUnix-like=E2=80=9D to before =E2=80=9Cconnect=E2=80=9D, or = refer to these calls as =E2=80=9Cbind()=E2=80=9D and =E2=80=9Cconnect()=E2= =80=9D.

It is important that these are the semantics of = Unix-like sockets; other APIs may not have a corresponding mechanism. Furth= er, the UDP source address might change later (i.e., in TCP the =E2=80=9Cco= nnect=E2=80=9D always forces a static source IP address selected at the ini= tiation of the TCP connection; in UDP, there=E2=80=99s no need for this to = happen only once at the time the =E2=80=9Cconnect()=E2=80=9D is issued.

Sounds good.=C2=A0
--000000000000321426058375c2ca-- From nobody Wed Mar 6 16:59:45 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD91312A9 for ; Wed, 6 Mar 2019 16:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 pNj5X3Vkg-9j for ; Wed, 6 Mar 2019 16:59:41 -0800 (PST) Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC9D131342 for ; Wed, 6 Mar 2019 16:59:38 -0800 (PST) Received: by mail-yw1-xc41.google.com with SMTP id n12so11886755ywn.13 for ; Wed, 06 Mar 2019 16:59:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/l76gm3YQmWkGxKrB4BNza8q8+MmMreMrdaiux8zF2M=; b=fX6/8DGqNG3g7FfbgqOgVrX4p9+9hkbnY5XD+R1PtxIcd/9AkJkG00dlNwFJ7gk6wL Xv8nQCTCYU5cSe4TieHgWZsEY/rdgm9DARnl9dt9beXkWdgrI2mpb2YSO0BrdPuL2/iO hNcpHwBHRZQMKRJbemml93HgfNMc87NV7fJuk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/l76gm3YQmWkGxKrB4BNza8q8+MmMreMrdaiux8zF2M=; b=K8ht4QEh6IsywAROdFPoMKyuhMxFVHVdCBTawa3E5Cx9+kaQuPBPjQ+JO8SP2YSaN6 AiDQ5lYeH/bDbZRvouAe340G2+eaZRq03yDHgNSEkPKvmBag38E+N9w6uGoWm0fH1GX1 ETmbS4uKBXPzOr0siIuT3cAyoZOjiyi+UzV963sUwvP6flSyDIzu1rNRVLl7xshPoLm4 mtWeLE1iAVqrlHrPwf1fr/k/SWroYZc2uCLOEPOPCrn5+cmZRvWfV0BLBKu6UdJ1HLzJ ClhJTF0tXQ0ocuGQeRRbrxtVUDG8R/oOfiONwar0QO0WS36G/l2XsT30Bqd1l4/jzHb8 1Z2w== X-Gm-Message-State: APjAAAUJ+B8K5FyRJPoBKC0kIVzdHnUjrDej5CTbsCD0Sm7Mz3M32cg2 W5DjRdtp2hSYAkkQKGpLSOUygA== X-Google-Smtp-Source: APXvYqwFP9xE5P2HFIFvpIGOt4mk8D+RV6uicu4X3M4hAapeVPXbHoF+7+d7Vj0NUkNvXrxhlfhD9A== X-Received: by 2002:a25:a083:: with SMTP id y3mr9402566ybh.40.1551920378050; Wed, 06 Mar 2019 16:59:38 -0800 (PST) Received: from [5.5.33.87] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id t126sm1091857ywa.83.2019.03.06.16.59.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 16:59:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <155173579996.5114.17917347453427376685.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 09:59:33 +0900 Cc: The IESG , draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BB471FF-BABC-430D-86B3-8E39BC79147C@sn3rd.com> References: <155173579996.5114.17917347453427376685.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Alissa Cooper's Yes on draft-ietf-rtcweb-security-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 00:59:44 -0000 > On Mar 5, 2019, at 06:43, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-rtcweb-security-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > PS seems like the appropriate status for this document given its role = in the > WebRTC document suite. >=20 > =3D Section 4.1.4 =3D >=20 > "The attacker forges the response apparently > http://calling-service.example.com/ to inject JS to initiate a call to ^ inserted =E2=80=9Cfrom" > himself." --> This doesn't read correctly. >=20 > =3D Section 4.2.4 =3D >=20 > It seems like this section should reference = draft-ietf-rtcweb-ip-handling. Can add:=20 See [I-D.ietf-rtcweb-ip-handling] for additional information. See PR: https://github.com/rtcweb-wg/security/pull/14 spt From nobody Wed Mar 6 17:03:22 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD081312AB for ; Wed, 6 Mar 2019 17:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 7QS9PYxWVy-t for ; Wed, 6 Mar 2019 17:03:18 -0800 (PST) Received: from mail-yw1-xc44.google.com (mail-yw1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66D413116E for ; Wed, 6 Mar 2019 17:03:18 -0800 (PST) Received: by mail-yw1-xc44.google.com with SMTP id k14so11911040ywe.4 for ; Wed, 06 Mar 2019 17:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JGGnQDTjiev+dgjS1Fayc/sQpLZbvsT+v3+C7ePO6g4=; b=ks90NAfJVqhuE1iehCDLZQhXdAiwyPdB74l2Eqi1Iw+H3xNuATRYkzTvxSO4cKU28I BmWEWsFhhG5g6HFrX1QIKqKzc9R1jZfjRrLYVo8Eo2shcRtZGzii5hzshiFj77qZQaB0 JOkCuFmfeBZl28WOuT4kP7aTH4PUk+cIgGaLo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JGGnQDTjiev+dgjS1Fayc/sQpLZbvsT+v3+C7ePO6g4=; b=F3XpWAPOxASP9mE8g2DC3Z7IE3FWG3/eHFT67xxSf+TpXZIL5W5a1Klvu+5mft6Z+c KYcdL8ojJKEunHLrZACxIPBx9kAwNYsgWNoB61P424Dx7ul38ESQzs/Wh8RqBdjeHatX JtDKWht3Wkpo+uKxCBVvgJDuyWanWDg6THb2zmFsN4IyR4ILm7ddybxd0QVzfQBAOJLK 9Tqfc8tpmY6prAJrS4B0+AEEU4Ojvhoo8pjCNfW6K/3McEf1QyRClsSwzfh5RA6SKJcS zha/2sXcPIcBD/rNCfLcDaQ13cpUYRsHrnITlxij2yTHg8qxlkW6cnyCE8iQAMhE7Z9j XPzg== X-Gm-Message-State: APjAAAUDgB09dVF0bNIj5fwIhl6XCz8tFXh4dpyZxnsisNKRNQDlAPWt n3N+xj9cHMnX6rQNrC5BBi4iUAgGNUR9eQ== X-Google-Smtp-Source: APXvYqxmLnkam/irYTNNNEQQ+UV5PJ+Vq5Qua/NPw22J7Im3cg3pSyputxygNuKkz1BvftK62zclsw== X-Received: by 2002:a81:9383:: with SMTP id k125mr7808923ywg.323.1551920597317; Wed, 06 Mar 2019 17:03:17 -0800 (PST) Received: from [5.5.33.87] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id g82sm1194228ywg.60.2019.03.06.17.03.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 17:03:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <155175814957.5184.10462812445955598264.idtracker@ietfa.amsl.com> Date: Thu, 7 Mar 2019 10:03:13 +0900 Cc: The IESG , draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9BA0FDE6-B690-4EF1-8530-4DBAC514B32F@sn3rd.com> References: <155175814957.5184.10462812445955598264.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 01:03:20 -0000 > On Mar 5, 2019, at 12:55, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-security-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I disagree that this should be informative. It does have sections that = have > informational content, but it also has sections that serve as security > considerations for WebRTC as a whole. >=20 > (nit) =C2=A74.2.1: Please expand ICE on first mention. https://github.com/rtcweb-wg/security/pull/15 From nobody Wed Mar 6 17:27:39 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2F91312BB; Wed, 6 Mar 2019 17:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 8RiSXK3LCNLH; Wed, 6 Mar 2019 17:27:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C878B1312C2; Wed, 6 Mar 2019 17:27:36 -0800 (PST) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x271RXkv038440 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 19:27:35 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551922056; bh=fzYT0VYkTSRRr5sQo9+UJspYoixoT+bgtgV2HcuW22U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=tWIS8U1ZqJXGuoDpfMD2JnKEn8oNox2IYbBFrhy2St4tJ8mUbvFvyb8Rmbo7CakeK yVeU/9ZKe986jRiN91ojMycGUE1fZuf9HvcMnAo7kERRfMLyJqOsPrGApuQ4VaVl52 1a3c5ayfIF3AtHwhTW3/1GZDelUW4IrqIYNJ/zyA= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A7F16BE8-EC74-4618-B00C-17C227F053BD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 19:27:26 -0600 In-Reply-To: <9BA0FDE6-B690-4EF1-8530-4DBAC514B32F@sn3rd.com> Cc: The IESG , draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org To: Sean Turner References: <155175814957.5184.10462812445955598264.idtracker@ietfa.amsl.com> <9BA0FDE6-B690-4EF1-8530-4DBAC514B32F@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 01:27:38 -0000 --Apple-Mail=_A7F16BE8-EC74-4618-B00C-17C227F053BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks! Ben. > On Mar 6, 2019, at 7:03 PM, Sean Turner wrote: >=20 >=20 >=20 >> On Mar 5, 2019, at 12:55, Ben Campbell wrote: >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-rtcweb-security-11: Yes >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I disagree that this should be informative. It does have sections = that have >> informational content, but it also has sections that serve as = security >> considerations for WebRTC as a whole. >>=20 >> (nit) =C2=A74.2.1: Please expand ICE on first mention. >=20 > https://github.com/rtcweb-wg/security/pull/15 >=20 --Apple-Mail=_A7F16BE8-EC74-4618-B00C-17C227F053BD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlyAc34ACgkQgFZKbJXz 1A3gKxAAmjEeQa+BN7FhwvEB0hPOT7VMdH/Coa35ldroEClqaXpEGy5XuXx8CkSH 9hxMX9vd5qbDaf58FEt7p/tDqCYluh7deyLNP0q3f8UVIXFNT8iHyhepelXqnQeK TQMG/C5kgIyooK3FtM1btFGZLkdoBHLdoSPh3W9DIpRbURWKP1l/Zm0MnQzVVPEG HKNP9gbiB5d3LsPCySOnsRZ6/8CCEGIBT8xPGWz7A7GrUsHY9YmdDQo3j7qg4nPO BD837SKKfYdMEQ3JqVv92nbjMEAe4tAV6TV1+nSeIFIKkH75lk9UDfD9/KBSjJ+g PsrYNspfE7CeM0wPvIxp5Izsvg+L/z/UtLxRz2C6yXpczwcZfIoE2sE8D0PYN2da Q1rXEHTCO6Hf6Zc6kt//pPEpoR2u0UroEdTU7wxOPU1RGQg29tQmxvNXSAVLXJ9I w05VbTlf4Q/SJSmUDf3YgVoD3ouDrR6qPtuHXtIt/czULgCC5o54+EXXZILZUx4Q l1i4cL+bWEBrciqUZTz/gDDCNWRA8lUqhuqJG1BN/ZP+ZkLN5Fuhsw5pcB9HNgW5 x0TfazpY871R0XKR8YH9c26ujbFo10AG6VPgf/Vt+6Ux2fKItcRwOe7g7YRm+kkc oS2/K77S7GypimrcAcuORNaDhfHJXSe/O3gcaZHWkr2LpNtA+Yo= =fRSA -----END PGP SIGNATURE----- --Apple-Mail=_A7F16BE8-EC74-4618-B00C-17C227F053BD-- From nobody Wed Mar 6 17:31:30 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137A126F72 for ; Wed, 6 Mar 2019 17:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 bvmQx6uChcPH for ; Wed, 6 Mar 2019 17:31:28 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B000131149 for ; Wed, 6 Mar 2019 17:31:26 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id r188so11943652ywb.12 for ; Wed, 06 Mar 2019 17:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z27UFaHAsizYnOqJsnUSAHauo6FpHvYIvVNa8y1MNiw=; b=fifeKf6vyBHZMshe2tCU3XIlU4DA5EvGgsq4MwusJGWH9XRuIGCYXU6JLmVdMqiyZ2 zh6fk1Jvu6RkH/zbNPXtjWrer0byBl8FBdawuLJBAiKWD3NNw/ZWhxGTr509gQCvYXJ7 tUzEMKo8DTxb4ABMGRe2Y1cU9nQ+PS1YOPNhQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z27UFaHAsizYnOqJsnUSAHauo6FpHvYIvVNa8y1MNiw=; b=aLIzrHNEQaAEPLUiyj1Zqi/ia83osSasAXOTFEtuQtFQrbjD6jf01Etm9RFgujekfP eo5Ld/sjvas3F0Zcl1QTnAzKCfyliNFI2b1mCytYAinkM1A1/HmnUDFgoQvo5/DYYWjZ MNql2bflhW/8UjWEZIl1+/3V84sTKas4EUxvdYTG999DZsc+iJCPWXSznhjpZPL5VUEe RttSoDAz5c8N7XQnvQ9plPIL3hFdedVS4zqdpQtCkAbt8TEfxKOhTbGwGGRXdOjdpAF5 oAn6J85UwEIZ8m4/axQkhZmb79HA4RO3myhEwnRxHYfslLrij4/laKTpSMchPxUaZ0e3 uaXQ== X-Gm-Message-State: APjAAAUCEvy3cSZ61pKfPl5ilN4oPEESDBgJkEljPyumiNZcCuYbGjlC SwsvFy6pw8lK++jbZ+vQcZIqmg== X-Google-Smtp-Source: APXvYqySeIsKg9X+tRfJejz9uqgo4SjhfMaUCOKMsafeM2QnG98tGFge3J4wTqcgEN2F5wLXJb5BNg== X-Received: by 2002:a25:61c8:: with SMTP id v191mr9202931ybb.489.1551922285454; Wed, 06 Mar 2019 17:31:25 -0800 (PST) Received: from [5.5.33.87] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id b83sm1087806ywb.48.2019.03.06.17.31.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 17:31:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <2c600fc6-ca2c-2cd5-f677-6edcd0a6f3b7@nostrum.com> Date: Thu, 7 Mar 2019 10:31:22 +0900 Cc: The IESG , rtcweb-chairs@ietf.org, RTCWeb IETF , draft-ietf-rtcweb-security-arch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> <2c600fc6-ca2c-2cd5-f677-6edcd0a6f3b7@nostrum.com> To: Adam Roach , Alexey Melnikov X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Alexey Melnikov's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 01:31:29 -0000 > On Mar 7, 2019, at 04:37, Adam Roach wrote: >=20 > On 3/5/19 3:52 AM, Alexey Melnikov wrote: >> My apologies for filing a procedural DISCUSS on this, but I am = looking at: >>=20 >> 7.5. Determining the IdP URI >>=20 >> 3. The path, starting with "/.well-known/idp-proxy/" and appended >> with the IdP protocol. Note that the separator characters '/' >> (%2F) and '\' (%5C) MUST NOT be permitted in the protocol = field, >> lest an attacker be able to direct requests outside of the >> controlled "/.well-known/" prefix. Query and fragment values = MAY >> be used by including '?' or '#' characters. >>=20 >> "idp-proxy" is not registered in the IANA's >> = >> registry and this document doesn't register it either. If I missed = where this >> is registered, please point me to the right document. If I haven't, = please >> register it in this document. >>=20 >=20 > Good catch! Thanks. >=20 > /a I submitted a PR: https://github.com/rtcweb-wg/security-arch/pull/86/files And fired off a message to the expert list. spt From nobody Wed Mar 6 18:18:01 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DAE13110B; Wed, 6 Mar 2019 18:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 oUH15q5rxP8V; Wed, 6 Mar 2019 18:17:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6B013108C; Wed, 6 Mar 2019 18:17:51 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x272HmjE046656 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 20:17:50 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551925071; bh=hedKl7sGDWp8UG7ga166RV2pHKM0d8SUhfqHuKjrjWw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GU6l+hSarmettxiaAZZFZ8Wq3aMrm9GhFVSBb43LyzgfZM576A2M9vRD8tXCkblhi KfezUvWWktvMQyWBVr/c27L3z/WeUuKInEjMeJBcDAzV46OUn6cKBp1P2DeLPPI2k/ MS9QprOZzIs/Lsr4fJI1u1U28p5AbYQLtqDfVXXw= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Justin Uberti , Ben Campbell Cc: draft-ietf-rtcweb-ip-handling@ietf.org, RTCWeb IETF , The IESG , rtcweb-chairs@ietf.org References: <155175838513.5229.12205097799963525432.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <1156ebe7-8c10-be7e-d668-694cd66874f2@nostrum.com> Date: Wed, 6 Mar 2019 20:17:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7951EF22D99F95DB842B61CA" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 02:17:55 -0000 This is a multi-part message in MIME format. --------------7951EF22D99F95DB842B61CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/6/19 5:37 PM, Justin Uberti wrote: > > > I agree with Mirja that this reads more like a BCP. Was BCP status > considered by the WG? > > > I don't think it was explicitly discussed. We have been treating this > document similarly to the other recommendation documents for WebRTC, > e.g. the recommended audio codecs in > https://tools.ietf.org/html/rfc7874; these docs are all Standards Track. It was actually touched on briefly in this thread: https://mailarchive.ietf.org/arch/msg/rtcweb/UYXeIvdRih3Mp7ox_VnkGdFIBxs In which: * Keith Drage asks for clarification of the intended status * Participant Ted Hardie expresses mostly ambivalence with a very slight lean towards BCP * Harald Alvestrand expresses a somewhat stronger preference, but for ST * Alissa Cooper weighs in with an opinion that "it could be either one" * And then the working group goes on to have a 53-message-long thread about normative language that eventually causes Barry to write RFC 8174. So it was discussed and no one felt strongly about its status, although the sentiment that *was* expressed did, on the average, lean very slightly towards standards track. I agree with Justin's observation that RTCWEB has been putting these kinds of guidance documents out as standards track, in large part because doing things other than what is documented in them can result in decreased interoperability of implementations, which seems more like a standard than a "best practice." /a --------------7951EF22D99F95DB842B61CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 3/6/19 5:37 PM, Justin Uberti wrote:


I agree with Mirja that this reads more like a BCP. Was BCP status considered by the WG?

I don't think it was explicitly discussed. We have been treating this document similarly to the other recommendation documents for WebRTC, e.g. the recommended audio codecs in https://tools.ietf.org/html/rfc7874; these docs are all Standards Track.


It was actually touched on briefly in this thread:

https://mailarchive.ietf.org/arch/msg/rtcweb/UYXeIvdRih3Mp7ox_VnkGdFIBxs

In which:

  • Keith Drage asks for clarification of the intended status
  • Participant Ted Hardie expresses mostly ambivalence with a very slight lean towards BCP
  • Harald Alvestrand expresses a somewhat stronger preference, but for ST
  • Alissa Cooper weighs in with an opinion that "it could be either one"
  • And then the working group goes on to have a 53-message-long thread about normative language that eventually causes Barry to write RFC 8174.

So it was discussed and no one felt strongly about its status, although the sentiment that *was* expressed did, on the average, lean very slightly towards standards track.

I agree with Justin's observation that RTCWEB has been putting these kinds of guidance documents out as standards track, in large part because doing things other than what is documented in them can result in decreased interoperability of implementations, which seems more like a standard than a "best practice."

/a

--------------7951EF22D99F95DB842B61CA-- From nobody Wed Mar 6 18:34:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A06131329 for ; Wed, 6 Mar 2019 18:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 nrfhpFVaFRXw for ; Wed, 6 Mar 2019 18:34:17 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5606131321 for ; Wed, 6 Mar 2019 18:34:14 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id l5so12808976lje.1 for ; Wed, 06 Mar 2019 18:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mH22Rz9Fifbnu1noX9kEUmr8XE3Xw2Lv0k2uiiYUDVs=; b=dVu92ExHQHbb6Zt3OtFpuRBvjdD0wenY60npZ9lKI9nNR+/kfcOP8LwIWxyOV8JqM+ g+wJgfqQT6aNEJ9rB8A/rbArqrDGDXCc0qnca+q2XDdeeSczhvvaGFsGNFDsPw9Cvswm lxisW/hz9uPvTa6wFEk3O8GGP8gm6bzQrpbues1sxxCfDBnfiLQ29HoCTVPCDlF44u1C TSeuQFa+w2l+Tf/ZykswKwqcW1mEvLy/+hZv4g1qdDCluoxQWVIVsV8JK57EZLgQBqLI McARr8axOn6l06md9+Av+sFmfV5/sWWVCEKi6kUP1KnytGUDgR2B6mu3M1EQsKwwwH7T YciQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mH22Rz9Fifbnu1noX9kEUmr8XE3Xw2Lv0k2uiiYUDVs=; b=B3o6W/HqemBenpZhgRvo/ilCYsEkDAVbhDjh0rPTmp9hG2oQrYNm1TjE+dqzd7YuSQ AnDNSablGV/hR2heoUi6i+A4VNMBfAJs1+C2RmjiX31QfUYSXqGDHeZ7tnr8wMO6al0r +T7aIIxUf4CUV13zFRkLKx2vmczssWwRWN0BybQdylFOfQ2hTmg15cxoineqeFoPohQ5 HcYjttb94LUZjtKaaNpwari/YcST3J6+yiiMsGINpP5JROPCHEEyPtOvEk5HyY3UVD46 szHArAQXt1O2priWEL4RWFc67kzjjczbGsymUszf7aX/ThPhrZJnKgJx/KPpt2HcKvTE jnyQ== X-Gm-Message-State: APjAAAUYSd3kXBa1z7iw7SwtOYxGEsOaIn9JwVaLa2bs55SQ73EXJkDR /TJwtONLKiPEunZK7PtTABVSWhcjLKpk/AOu8ACMsw== X-Google-Smtp-Source: APXvYqygas8cJDqQu/pJ5N0Yd17R5PKDGK7k5S/1MaWRdCcuuK/l+LvJcBMV+kwN0GNalQEA3wsWUs/LnPQYxnYanNs= X-Received: by 2002:a2e:a28f:: with SMTP id k15mr4319370lja.160.1551926052659; Wed, 06 Mar 2019 18:34:12 -0800 (PST) MIME-Version: 1.0 References: <155188458557.5238.17233070387773707583.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Wed, 6 Mar 2019 18:33:35 -0800 Message-ID: To: Justin Uberti Cc: Datatracker on behalf of Eric Rescorla , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, The IESG , rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000164cc9058377f19a" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 02:34:20 -0000 --000000000000164cc9058377f19a Content-Type: text/plain; charset="UTF-8" On Wed, Mar 6, 2019 at 3:45 PM Justin Uberti wrote: > > > On Wed, Mar 6, 2019 at 7:03 AM Datatracker on behalf of Eric Rescorla < > ietf-secretariat-reply@ietf.org> wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-rtcweb-ip-handling-11: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Rich version of this review at: >> https://mozphab-ietf.devsvcdev.mozaws.net/D3744 >> >> >> >> COMMENTS >> S 3. >> > >> > 1. If the client is multihomed, additional public IP addresses for >> > the client can be learned. In particular, if the client tries >> to >> > hide its physical location through a Virtual Private Network >> > (VPN), and the VPN and local OS support routing over multiple >> > interfaces (a "split-tunnel" VPN), WebRTC will discover not >> only >> >> This might be simpler if you said "route traffic over" rather than >> "support routing" >> >> Also, do you want to say "may discover" because the guidelines below >> would potentially stop that. >> > > This is the problem statement section; I think it is expected that the > proposed guidelines would invalidate some of the problem definition. > > That said, I could get behind switching 'will' to 'can', as is used in S3, > category #2. > That's fine. >> >> S 6.2. >> > addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to >> > route WebRTC traffic the same way as it would HTTP traffic. STUN >> and >> > TURN will work as usual, and host candidates can still be >> determined >> > as mentioned below. >> > >> > 6.2. Determining Host Candidates >> >> This is framed a little confusingly, because all host candidates are >> suitable in mode 1. Perhaps add "In modes XXX..." >> > > This seems like a good addition. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000164cc9058377f19a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Mar 6, 2019 at 3:45 PM Justin= Uberti <juberti=3D40goog= le.com@dmarc.ietf.org> wrote:


On Wed, Mar 6, 2= 019 at 7:03 AM Datatracker on behalf of Eric Rescorla <ietf-secretariat-reply@= ietf.org> wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3744


COMMENTS
S 3.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 1.=C2=A0 If the client is multihomed, additional p= ublic IP addresses for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the client can be learned.=C2=A0 In = particular, if the client tries to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hide its physical location through a= Virtual Private Network
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (VPN), and the VPN and local OS supp= ort routing over multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interfaces (a "split-tunnel&quo= t; VPN), WebRTC will discover not only

This might be simpler if you said "route traffic over" rather tha= n
"support routing"

Also, do you want to say "may discover" because the guidelines be= low
would potentially stop that.

This is th= e problem statement section; I think it is expected that the proposed guide= lines would invalidate some of the problem definition.=C2=A0

=
That said, I could get behind switching 'will' to 'c= an', as is used in S3, category #2.=C2=A0

That's fine.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


S 6.2.
>=C2=A0 =C2=A0 =C2=A0 addresses (0.0.0.0 for IPv4, :: for IPv6), which a= llows the OS to
>=C2=A0 =C2=A0 =C2=A0 route WebRTC traffic the same way as it would HTTP= traffic.=C2=A0 STUN and
>=C2=A0 =C2=A0 =C2=A0 TURN will work as usual, and host candidates can s= till be determined
>=C2=A0 =C2=A0 =C2=A0 as mentioned below.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A06.2.=C2=A0 Determining Host Candidates

This is framed a little confusingly, because all host candidates are
suitable in mode 1. Perhaps add "In modes XXX..."

This seems like a good addition.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000164cc9058377f19a-- From nobody Thu Mar 7 01:07:22 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50F4130EF2 for ; Thu, 7 Mar 2019 01:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bSZM87__kv5Z for ; Thu, 7 Mar 2019 01:07:17 -0800 (PST) Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0AD130F17 for ; Thu, 7 Mar 2019 01:07:16 -0800 (PST) Received: (qmail 37103 invoked from network); 7 Mar 2019 09:07:14 -0000 X-APM-Authkey: 255286/0(159927/0) 213 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 7 Mar 2019 09:07:14 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6259E18A0614; Thu, 7 Mar 2019 09:07:14 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JWbglLUjhh5r; Thu, 7 Mar 2019 09:07:14 +0000 (GMT) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3319218A04EC; Thu, 7 Mar 2019 09:07:14 +0000 (GMT) From: westhawk Message-Id: <47BAABBF-E762-4DE6-A3FD-AB27A48FFCA9@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_B708A6ED-06FF-4E0E-ABF2-C5C8BF5505D0" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 09:07:13 +0000 In-Reply-To: Cc: Ted Hardie , RTCWeb IETF To: Justin Uberti References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:07:21 -0000 --Apple-Mail=_B708A6ED-06FF-4E0E-ABF2-C5C8BF5505D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Mar 2019, at 23:55, Justin Uberti wrote: >=20 >=20 >=20 > On Wed, Mar 6, 2019 at 2:11 AM westhawk > wrote: >=20 >=20 >> On 6 Mar 2019, at 03:34, Justin Uberti > wrote: >>=20 >> We'll always mask any local addresses with mDNS, since we don't know = if they're public or not. We will also provide a srflx candidate with = the actual address should STUN tell us that information. >=20 > So the =E2=80=98always=E2=80=99 should be conditional on how the = addresses are =E2=80=98found=E2=80=99? > Perhaps a definition of Local IP addresses would help: > =E2=80=9CLocal IP addresses means addresses discovered by = interrogating the operating system for > a list of available interfaces and their associated IP addresses=E2=80=9D= =20 >=20 > Plus a clarification that =E2=80=9Cthese rules do not apply to = addresses that are subsequently found via > STUN or ICE - note that this may cause an address to be listed twice - = once as a host candidate with a masked mdns > and a second time with it=E2=80=99s IP address as a reflex = candidate=E2=80=9D >=20 > Perhaps this could be simplified by simply referring to 'host' IP = addresses, where 'host' has the same meaning (i.e. local interface) as = in ICE.=20 Yep, that is probably clearer. >=20 > (I=E2=80=99ve a feeling there is section of the ICE RFC that talks = about eliminating reflex candidates that duplicate host candidates=20 > but can=E2=80=99t find it) >=20 > There is, but I content it does not apply here, since these srflx = candidates will contain a different (non-hostname) address. Yep, but I think it might be worth a clarification note in this document = - unless it is clear to everyone else that the de-dupe is done by host = name not by underlying address. - Essentially this is a clarification on = what order the processing is done across multiple RFCs. T. --Apple-Mail=_B708A6ED-06FF-4E0E-ABF2-C5C8BF5505D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6 Mar 2019, at 23:55, Justin Uberti <juberti@google.com> = wrote:



On Wed, Mar 6, 2019 at 2:11 AM westhawk <thp@westhawk.co.uk> = wrote:


On 6 Mar 2019, at 03:34, Justin = Uberti <juberti@google.com> wrote:

We'll always mask any local = addresses with mDNS, since we don't know if they're public or not. We = will also provide a srflx candidate with the actual address should STUN = tell us that information.

So the =E2=80=98always=E2=80=99 should = be conditional on how the addresses are =E2=80=98found=E2=80=99?
Perhaps a definition of Local IP addresses would = help:
=E2=80=9CLocal IP addresses means addresses = discovered by interrogating the operating system for
a list of available interfaces and their associated IP = addresses=E2=80=9D  

Plus a clarification that =E2=80=9Cthese = rules do not apply to addresses that are subsequently found = via
STUN or ICE - note that this may cause an = address to be listed twice - once as a host candidate with a masked = mdns
and a second time with it=E2=80=99s IP address = as a reflex candidate=E2=80=9D

Perhaps this could be = simplified by simply referring to 'host' IP addresses, where 'host' has = the same meaning (i.e. local interface) as in = ICE. 

Yep, that is probably clearer.


(I=E2=80=99ve a feeling = there is section of the ICE RFC that talks about eliminating reflex = candidates that duplicate host candidates 
but = can=E2=80=99t find it)

There is, but I content it does = not apply here, since these srflx candidates will contain a different = (non-hostname) address.

Yep, but I think it might be worth a clarification = note in this document - unless it is clear to everyone else that the = de-dupe is done by host name not by underlying address. - Essentially = this is a clarification on what order the processing is done across = multiple RFCs.

T.


= --Apple-Mail=_B708A6ED-06FF-4E0E-ABF2-C5C8BF5505D0-- From nobody Thu Mar 7 01:48:45 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A612D826 for ; Thu, 7 Mar 2019 01:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952124; bh=z/BMbuuyFzaV1mzlqXnMHhUyz1aVrrVjVrnJFOszKl8=; h=From:To:Cc:Subject:Date; b=sZ4yBDQUVp8yeyapSX1Q+11Ref76v53lpRumPV4lXYlNs2ZxEANUa00IGYw8dEo8R jWDEFHfCSs/IMzzp0sDKJbC+bEKrBpF4mgeT5FIhHHtbkHT62Ssu0lyBfI8uxKjLRI KQ+RXue90xQt+VJR0TUCCQUJHtxmlX3CX4ElC6k8= X-Original-To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Benjamin Kaduk To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155192582265.13773.4546017380973569678.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 18:30:22 -0800 Archived-At: Subject: [rtcweb] Benjamin Kaduk's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:48:45 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The question of when an IdP is trustworthy, whether at all (even for "authoritative" IdPs) or for a specific user, is a pretty core topic for the identity assertion scheme presented here. These topics do get explained in localized sections of the document, but there seem to be other portions of the text that do not really acknowledge the risks. I've tried to note these in the COMMENT section (though having finished reading the document, perhaps I am overzealous about determination that an authoritative IdP is indeed authoritative). I also think that we need to be more careful about having the IdP know the semantics of what it's signing (or otherwise attesting to), so that it does not turn into a signing oracle, etc.. The "Modifying the Session" treatment for the SDP "identity" attribute seems incompletely specified. I'm a bit unclear about how the port in the IdP URI's Authority (Section 7.5) would get discovered. If it can be remotely supplied, there may be risks in just trusting blindly whatever value is received. It seems like there are some unstated privacy considerations in allowing the IdP proxy to automatically generate an assertion (that reveals the user's identity) at the request of javascript from the calling application, as described in Section 7.7. Section 9.4 talks about how the IdP is attesting to the binding of the user identified in the assertion with the key fingerprints, but in Sections 7.4 and 7.6 we claim that this assertion is "opaque to the IdP"; these statements appear to be in conflict with each other. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 (My comment about TCB and the other browser from the companion document is probably relevant here, too.) Section 4.1 This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS [RFC5246]. The signaling server processes the message from Alice's This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably". (Also, s/5246/8446.) call and to Alice's identity. In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no specific knowledge of the IdP) to verify the assertion. This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice. [...] I think I'm confused. We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? Section 4.3 Once the ICE checks have completed [more specifically, once some ICE checks have completed], [...] nit: that's not really more specific. Maybe "Once the requisite ICE checks have completed"? Section 5 I see that the 4566 includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 5.1 This section defines the SDP Offer/Answer [RFC6454] considerations for the SDP 'identity' attribute. 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). Section 5.1.3 I feel like we need some text here about the (non?)trustworthiness of the IdP. Section 5.1.4 I'm a bit confused at what's going on here. Is "MAY send the same" supposed to prevent changing it? If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification? Am I allowed to send a different one? Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. nit: is this "each media section"/"every media section" redundant? Section 6.1 Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Section 6.2 Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins. Just to check: this last sentence applies for one-time requets, too? The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. [...] Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). [...] Do we need to say anything about that state transition being visible to the peer, here? UI Requirement: If the UI indication of camera/microphone use are [...] camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] nit: s/windows/window/? Clients MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (though see Section 6.3 for a related issue). Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Section 6.3 While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Is the "the current WG consensus" language going to age well? Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. Is there a WIP draft for this separate document? Section 6.4 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. nit: maybe make it more clear that this only applies for incoming calls? Section 6.5 Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. [...] It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. Endpoints MUST NOT implement TLS False Start [RFC7918]. (7918 doesn't claim to be applicable to DTLS anyway) API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) nit: might be appropriate to note why we care about a super-cookie (and what it is) * The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. I'm not sure I see anywhere that we allow the usage of null ciphers. Section 7 Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to your identity. For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was alice@example.org. [...] I agree with Alissa that the first person is not needed here. Section 7.1 Third-Party: IdPs which don't have control of their section of the [...] identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. If an AP is authenticating via an authoritative IdP, then the RP does not need to explicitly configure trust in the IdP at all. The The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! Section 7.2 In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection A reference to that W3C API spec might be handy. Section 7.3 There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. Section 7.4 The indentation of the line with "}, {" is a bit confusing. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in I'm a little confused what this "encoded in a JSON string" is supposed to mean. This structure does not need to be interpreted by the IdP or the IdP proxy. It is consumed solely by the RP's browser. The IdP merely treats it as an opaque value to be attested to. Thus, new parameters can be added to the assertion without modifying the IdP. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. Section 7.4.1 (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 7.5.2 (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) Section 7.6 The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. (IdP still doesn't want to become a signing oracle.) For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. Section 7.7 I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). Section 8 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. IMPORTANT: Do we need a freshness property for the assertion? Some of these schemes do not provide freshness. Figure 6 shows an example response formatted as JSON for illustrative purposes. (Doesn't the W3C API spec need to say how the response is formatted? Is the JSON formatting actually "illustrative" then, or is this just an example output?) Section 8.1 2. If the domain portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless: Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. Section 9.1 Users who wish to assure themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. In order to protect against malicious content JavaScript, that JavaScript MUST NOT be allowed to have direct access to---or perform computations with---DTLS keys. For instance, if content JS were able to compute digital signatures, then it would be possible for content JS to get an identity assertion for a browser's generated key and then use that assertion plus a signature by the key to authenticate a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. I don't think I fully understand the scenario described in this last sentence. Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? Section 9.2 Otherwise, the other side will learn linkable information. nit: "linkable information that would allow them to correlate the browser across multiple calls". Section 9.3 Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. I think I'm missing a step here. How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. nit: "must be used to suppress the misbehaving flow", I think. Section 9.4.3 The "origin" field of the signature request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? Section 9.4.5.1 nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". Section 13.2 It's perhaps debatable that JSEP is only an informative reference. From nobody Thu Mar 7 01:49:19 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9D13136E for ; Thu, 7 Mar 2019 01:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952130; bh=cQWKj8ovnifFBic3PpRI8xHxiTu0EPH6RGsrz2eCeMM=; h=From:To:Cc:Subject:Date; b=CWA4ZZ51azSsQNZyOgCeAxer+Ae/WvhLI+0YMTTtfelLSBA4jA7debvHpGuXGipO3 RhP+vgZpMkIgL1Ie3BpT/7TYuKiX4UVMiXuD9l7sDJT8MwVpH4YiT09nDWmaXSmQXB eNtrkqNOXLmzcqq5LgUB5SsV8STYYgj2l9BQt76E= X-Original-To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Benjamin Kaduk To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155192710483.13718.15164609638438627437.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 18:51:44 -0800 Archived-At: Subject: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:48:55 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben about the STUN/TURN normativity. Section 5.1 2. By default, WebRTC should be able to negotiate direct peer-to- peer connections between endpoints (i.e., without traversing a NAT or relay server). [...] I'm not sure how to interpret "be able to", here, with respect to "without traversing a NAT", since if one endpoint is behind a NAT w.r.t. the public Internet, that's not possible. Section 5.2 Mode 1 MUST only be used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. nit: we may not have left a big enough breadcrumb trail for the reader to find "getUserMedia consent". From nobody Thu Mar 7 01:49:41 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB41313FD for ; Thu, 7 Mar 2019 01:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952134; bh=SyBUG3NuUL3T4g5EOszpHpNqil6KJdmvDHppf31VOL0=; h=From:To:Cc:Subject:Date; b=WUYvyAkOAnChWNkCxCu2PeFUFcJXpONyuvGcQcY9iDpwKXjOt7wTvajc888xaN1kI g/ZhafbL0C2LeCIft/611FjhoLyKv9drqvYMBr4BUOVGFXPpfG3t6bSqc4OcxSmg6U HzVzYuSfRrtOe3fkT767aB+GZwEZl+zeKHtV1NJQ= X-Original-To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Spencer Dawkins To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155192908526.13814.8369245552983831155.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 19:24:45 -0800 Archived-At: Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:48:59 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Benjamin's question about Section 5.1 (but I'll watch the discussion on his ballot thread, so no follow-up needed here). From nobody Thu Mar 7 01:50:26 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF31313E4 for ; Thu, 7 Mar 2019 01:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952142; bh=RYJ1im8pvN3P3d3mX6mNe5WNm96fB6QWRuaObStgU5c=; h=From:To:Cc:Subject:Date; b=hEzhbmfllEN8/geO/9zMr83AD+a+HDrQFuFNffkV88s5texTYQV5iWWZKaFsKdqzY 0aCZ/ZpQs1DI0ElsTXpHfUcRZ3VZunOQdiEr1cjGTZvnxBKWVrx247CKS0Idy+KMf0 lIjQ2d3HiMAMslzA08UMvaKzUKWqWeoXZMlZW360= X-Original-To: rtcweb@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Suresh Krishnan To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155193259226.13743.3839965952947451511.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 20:23:12 -0800 Archived-At: Subject: [rtcweb] Suresh Krishnan's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:49:07 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3 Not sure how the use of temporary addresses in IPv6 [RFC4941] is relevant at all to a discussion of NAT usage (#2). Can you please clarify? "#2 is a less significant but valid concern. While the [RFC4941] IPv6 addresses recommended by [I-D.ietf-rtcweb-transports] are fairly benign due to their intentionally short lifetimes" From nobody Thu Mar 7 15:37:34 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1AA1277D2 for ; Thu, 7 Mar 2019 15:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.479 X-Spam-Level: X-Spam-Status: No, score=-16.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 43pgP2mux8tO for ; Thu, 7 Mar 2019 15:37:31 -0800 (PST) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9793130F07 for ; Thu, 7 Mar 2019 15:37:29 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id z124so18739476itc.2 for ; Thu, 07 Mar 2019 15:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=Q0W3EMvkuvltvV126sXap/YINPw9LqyK9msB8t+Elt0=; b=NHAMtALakRge8erG0dvdAAdERAgaer5SlW56SPMdxWDK6tIVXHHl9F3x0/Bfa4AUAq ouieTJouSokvOo+b/iwVdhzRTsN6Wh7xzXyT2/alzXwmFap2jDq/jp4lI0BsTppOVsR5 ug77MXCf3SbzQ/qBix8cYFXbOtnvsVMuCRL7gNRZc2hJKnDGRO/pDVwodUuc5K26UCoU wt9NAWmfpofEnhYGNoile9cyS1XLx+PIPKY0pp4g3b0GBHfRuvKqNxbXq+KkJPZrKlPH hl8H6Ca30Xz0plgQrdvQd6bRghi/HTU2rRZaWyseFRg8G5RMEEkpsN7PKdv8BYOa2418 aVLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=Q0W3EMvkuvltvV126sXap/YINPw9LqyK9msB8t+Elt0=; b=QreU8oz6RX4jsSx+LrW3cB0s4t43yF8RWT0JmXbIQUYZFBvYOFMdA0AG3yesdPt/G3 qoLgZYof70DEasNRXt22+3b9NkBesAdJQPMEDQEWiuDSu73srv3K77LMvxvWdntA+ylC e/PT6Yf+Of8y03IMjo4JVWwHxFrG6Q+AthPfuD2/uLIoJlzMqBHUxoPQjouisHC1kmUJ bakAEqNlytYwQh11w00jN2vQeUUWCWMhW18Kdw2P1wnH4h7VoTDFj1yVi+/WFGo2U6FX jTRMq6m3/xxn+fsrv3IiebblqObcDt3LVTncIm1w/Fe4NWFWCa7PV261okk8WgQzTh5y Nl6Q== X-Gm-Message-State: APjAAAVf/9lwStFkgAOHaQJXoUpEBMCH/iOnhnZptmfvbgC6rXrBz3cA X5lptr4Ei+j7nWuPAjM/Pja49+10El3B8jdlAwSttg== X-Received: by 2002:a02:a482:: with SMTP id d2mt1538719jam.88.1552001848866; Thu, 07 Mar 2019 15:37:28 -0800 (PST) MIME-Version: 1.0 References: <155192710483.13718.15164609638438627437.idtracker@ietfa.amsl.com> In-Reply-To: <155192710483.13718.15164609638438627437.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Thu, 7 Mar 2019 15:37:17 -0800 Message-ID: Cc: The IESG , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e615750583899633" Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:37:33 -0000 --000000000000e615750583899633 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 1:49 AM Datatracker on behalf of Benjamin Kaduk < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-rtcweb-ip-handling-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Ben about the STUN/TURN normativity. > > Section 5.1 > > 2. By default, WebRTC should be able to negotiate direct peer-to- > peer connections between endpoints (i.e., without traversing a > NAT or relay server). [...] > > I'm not sure how to interpret "be able to", here, with respect to > "without traversing a NAT", since if one endpoint is behind a NAT w.r.t. > the public Internet, that's not possible. > There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this. > Section 5.2 > > Mode 1 MUST only be used when user consent has been provided. The > details of this consent are left to the implementation; one potential > mechanism is to tie this consent to getUserMedia consent. > > nit: we may not have left a big enough breadcrumb trail for the reader > to find "getUserMedia consent". > Noted. --000000000000e615750583899633 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2019 at 1:49 AM Datatr= acker on behalf of Benjamin Kaduk <n= oreply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot position for=
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Ben about the STUN/TURN normativity.

Section 5.1

=C2=A0 =C2=A02.=C2=A0 By default, WebRTC should be able to negotiate direct= peer-to-
=C2=A0 =C2=A0 =C2=A0 =C2=A0peer connections between endpoints (i.e., withou= t traversing a
=C2=A0 =C2=A0 =C2=A0 =C2=A0NAT or relay server).=C2=A0 [...]

I'm not sure how to interpret "be able to", here, with respec= t to
"without traversing a NAT", since if one endpoint is behind a NAT= w.r.t.
the public Internet, that's not possible.

There is an implicit "where possible" here. The specific s= cenario is for two devices behind the same NAT who could communicate direct= ly if only they knew each others' addresses; in this case, a direct con= nection should be possible, which implies that there needs to be some way f= or the two sides to share their machine addresses. Naturally, devices behin= d different NATs will not be able to do this.


Section 5.2

=C2=A0 =C2=A0Mode 1 MUST only be used when user consent has been provided.= =C2=A0 The
=C2=A0 =C2=A0details of this consent are left to the implementation; one po= tential
=C2=A0 =C2=A0mechanism is to tie this consent to getUserMedia consent.

nit: we may not have left a big enough breadcrumb trail for the reader
to find "getUserMedia consent".

Noted.=C2=A0
--000000000000e615750583899633-- From nobody Thu Mar 7 15:42:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295BD130FB8 for ; Thu, 7 Mar 2019 15:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.479 X-Spam-Level: X-Spam-Status: No, score=-16.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LZ-Kn2472ReW for ; Thu, 7 Mar 2019 15:42:08 -0800 (PST) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D76413103D for ; Thu, 7 Mar 2019 15:42:06 -0800 (PST) Received: by mail-it1-x144.google.com with SMTP id f186so5062788ita.0 for ; Thu, 07 Mar 2019 15:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=San+6tJEXNbIkUrVCnzOmOq/W+y21gwWr+0A2I8xpDU=; b=LBRHNqYLxidIisQzDOzwGjDRUj8loXboFTlOIz3ROHAkgoFnKgcfPBVx8l51cqgAv0 ybquAZck5pChonE7JCjW4SUAaNgMSdcM+RzrihaEC1U0ElKUz8cxHpfM6+2w7bRLsB4m LUAZZ0T1O/JEaiqrx06zbovL+UeKX56hFx5q/yuoC4XwbldZWAIkBHXcxb3ujMC6cA8X LN2GEi9B77eMTcUZIKgi9DeQm4CSOV2L5XM07cV+LgT/ovTzAOiDQCPG257dO/Nu+3nK SQyAATfyQXZIDMQEl+CPWKr3wF2yq8w0mNZS/8yI9T6u5kMzG2aUa3O9goOG77ijaRxk DXsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=San+6tJEXNbIkUrVCnzOmOq/W+y21gwWr+0A2I8xpDU=; b=N0TEU12T6RiR2TEnk2EdVB4T6O8efWswzOvBemnM859s2Ru0nrPWfXffqsAszbtw3V /vkLYyZgCUHMhzpQaPmDJvaf929sX1gwN1TyXcvzVvtYiTIQlM4SCtb4gRTKEASVRqZ2 hAukpMBSclblEY9qHoXX0zJGuwi1tig0GZYz3vTwAD38xRgjSrkc9MxyLKH3L/VQ+eRp hgPsNqKKpFkt/HyhwisMhlvbgZN1iw1v1TRlMVJw+2p01Bj2lEjk+20i7SsoQxq6GywM u/H4+MccpY0QC2WMBl3ixq/sCsmadHsapwMQJAIfXLZ5rO4+c2YE4wMIJ6zyTolyZSji Rgmg== X-Gm-Message-State: APjAAAV3p8wrRPVENo1W29jHd1b8LxLqtonSsRRnhrIYi72qZJ5XF74m UqgtpsXbPmp157eq6jbLRA88P/Ly+SrrlVJup9Sxvg== X-Received: by 2002:a24:6588:: with SMTP id u130mt6582472itb.136.1552002125525; Thu, 07 Mar 2019 15:42:05 -0800 (PST) MIME-Version: 1.0 References: <155193259226.13743.3839965952947451511.idtracker@ietfa.amsl.com> In-Reply-To: <155193259226.13743.3839965952947451511.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Thu, 7 Mar 2019 15:41:53 -0800 Message-ID: Cc: The IESG , RTCWeb IETF , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000629ff4058389a7af" Archived-At: Subject: Re: [rtcweb] Suresh Krishnan's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:42:09 -0000 --000000000000629ff4058389a7af Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 1:50 AM Datatracker on behalf of Suresh Krishnan < noreply@ietf.org> wrote: > Suresh Krishnan has entered the following ballot position for > draft-ietf-rtcweb-ip-handling-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 3 > Not sure how the use of temporary addresses in IPv6 [RFC4941] is > relevant at > all to a discussion of NAT usage (#2). Can you please clarify? > > "#2 is a less significant but valid concern. While the [RFC4941] IPv6 > addresses recommended by [I-D.ietf-rtcweb-transports] are fairly > benign due to their intentionally short lifetimes" > The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address. --000000000000629ff4058389a7af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 7, 2019 at 1:50 AM Datatr= acker on behalf of Suresh Krishnan <= noreply@ietf.org> wrote:
Suresh Krishnan has entered the following ballot position f= or
draft-ietf-rtcweb-ip-handling-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3
=C2=A0 Not sure how the use of temporary addresses in IPv6 [RFC4941] is rel= evant at
=C2=A0 all to a discussion of NAT usage (#2). Can you please clarify?

=C2=A0 "#2 is a less significant but valid concern.=C2=A0 While the [R= FC4941] IPv6
=C2=A0 =C2=A0addresses recommended by [I-D.ietf-rtcweb-transports] are fair= ly
=C2=A0 =C2=A0benign due to their intentionally short lifetimes"

=C2=A0The most obvious case is a NAT64 scenar= io, where the IPv6 address is never seen by the outside world, and therefor= e exposing said address to the web site presents a potential leakage concer= n. This concern is significantly mitigated if the IPv6 address is a RFC4941= ephemeral address.
--000000000000629ff4058389a7af-- From nobody Thu Mar 7 15:47:47 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96922130E82 for ; Thu, 7 Mar 2019 15:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Zk5o1wAK-PtI for ; Thu, 7 Mar 2019 15:47:43 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2619C12DF71 for ; Thu, 7 Mar 2019 15:47:43 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id z124so18771325itc.2 for ; Thu, 07 Mar 2019 15:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Ernwo/htdca0kSo4aIFgSOHkYSurgMPajWk3kxMy+E=; b=ZKr5V1aHsExznhOi1IOPRbhq5Rhi5NJvarRVX5nChopIRlb+Ar1V2lJt05/IH7XPeH w6ND2Q7ezNWBAU+rJFSizcrAIy8scebxuxHb/1rffGulgHe9/TWp5O52b7kAHLG9/r8E pKSayZt+31YeKL1m6DJ30uUoa3MKiB3JJjvIzh6pVYURqifUse4Elx6Ym2LwRcPom3yN 8L1cwXUvkl8jamPlSEtMIV1xFWb6kUykES3YWGI7BJBVMOWe63PIDEdYH3ajDysDfXYP WqpfGqc5g+pcTum16r0mJH9VNRkQn6Ik4l9cJMoH1nQI48TuEqQvg+HkOi2NVZTl/Iwi Pcfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Ernwo/htdca0kSo4aIFgSOHkYSurgMPajWk3kxMy+E=; b=W3YK83P6R/PWOceUlsAN9NomzDBm+KuhXaimZlcdYk4EBc2xYMlF6c+i2S+HHN0y8a +fceZBaYivRsAyhGbTvSio7t3d+nndUNxa9/iyzHjM54tA7BRXDdYKD7y9Ta+UqbYbTM Qxy63I2//NKaGf41qLC8hE4ye43iGjJQfWXxBj5l26Ebkxvgzh08jKCpIJaUUNMJsmGd XLJ1iLZgx74tUhhfELW1eBcQMGiwVA6+5/N5aJp9sdUoxrm+1GTtkXeqRDAV1v4iCMgp d7pPjJCDKAs7N0voGlaePLTJ0iyChjVqMpnn0Bdi5wEnbfwA8OxxvR3WfRoeMCiGt5Vk KejA== X-Gm-Message-State: APjAAAWL73GGK/lq4ylI1dePpFjTz5bWmFe7251T7f/+0IE1WwPtnzrp PCKZcreXOVCDmAZ5703eredBgBi6ApVKchuLm33crA== X-Google-Smtp-Source: APXvYqwTJ8yokDkrw/Z24/RHdYw4K5Rj/UjvSvSwjtdQHtuNAz4ODj7ZFajCTkQeEmPxXYpCioaw2TvE5iCG/EzNT10= X-Received: by 2002:a02:85ec:: with SMTP id d99mr507715jai.116.1552002462145; Thu, 07 Mar 2019 15:47:42 -0800 (PST) MIME-Version: 1.0 References: <3AAE140F-F6BC-4C5F-A5AF-DE81A8876C21@westhawk.co.uk> <47BAABBF-E762-4DE6-A3FD-AB27A48FFCA9@westhawk.co.uk> In-Reply-To: <47BAABBF-E762-4DE6-A3FD-AB27A48FFCA9@westhawk.co.uk> From: Justin Uberti Date: Thu, 7 Mar 2019 15:47:30 -0800 Message-ID: To: westhawk Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000072c492058389bb99" Archived-At: Subject: Re: [rtcweb] Call for review X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 23:47:46 -0000 --00000000000072c492058389bb99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 7, 2019 at 1:07 AM westhawk wrote: > > > On 6 Mar 2019, at 23:55, Justin Uberti wrote: > > > > On Wed, Mar 6, 2019 at 2:11 AM westhawk wrote: > >> >> >> On 6 Mar 2019, at 03:34, Justin Uberti wrote: >> >> We'll always mask any local addresses with mDNS, since we don't know if >> they're public or not. We will also provide a srflx candidate with the >> actual address should STUN tell us that information. >> >> >> So the =E2=80=98always=E2=80=99 should be conditional on how the address= es are =E2=80=98found=E2=80=99? >> Perhaps a definition of Local IP addresses would help: >> =E2=80=9CLocal IP addresses means addresses discovered by interrogating = the >> operating system for >> a list of available interfaces and their associated IP addresses=E2=80= =9D >> > >> Plus a clarification that =E2=80=9Cthese rules do not apply to addresses= that are >> subsequently found via >> STUN or ICE - note that this may cause an address to be listed twice - >> once as a host candidate with a masked mdns >> and a second time with it=E2=80=99s IP address as a reflex candidate=E2= =80=9D >> > > Perhaps this could be simplified by simply referring to 'host' IP > addresses, where 'host' has the same meaning (i.e. local interface) as in > ICE. > > > Yep, that is probably clearer. > > >> (I=E2=80=99ve a feeling there is section of the ICE RFC that talks about >> eliminating reflex candidates that duplicate host candidates >> but can=E2=80=99t find it) >> > > There is, but I content it does not apply here, since these srflx > candidates will contain a different (non-hostname) address. > > > Yep, but I think it might be worth a clarification note in this document = - > unless it is clear to everyone else that the de-dupe is done by host name > not by underlying address. - Essentially this is a clarification on what > order the processing is done across multiple RFCs. > > That's reasonable. We'll add a note to this effect in the main rtcweb-mdns-candidates document. https://github.com/rtcweb-wg/mdns-ice-candidates/issues/105 --00000000000072c492058389bb99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 7, 2019 = at 1:07 AM westhawk <thp@westhawk.= co.uk> wrote:


On 6 Mar 2019, at 23:55, Justin Uberti <juberti@google.com> wrote:


On Wed, Mar 6, 2019 at 2:11 AM westhawk <thp@westhawk.co.uk> wr= ote:


On 6 Mar 2019, at 03:34, Justin Ubert= i <juberti@googl= e.com> wrote:

We'= ;ll always mask any local addresses with mDNS, since we don't know if t= hey're public or not. We will also provide a srflx candidate with the a= ctual address should STUN tell us that information.

So the =E2=80=98always=E2=80=99 should be conditional = on how the addresses are =E2=80=98found=E2=80=99?
Perhaps a defin= ition of Local IP addresses would help:
=E2=80=9CLocal IP address= es means addresses discovered by interrogating the operating system for
a list of available interfaces and their associated IP addresses=E2= =80=9D=C2=A0=C2=A0

Plus a clarification = that =E2=80=9Cthese rules do not apply to addresses that are subsequently f= ound via
STUN or ICE - note that this may cause an address to be = listed twice - once as a host candidate with a masked mdns
and a = second time with it=E2=80=99s IP address as a reflex candidate=E2=80=9D

Perhaps this could be simpli= fied by simply referring to 'host' IP addresses, where 'host= 9; has the same meaning (i.e. local interface) as in ICE.=C2=A0
=

Yep, that is probably clearer.
=

(I=E2=80=99ve a feeling there is section of the ICE RFC that talks = about eliminating reflex candidates that duplicate host candidates=C2=A0
but can=E2=80=99t find it)

<= /div>
There is, but I content it=C2=A0does not apply here, since these = srflx candidates will contain a different (non-hostname) address.
=

Yep, but I think it might be worth = a clarification note in this document - unless it is clear to everyone else= that the de-dupe is done by host name not by underlying address. - Essenti= ally this is a clarification on what order the processing is done across mu= ltiple RFCs.

That's reasona= ble. We'll add a note to this effect in the main rtcweb-mdns-candidates= document.
--00000000000072c492058389bb99-- From nobody Sat Mar 9 10:27:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49E3130EC7; Sat, 9 Mar 2019 10:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 U1aBaX2m_Gtu; Sat, 9 Mar 2019 10:27:26 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820139.outbound.protection.outlook.com [40.107.82.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68B7130E63; Sat, 9 Mar 2019 10:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N1odL2k1+OdOelSrYddGbyJVeFjWkv382FkOI8Fm5Mw=; b=IU/tTkv6DQFs69hqI6rvhYHdhSg8udaor4339p3tJuR3ChZBnkZ+sqiouYUZB2tETLXa3+35Aa1QoOQhIJs91Te3H76aHtW0e20U//2jFWEHbK/WuljrnhFARG3pZUDbU28FNl8VTjjl0mQmew2O4c+t07dzybTjCZmJAYUAdls= Received: from DM5PR0101CA0005.prod.exchangelabs.com (2603:10b6:4:28::18) by CY1PR01MB2012.prod.exchangelabs.com (2a01:111:e400:c60e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Sat, 9 Mar 2019 18:27:22 +0000 Received: from BY2NAM03FT012.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::202) by DM5PR0101CA0005.outlook.office365.com (2603:10b6:4:28::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18 via Frontend Transport; Sat, 9 Mar 2019 18:27:22 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT012.mail.protection.outlook.com (10.152.84.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Sat, 9 Mar 2019 18:27:22 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x29IRIfV013492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Mar 2019 13:27:20 -0500 Date: Sat, 9 Mar 2019 12:27:18 -0600 From: Benjamin Kaduk To: Justin Uberti CC: , RTCWeb IETF , The IESG , Message-ID: <20190309182718.GL9824@kduck.mit.edu> References: <155192710483.13718.15164609638438627437.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(136003)(346002)(2980300002)(199004)(189003)(97756001)(305945005)(8676002)(47776003)(106466001)(55016002)(486006)(66574012)(966005)(246002)(1076003)(6306002)(88552002)(8936002)(36906005)(4326008)(2906002)(26826003)(356004)(76176011)(104016004)(426003)(446003)(5660300002)(86362001)(53546011)(16586007)(316002)(53416004)(956004)(58126008)(476003)(106002)(33656002)(186003)(11346002)(786003)(229853002)(26005)(75432002)(478600001)(50466002)(54906003)(46406003)(23726003)(7696005)(6246003)(336012)(126002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR01MB2012; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7b4c3e0d-4403-44df-c807-08d6a4bcdf33 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:CY1PR01MB2012; X-MS-TrafficTypeDiagnostic: CY1PR01MB2012: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2012; 20:wg3SyVmNZU5h9W7vP7742Cz23lT0D1ezTIYv+vZs0PpnXRtWw6CsFzmV5MiguriHAjs1kAGtwqbJ47hguDkjjzV95zzEcKmg/UPDSChlD2VwzAGp7qRblX+EsIxX82nfd6TjViCIaA8Ms1DP0z09HTfz4FMGyG0NV98uVKuTfQRv1w0dnJOd11oYet1vhPQTOmg3zcCK5FreMpg63aOkujxznFRFwTXvenQm91kMewaNDhTOYcNeRwQQWHKcRlatwhBdloZ91LOGhZwbq2DydF3AOAoqa0SUVU2e5xXClahwlNLZ8mX5AaFyX9F+r1714JEnHS3YRmuezCvhrvWOg0Air5or/C3f4/RSBzsJyYPUVPSZJcUi+vbkz+apDfORXsKjulwK7B83h8CpffhDaFRKwSmvqiGzCXOx0z7YJO2YQl0GFMpnm+zlFQHnTzCXvYIn41FcCseP5G2wRlaRVmVLPcJc8DGBL/ugADPw5N4QF2w5WZ0OV7XMfz3IYpDomVn8XyZFiDRBF6fORpOoY2/lbQrerUti9Qva1f92pUkRlNUJxoqcQi6IH7o9+bVTmw56zyC2HgX3U4J+DNqIivyKkCL5BnrdJyi3dctR8b4= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0971922F40 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR01MB2012; 23:OyZFXkSa00tevY0n/X36KFnOBuyGPcNSTsFm5B+k9?= =?us-ascii?Q?35lPr1lEcN72+mrTG8ub645m1ilkrbD+rckQPoNq3ZBUBwRfEeOAtlyOcTXU?= =?us-ascii?Q?CdoU2xWQyI8a8ZKTa1HVWLbBs/zLh7heL2wnStz0HYZKzLqcloCabtfgOY/7?= =?us-ascii?Q?wOsFVU9fsnN+Lj0wDVUiAic5cTM7Kjbd5wzJ/J44F1vB1Z8/et5rgHouolqn?= =?us-ascii?Q?EHiG0McHV3PzmD8alIfb9Pv9sjCv52jGMv8amP0BoHGB8lLc0injS8/mqycd?= =?us-ascii?Q?dY2AS2xalI3oSlQAnLB0RZdhb8gqtlKo5dmT6p5DPcAFuLqD5a0hht6su8zW?= =?us-ascii?Q?saX/ZO0FD+zoK0RMY/kmljmOe4eY99CEInG2AkOXv7xJwr7kCwzmWgHziUsd?= =?us-ascii?Q?xzKQJAb9hc1+eGfxBkkklxdOeHdTUzv97uEmH7hu2Hjfo8pbIrZXe517xoiJ?= =?us-ascii?Q?ch5/8YAsufzjrtCJHkpjJWS4sDX2L4/cnQGYIOj4MJnJXdo3Wi7WhPHnIoLZ?= =?us-ascii?Q?InrPYJioHyHCUCbfD4hVe6SJQmhwvNnaDdUFU7aucw0F/8JZ+Xkw4HIuJNsx?= =?us-ascii?Q?Woddggsw+Ym141TRcMUE/g6CpGVliyPU68KAH3siuAawHPtdliSZgTXJXHVd?= =?us-ascii?Q?oLglGGDzMgNoT3x8fgohhqzaHcRGeQuo9cg/5NqZ33gbJan89IwnIHvAt7Ex?= =?us-ascii?Q?cC3EZBquDCjjKKUgU1H8Sg/HLvvlASwDQ76KT15eKGbfBF2WT9R1cxeMA7Ab?= =?us-ascii?Q?JwJ1rjLP6n/FvY8UeuivjdJ8NPSQ6lLgd/xh0ZouIpprOf8zUXP6ReMpRRQs?= =?us-ascii?Q?2fh/+/Z7dnKmqEmVAXt6t93ECl5HFhq5P7XP5RrOIt1oBH1eWZnVu3z7sXeo?= =?us-ascii?Q?gEeTjeEOUlfiuEz35h3vmEIP+rEmidGQ+Mjv0LPH69z9wuIhCqhnEb2W1V2M?= =?us-ascii?Q?n+Pj9gfT5Y/6V9WXmgHcLgIooNM00NEaRLlgsQ7ow9R4mAkV8qkOdrxBSKMo?= =?us-ascii?Q?gbHLtXx0G8FiYVGZdya5SOwCzczr+TJVo43FK6uXN6sx+aPtmGIp4/KI541B?= =?us-ascii?Q?/nUWQxTR/fvim+k6ygFpnwZIIE5lS0pLqkodXyoi94l9lwMfagH2i8Fm2VoI?= =?us-ascii?Q?a7QfAvPckQU0hm8n5Sp7ExfeszOtudBMMFpXV8zvh8eiRrv3ztkqIoQ1sMOg?= =?us-ascii?Q?rXMMMqfWsz/BdE5iwG0fATq+GSy0xT9hZSa+280QTqOawUwESIGtVaDBR1N8?= =?us-ascii?Q?nODsFJkTd81ac9/Ha4=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 67X7rVY9kVPOi4tSWQoH07Nee7bacH1i4M1JwareCBr735dGWfSUOpVA9ufDQaCbuMt0RWUqg9gC6FIkynE6glll+qoZLx2h/7vAcTLVq2P2SWpaZTB5GkjgU+/keNJ1CSwf+5X2P/IADuRvg6eTrUtlWahslgZMdbikD+ijR40VX8DMnuyoCPlw9UjSnzpjGB+e9Jo/pNXwPWZsp2Zi53hE79HHmQTBuSIewJoycJT3GBhQ0KT1WMWgOhcOK87XVBcgOfUJ0doNm8R63OPhWkxiDSfNDoeNb6Uj2C3Mvvk3Sooz2nV2riWJT15DMreGVyquyDts35GkKTrW44N0gZEdjU4Lut7Fddh4uNNoOV6ZPK6zD6PH8A3GhrcSbBDZWqmUQ+CF3YfDGEc/ttxv6yevTPfmSjV/KUAQmtkWPnQ= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2019 18:27:22.1100 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4c3e0d-4403-44df-c807-08d6a4bcdf33 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB2012 Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-ip-handling-11: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 18:27:29 -0000 On Thu, Mar 07, 2019 at 03:37:17PM -0800, Justin Uberti wrote: > On Thu, Mar 7, 2019 at 1:49 AM Datatracker on behalf of Benjamin Kaduk < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-rtcweb-ip-handling-11: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Ben about the STUN/TURN normativity. > > > > Section 5.1 > > > > 2. By default, WebRTC should be able to negotiate direct peer-to- > > peer connections between endpoints (i.e., without traversing a > > NAT or relay server). [...] > > > > I'm not sure how to interpret "be able to", here, with respect to > > "without traversing a NAT", since if one endpoint is behind a NAT w.r.t. > > the public Internet, that's not possible. > > > > There is an implicit "where possible" here. The specific scenario is for > two devices behind the same NAT who could communicate directly if only they > knew each others' addresses; in this case, a direct connection should be > possible, which implies that there needs to be some way for the two sides > to share their machine addresses. Naturally, devices behind different NATs > will not be able to do this. Maybe we can think about tighter wording to use here. I'm not sure if just using "hairpin NAT" instead of "NAT" would be (1) correct and (2) good enough; we could also make the "where possible" explicit instead of implicit. But I don't feel a need to have a say in the final wording -- that can be between you and the responsible AD. -Benjamin > > > Section 5.2 > > > > Mode 1 MUST only be used when user consent has been provided. The > > details of this consent are left to the implementation; one potential > > mechanism is to tie this consent to getUserMedia consent. > > > > nit: we may not have left a big enough breadcrumb trail for the reader > > to find "getUserMedia consent". > > > > Noted. From nobody Sun Mar 10 15:21:48 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45779128B36; Sun, 10 Mar 2019 15:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Chown via Datatracker To: Cc: draft-ietf-rtcweb-security-arch.all@ietf.org, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155225650317.30991.14829057607913402706@ietfa.amsl.com> Date: Sun, 10 Mar 2019 15:21:43 -0700 Archived-At: Subject: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-arch-18 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 22:21:44 -0000 Reviewer: Tim Chown Review result: Has Issues Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes the security architecture for WebRTC, a protocol used for real-time communications between web browsers. It aims to address the threats and requirements described in draft-ietf-rtcweb-security, by the same author. The document is well-written, easy to read and free of typos. Overall, the document is close to being ready for publication, and the points as covered all seem appropriate, but I have some comments that the author should consider addressing. Major comments: Firstly, it is not clear that all the threats and requirements in draft-ietf-rtcweb-security have been addressed, as claimed in the Introduction to this document. It would be useful to see the threats in the threats draft enumerated, and a section / appendix in this document saying where / how they are addressed or whether they remain open to be resolved. Section 9 says "in order to avoid repetition", but I found it hard to deduce whether this draft met its claim of addressing all the threats. As an example, there is discussion of fingerprinting in the threats document, but I don't recall seeing that being covered in this document. Secondly, it is not clear why communications to the call service can be over plain http. What is this allowed? Section 4.1 says communications to the calling service are "preferably over TLS"; why is this not a MUST be over TLS? Likewise, 6.1 talks of http and https origins, and section 9.1 says "if https is not used to the signalling server". Privacy is of course important, more so since RFC 7258. From the user's perspective, how do they judge setting the slider between security and privacy? Section 4 says the document errs towards security rather than privacy, but how can user make an informed decision? Section 9.2 says "Sites SHOULD make users aware of these tradeoffs", but how do you do that in a way a typical user can understand? Section 9.2 talks about sites and that they SHOULD offer privacy-enhancing features by default, but perhaps you can go further and say that MUST make rolling DTLS keys be a configurable option. Similarly for the privacy-preserving CNAME generation mode. It would seem natural to publish this draft and draft-ietf-rtcweb-security at the same time; I assume this is already planned. Minor comments: In the Introduction, s/some Web server/a Web server providing the calling service/ ? In section 3.1, 2nd bullet, isn't DTLS-SRTP a MUST later in the document (section 6.5), or are you not referring to keying here? Are these two points consistent? In Section 4, "relying party" is a term used before it is defined in 7.1. Perhaps a definition of some terms would be useful in an early section in the document? Best wishes, Tim From nobody Thu Mar 21 03:50:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275D8130F5B for ; Thu, 21 Mar 2019 03:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TBDARtPUwmHm for ; Thu, 21 Mar 2019 03:50:32 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74AA130EC7 for ; Thu, 21 Mar 2019 03:50:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2F4D47C3F64; Thu, 21 Mar 2019 11:50:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 440bhW66E3c1; Thu, 21 Mar 2019 11:50:28 +0100 (CET) Received: from [192.168.3.141] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id BF3EE7C3E70; Thu, 21 Mar 2019 11:50:28 +0100 (CET) To: "public-webrtc@w3.org" , "rtcweb@ietf.org" From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <354fbd14-4368-502c-195d-bdf7127f8115@alvestrand.no> Date: Thu, 21 Mar 2019 11:50:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [rtcweb] Reminder: WebRTC table at IETF hackathon in Prague X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 10:50:35 -0000 As of this Saturday, we will have the WebRTC hackathon event as part of the IETF hackathon in Prague. So far, 11 people have signed up and indicated that they'll want to do WebRTC; we know there will be more. If you're coming, remember to sign up for the hackathon; registration is free, and separate from the IETF registration: https://www.ietf.org/registration/ietf104/hackathonregistration.py General info on the hackathon: https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon Specific sub page for WebRTC (still work-in-progress): https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon/webrtc Welcome! -- Surveillance is pervasive. Go Dark. From nobody Mon Mar 25 04:51:31 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AA120407; Mon, 25 Mar 2019 04:51:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <155351469035.29041.4094773978737475729@ietfa.amsl.com> Date: Mon, 25 Mar 2019 04:51:30 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-mdns-ice-candidates-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 11:51:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Using Multicast DNS to protect privacy when exposing ICE candidates Authors : Youenn Fablet Jeroen de Borst Justin Uberti Qingsi Wang Filename : draft-ietf-rtcweb-mdns-ice-candidates-03.txt Pages : 18 Date : 2019-03-25 Abstract: WebRTC applications collect ICE candidates as part of the process of creating peer-to-peer connections. To maximize the probability of a direct peer-to-peer connection, client private IP addresses are included in this candidate collection. However, disclosure of these addresses has privacy implications. This document describes a way to share local IP addresses with other clients while preserving client privacy. This is achieved by concealing IP addresses with dynamically generated Multicast DNS (mDNS) names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-03 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-mdns-ice-candidates-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 26 03:28:36 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F111202A3 for ; Tue, 26 Mar 2019 03:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 Fx6kUEMaVrez for ; Tue, 26 Mar 2019 03:28:33 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A55120296 for ; Tue, 26 Mar 2019 03:28:31 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id e76so9346394ywa.9 for ; Tue, 26 Mar 2019 03:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7gyNh3wdL/SpHQ5pZH5qxnC/JbFc7z1m4qkrwFueyjM=; b=WWqTcJZEqV0g4vITawv9FBc5+HkP6DUCQGqx8+4PDKB5E78mUKp2C9lWDsIvrxtJfK ZfwGAERwqy7xQG16CHy2OCFlR0yuYI5j3sC+4Jr71CQSvI2rBNNXiQ9PqYE6O8q54MrD agltKzobJYYMI507K9UXJdoMmamhlzo9vDiNE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7gyNh3wdL/SpHQ5pZH5qxnC/JbFc7z1m4qkrwFueyjM=; b=L3O684/DpzmOjxJMoaBIdiJrx6JRHYC3lB0ZgMQojaV3wiAvtw0MjCiLcftsDdrM2g qUmEwCWB/20xGyujfUnpm4NCtItTmmLoZ31xrvEao6EW7RLgXvAwCM+R5PKKeZUmabQo S2PgCPd9RTW29Ve52HWY5XPZ0imZL+y3Frm2QAwdafAkEJCSXvL/uNZubuz/8pN3wX6K nG8wkcnvkcXReaflDDYC7vpg9PNDSLlMKAwAS0RtRLohUx50LhDxrvn3NCSHB2u/jHfD iBYPZ5c+LX9vXnvvR1FZbK56oOqApFs+PbSINfX8QiLR4u4rFd2VUxm/cZ5+8s6hl5pI /fcw== X-Gm-Message-State: APjAAAXQCQW+uD+63ZvXIG2AFg2NZ83uMfgYf3rtT+MxMxzGeO+xPoI4 y7UUMr8LBU53KWHgXgoWJNU71Q== X-Google-Smtp-Source: APXvYqw1OjCS6to3DsVjgBzm0A0tkexSxjx2yPxyKKjlOiLQW2C2TtpvZGivRBESh6lRH/glaW56Jg== X-Received: by 2002:a25:a027:: with SMTP id x36mr24001465ybh.158.1553596110515; Tue, 26 Mar 2019 03:28:30 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:e5c5:793a:fbe8:db1c? ([2001:67c:370:128:e5c5:793a:fbe8:db1c]) by smtp.gmail.com with ESMTPSA id k189sm3730084ywa.48.2019.03.26.03.28.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 03:28:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Tue, 26 Mar 2019 11:28:26 +0100 Cc: The IESG , rtcweb-chairs@ietf.org, RTCWeb IETF , draft-ietf-rtcweb-security-arch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> <2c600fc6-ca2c-2cd5-f677-6edcd0a6f3b7@nostrum.com> To: Adam Roach , Alexey Melnikov X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Alexey Melnikov's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 10:28:35 -0000 > On Mar 7, 2019, at 02:31, Sean Turner wrote: >=20 >=20 >=20 >> On Mar 7, 2019, at 04:37, Adam Roach wrote: >>=20 >> On 3/5/19 3:52 AM, Alexey Melnikov wrote: >>> My apologies for filing a procedural DISCUSS on this, but I am = looking at: >>>=20 >>> 7.5. Determining the IdP URI >>>=20 >>> 3. The path, starting with "/.well-known/idp-proxy/" and appended >>> with the IdP protocol. Note that the separator characters '/' >>> (%2F) and '\' (%5C) MUST NOT be permitted in the protocol = field, >>> lest an attacker be able to direct requests outside of the >>> controlled "/.well-known/" prefix. Query and fragment values = MAY >>> be used by including '?' or '#' characters. >>>=20 >>> "idp-proxy" is not registered in the IANA's >>> = >>> registry and this document doesn't register it either. If I missed = where this >>> is registered, please point me to the right document. If I haven't, = please >>> register it in this document. >>>=20 >>=20 >> Good catch! Thanks. >>=20 >> /a >=20 > I submitted a PR: > https://github.com/rtcweb-wg/security-arch/pull/86/files > And fired off a message to the expert list. The response from the DE: From: Mark Nottingham Date: Thu, 14 Mar 2019 14:53:35 +1100 Cc: wellknown-uri-review@ietf.org, draft-ietf-rtcweb-security-arch.all@ietf.org To: Sean Turner Looks fine to me, although it'd be better to refer to 5785bis. > On 7 Mar 2019, at 12:30 pm, Sean Turner wrote: > > Hi! We=3DE2=3D80=3D99re looking to register idp-proxy. It=3DE2=3D80=3D9= 9s used =3D in: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > We forgot to register it (Alexey caught it) and I submitted the > following PR to add it: > https://github.com/rtcweb-wg/security-arch/pull/86/files > Let us know what you think. > > spt > _______________________________________________ > wellknown-uri-review mailing list > wellknown-uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/wellknown-uri-review From nobody Tue Mar 26 06:14:48 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB336120004; Tue, 26 Mar 2019 06:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 46oS_bqmTBVa; Tue, 26 Mar 2019 06:14:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8576D120003; Tue, 26 Mar 2019 06:14:45 -0700 (PDT) Received: from dhcp-8111.meeting.ietf.org (dhcp-8111.meeting.ietf.org [31.133.129.17]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2QDEZQw043853 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Mar 2019 08:14:38 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553606081; bh=B7RF2hOmg/vP3OOvtfAJA78kVI3vpyypVz0yBfDH4IU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=pwPZs+232Ev4FqYxlWnornojjK/pt11CL5eQSUODxPtzDSIdLfruP+gJkc1C6k0KS Nk0sYN542lI9yNIkGIr6w7vT5FIZ4l3SUffDKrL3L/TEdYs95mhnAcF9togwQdGxsK 9mELKnWy02BL0O+9RLE0oTF+TtdIm2zzhBJrrsjE= To: Sean Turner , Alexey Melnikov Cc: The IESG , rtcweb-chairs@ietf.org, RTCWeb IETF , draft-ietf-rtcweb-security-arch@ietf.org References: <155177956812.24656.14146723462005957233.idtracker@ietfa.amsl.com> <2c600fc6-ca2c-2cd5-f677-6edcd0a6f3b7@nostrum.com> From: Adam Roach Message-ID: <00ab1027-848d-2535-d1cf-4c3c84079e66@nostrum.com> Date: Tue, 26 Mar 2019 14:14:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Alexey Melnikov's Discuss on draft-ietf-rtcweb-security-arch-18: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 13:14:47 -0000 Thanks, Sean. I have already given Sean this guidance, but for the benefit of others: at this point, I am imposing a moratorium on adding any new normative dependencies from Cluster 238 documents to any works in progress, regardless of their level of maturity. In this case: if RFC 5785bis completes prior to publication of rtcweb-security-arch, the RFC editor will (as a matter of practice) ask the authors whether they want to update the reference. If it does not, we do not want to block publication of the rest of the cluster on it. /a On 3/26/19 11:28, Sean Turner wrote: > >> On Mar 7, 2019, at 02:31, Sean Turner wrote: >> >> >> >>> On Mar 7, 2019, at 04:37, Adam Roach wrote: >>> >>> On 3/5/19 3:52 AM, Alexey Melnikov wrote: >>>> My apologies for filing a procedural DISCUSS on this, but I am looking at: >>>> >>>> 7.5. Determining the IdP URI >>>> >>>> 3. The path, starting with "/.well-known/idp-proxy/" and appended >>>> with the IdP protocol. Note that the separator characters '/' >>>> (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, >>>> lest an attacker be able to direct requests outside of the >>>> controlled "/.well-known/" prefix. Query and fragment values MAY >>>> be used by including '?' or '#' characters. >>>> >>>> "idp-proxy" is not registered in the IANA's >>>> >>>> registry and this document doesn't register it either. If I missed where this >>>> is registered, please point me to the right document. If I haven't, please >>>> register it in this document. >>>> >>> Good catch! Thanks. >>> >>> /a >> I submitted a PR: >> https://github.com/rtcweb-wg/security-arch/pull/86/files >> And fired off a message to the expert list. > The response from the DE: > > From: Mark Nottingham > Date: Thu, 14 Mar 2019 14:53:35 +1100 > Cc: wellknown-uri-review@ietf.org, > draft-ietf-rtcweb-security-arch.all@ietf.org > To: Sean Turner > > Looks fine to me, although it'd be better to refer to 5785bis. > >> On 7 Mar 2019, at 12:30 pm, Sean Turner wrote: >> >> Hi! We=E2=80=99re looking to register idp-proxy. It=E2=80=99s used = > in: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ >> We forgot to register it (Alexey caught it) and I submitted the >> following PR to add it: >> https://github.com/rtcweb-wg/security-arch/pull/86/files >> Let us know what you think. >> >> spt >> _______________________________________________ >> wellknown-uri-review mailing list >> wellknown-uri-review@ietf.org >> https://www.ietf.org/mailman/listinfo/wellknown-uri-review From nobody Wed Mar 27 03:06:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79215120293 for ; Wed, 27 Mar 2019 03:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 hOk60HTdVA7N for ; Wed, 27 Mar 2019 03:06:25 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF6212028F for ; Wed, 27 Mar 2019 03:06:24 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id d132so12049018ywa.2 for ; Wed, 27 Mar 2019 03:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dU2Tgdc1QFbt6qbAyRW0KftqrqqnFXxeW+QehCOnd1Q=; b=ABpmYjTe59Gk7Nr0c9oWHftJxrcPHIui7farwU1fzc7bhklQFIKfVsgQOps6VPKHqy tQJxhtshGL9U/lBHyUKAwHivPJ6wrcnwdaPcxDVYSbdtJfr3cKrkcEf8TTPzltkL7LF0 dsVt9+7uGLUtFSWDPlXJEl1f1+pAcuCyQvliM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dU2Tgdc1QFbt6qbAyRW0KftqrqqnFXxeW+QehCOnd1Q=; b=jUsCXp5DncE0rCeJmlagGPgweKgrFVpkbxfsbaEiftDdV2/Flin7+lCBjDwj6dppPL ah4FD3UauguaJD1MzpGKrVA4XZ3EVMSOEXddtoyADAua+beuLncHiXCFyrCrD03ittE8 /ia1XD1CH+7LqfyYFVe/MP5jFl/cljKyD0wF4UuQUJ0fieF11j1rhEcO1WFuxkWx7Ofw wDcgQZvngQbSSKWFVZ9GMC9cx9fqtFV/Rq01jjUWpJwpCiraAwN/8BBBFMOS210QHYBA mL0cAsORM2YP/3L6T+qtwVDfn4ldRrOi7HPvODIKXiwQ2uKmmswh3QRKFm9JdAic034Y dNTg== X-Gm-Message-State: APjAAAUmxYFe4e8a2cuaE1iYYskC5rDeHZioVaLRKbrfh9pratsQzN5i gnNBHLmNmRgUT4lt4lCfW5dlvg== X-Google-Smtp-Source: APXvYqwFVsCsm2VkJlzwnQ/+1WnyNHbAf3u8JQS3XHti1RSlDwrfUIWNFF5F+lxyupaTOPhlCxanFQ== X-Received: by 2002:a0d:db91:: with SMTP id d139mr30300404ywe.418.1553681184065; Wed, 27 Mar 2019 03:06:24 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:1468:25d2:df6d:be9d? ([2001:67c:370:128:1468:25d2:df6d:be9d]) by smtp.gmail.com with ESMTPSA id 77sm7692805ywo.72.2019.03.27.03.06.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 03:06:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2019 11:06:20 +0100 Cc: The IESG , draft-ietf-rtcweb-security-arch@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0507911D-76A2-4D4F-92BC-6026A14F8305@sn3rd.com> References: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 10:06:28 -0000 > On Mar 5, 2019, at 13:45, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-security-arch-18: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Update: Ignore my comment about t=3D vs c=3D0. I had my order crossed; = it is > correct in the example. >=20 > I'm balloting "yes", but have a few minor comments and editorial = comments: >=20 > =C2=A71: > - (nit) The first sentence will not age well; I gather RTCWEB will = close before > long. (also The WG acronym is RTCWEB, not WebRTC. Or are you talking = about the > W3C?) Fixed in the following PR: https://github.com/rtcweb-wg/security-arch/pull/88 > - (nit) Figure 2: It seems a bit weird to have XMPP here, but never = mentioned > in the text. At least, please expand the abbreviation somwhere. (It = also shows > up in figure 4.) Fixed in the above mentioned PR. > (nit) =C2=A73.1, first bullet: While I don't normally object (beyond = nose holding, > anyway) to the use of first person in RFCs, it seems an odd choice for = this > sentence. I assume "we" in this sentence does not refer to the the = author or > the WG. I am hoping the RFC editor can help here. =E2=80=9Cwe=E2=80=9D is used = a lot in this draft. > =C2=A74.1: > (nit) - '... button next to Bob=E2=80=99s name which says "Call".': > s/which/that fixed in the above PR > - "The calling site will also provide some user interface > element (e.g., a button) to allow Bob to answer the call, though this > is most likely not part of the trusted UI." >=20 > This is the first mention of "trusted UI". It would be helpful to = elaborate on > that prior to this mention. Fair enough, but there is draft-ietf-rtcweb-security that you also had = to read and there=E2=80=99s a lot of discussion there about browsers, = sandboxing, etc. > =C2=A75.1.4: > - "In this > case, the established identity SHOULD be applied to existing DTLS > connections as well as new connections established using one of those > fingerprints." >=20 > Applied by the recipient? (consider active voice). Also, why not MUST? = Don't > unexpected things happen if the recipient doesn't do this? will get back to you on this one.=20 > =C2=A76.2: > - "Because HTTP origins cannot be securely established against network > attackers, implementations MUST NOT allow the setting of permanent > access permissions for HTTP origins. Implementations MUST refuse all > permissions grants for HTTP origins." >=20 > (nit-ish) - The MUST NOT seems non-constraining considering the last = sentence. > Or am I reading that sentence wrong? will get back to you on this one. > (nit) - .E.g., "Call customerservice@ford.com"' : sentence fragment. > (nit) - ".. unlikely that browsers would have an X.509 certificate..." = : Plural > disagreement (assuming the browsers do not share 1 cert). fixed in the above PR > (maybe nit) - "Clients MAY permit the formation of data channels = without any > direct user approval." Is the switch from talking about "the browser" = to > "Clients" intentional? fixed in the above PR > =C2=A76.4: > (nit) - "Note that these requirements are NOT intended..." > "NOT" in all caps is likely to be confused with 2119/8174 language. fixed in the above PR > =C2=A76.5: > (nit) - "Implementations MUST implement SRTP [RFC3711]. = Implementations MUST > implement DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP > keying. Implementations MUST implement [RFC8261]." >=20 > Thank you for using the citation style that doesn't assume everyone = has > memorized the RFC numbers. But why not do the same for 8261? fixed in the above PR > =C2=A77.2: > (nit) - First paragraph: Can there be a citation for the W3C API spec? There might be, but if you get=20 > (My bad, the draft is correct. Comment removed.) =C2=A77.1.4, SDP = example: >=20 > (nit) =C2=A711: The first sentence is a fragment. It is. > =C2=A713.1 (normative references) >=20 > (nit) - There's a reference to RFC 5234, but it is not cited in the = text. Yep meant to delete that now it=E2=80=99s gone see the earlier PR. > - Is there a reason to reference 5246 rather than 8446, which = obsoleted it? 1.2 is required so we=E2=80=99re pointing there. > =C2=A713.2: > - seems like the jsep reference should be normative. Well the reference comes from =E2=80=9CNote=E2=80=9D sentence. Since = you=E2=80=99re really only doing this drfat And, you=E2=80=99re really = only doing this draft because you=E2=80=99re doing the JSEP draft= From nobody Thu Mar 28 06:51:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8136812045F for ; Thu, 28 Mar 2019 06:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 eQppGs6l-qlQ for ; Thu, 28 Mar 2019 06:51:05 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95D2120466 for ; Thu, 28 Mar 2019 06:51:04 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id l15so14661461ywe.8 for ; Thu, 28 Mar 2019 06:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ywUsfU4RPBymLHY1OPmxQws5knH5mlzcvGMayw9AwMI=; b=NCIW58l/2fhnLizPslULi8QHL4dPDYCh/3FIAwz33ni3Wv7drintfRj2TwyG2ErpFc b1Ya2gTbQtd/VOEJdmMuldAaz5vt99KflnMn4ztSQ0/ar9MKwUK6sl8sqRFkSch5YyPy reoMbV4DcRald+qakS/I7FoXqFjbyKgS3PGzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ywUsfU4RPBymLHY1OPmxQws5knH5mlzcvGMayw9AwMI=; b=c/4nF8EWNQc3SAR0qwG5FQdN/ev4hhs3GywoOfnIgyqulEinP6yHpWZIBrmzZYEzbw 2+DWa0cYJmuQxL5GRqYTC70I1mUYM0vIhFr2l9w6zGcL+vT0n5xmC/BrsgH3FxYNOzn4 lx4ztDTAti5Q5cQ2SF6dM1m7hvYpiqnjSbtQG1N+h9M+BUweq3JxTDudjKOeZUBOdqJj LXUmH+fsXvlr1z105JoIVV5bhjPpKB7pDRapBkqiTFeSAJV2VBJNeLUdJxvfZ1m/hwJB TOfY8XbXq5NJ7lC+Zrl/MM6oQKgv9RXvkCPw0lFXB+UFwqgpffudNwnlQOo20Ml95cSG pfOQ== X-Gm-Message-State: APjAAAVmjBOMwy1SIMucB4L3uarEJqqoiDD7f5rBYySnTJkWWZoyxCAF 0BH8dYGyh8JVAC+LL6XsjjvTwQ== X-Google-Smtp-Source: APXvYqzWFtIEkQBqFbvIT4RjeO9xBVBGo+O0wY0B9Dsxgc05cJzkS9Gwm06+fcrsTfLwQ4pI1ziOMA== X-Received: by 2002:a81:f85:: with SMTP id 127mr37430749ywp.348.1553781064173; Thu, 28 Mar 2019 06:51:04 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:c1ec:6bbe:60d6:361d? ([2001:67c:370:128:c1ec:6bbe:60d6:361d]) by smtp.gmail.com with ESMTPSA id d196sm8977458ywh.105.2019.03.28.06.51.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 06:51:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <0507911D-76A2-4D4F-92BC-6026A14F8305@sn3rd.com> Date: Thu, 28 Mar 2019 14:51:00 +0100 Cc: The IESG , draft-ietf-rtcweb-security-arch@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19241E5A-1DEA-443A-8130-F3F0F7431156@sn3rd.com> References: <155176110055.5301.9102355161357963697.idtracker@ietfa.amsl.com> <0507911D-76A2-4D4F-92BC-6026A14F8305@sn3rd.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-security-arch-18: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 13:51:11 -0000 > On Mar 27, 2019, at 11:06, Sean Turner wrote: >=20 >=20 >=20 >> On Mar 5, 2019, at 13:45, Ben Campbell wrote: >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-rtcweb-security-arch-18: Yes >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >> =C2=A75.1.4: >> - "In this >> case, the established identity SHOULD be applied to existing DTLS >> connections as well as new connections established using one of those >> fingerprints." >>=20 >> Applied by the recipient? (consider active voice). Also, why not = MUST? Don't >> unexpected things happen if the recipient doesn't do this? >=20 > will get back to you on this one.=20 MT seems to think we can just drop SHOULD and r/SHOULD/can I reflected that in the PR. >> =C2=A76.2: >> - "Because HTTP origins cannot be securely established against = network >> attackers, implementations MUST NOT allow the setting of permanent >> access permissions for HTTP origins. Implementations MUST refuse all >> permissions grants for HTTP origins." >>=20 >> (nit-ish) - The MUST NOT seems non-constraining considering the last = sentence. >> Or am I reading that sentence wrong? >=20 > will get back to you on this one. Chopped it to: Because HTTP origins cannot be securely established against network attackers, implementations MUSTrefuse all permissions grants for HTTP origins. From nobody Fri Mar 29 01:32:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211BC120257 for ; Fri, 29 Mar 2019 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 RqoLZnt1wRR0 for ; Fri, 29 Mar 2019 01:32:40 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on060a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::60a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE01E120437 for ; Fri, 29 Mar 2019 01:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=82TByqpmuMX0HoMjWy/s0S5WWS/lXILrlNIC2di7uRk=; b=QboWTm6kBGsIntoWe+Vr44kHbLPxlqqx6hbyN6lHLDWXTq4RjgYSiokPgMcwoSnDfTzVt78iW7csAqLQTDMs0ePVhyQdj4JKed18K1vkYZHG0alEUrbb7H+HiYa2O60qKeg46GIrwsWITNBFxqOO9KNm/geH95xH3gldwffuDBI= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2329.eurprd07.prod.outlook.com (10.168.127.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 29 Mar 2019 08:32:37 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1771.006; Fri, 29 Mar 2019 08:32:37 +0000 From: Magnus Westerlund To: "rtcweb@ietf.org" Thread-Topic: [payload] Updates on FLEX FEC (ver -19) Thread-Index: AdTlkiuoQvnOaQJpTdKMsfXe7HImOA== Date: Fri, 29 Mar 2019 08:32:37 +0000 Message-ID: References: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [129.192.74.4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5724cdc-a18a-4fc1-f2fa-08d6b4211997 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2329; x-ms-traffictypediagnostic: HE1PR0701MB2329: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(366004)(39860400002)(346002)(199004)(189003)(25786009)(6436002)(106356001)(316002)(105586002)(186003)(966005)(2906002)(5640700003)(33656002)(53936002)(8936002)(5660300002)(15650500001)(6916009)(236005)(3846002)(76176011)(14454004)(71190400001)(6116002)(6306002)(2351001)(55016002)(2473003)(71200400001)(54896002)(9686003)(446003)(14444005)(99286004)(256004)(68736007)(478600001)(606006)(476003)(74316002)(229853002)(1730700003)(2501003)(7696005)(44832011)(97736004)(8676002)(86362001)(52536014)(81166006)(66066001)(81156014)(6506007)(102836004)(486006)(26005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2329; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6l0gbDXZDLcPuccKgkyVwrPyXGfWgIUk4TOwyA1G28d9VJcO/cezLvcrUeM+f0VnN2lQC9VStZ7t5vFpWtpNIoybdI/+6v9h682abMdou3SJ8f5jXUxW0oUjpoe9p3AsVy9beyaZwM+sKNZ7yNQgHnJ2SiphvDRctGy1kgdkkIJKQi3GEV3XM51NT8SL2/3nWtxmDI7JTdE7L6TZRipBlrXMtqpUwsskFTpdEZJcxq0MUIG0mHcd1V6vx/YEr76S1TGc8JG2dL2UTDicwp98B6JWrmWyEX6Hv7+5tXhWXdVVUxqYAjsfOPQZ4aQH54YaZQWEI+Dxf5/7YhE8Cxqb8vRmdAkBJm7q18X72ooqLc8Dqc5ts2Tc02n2NakGstyGj3vmBNX2+sXbTpn+h6RgfhNqPGu03yGA1shyyvI7yDA= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522550248ED1AA0500F3791955A0HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5724cdc-a18a-4fc1-f2fa-08d6b4211997 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 08:32:37.4361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2329 Archived-At: Subject: [rtcweb] Fwd: [payload] Updates on FLEX FEC (ver -19) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 08:32:50 -0000 --_000_HE1PR0701MB2522550248ED1AA0500F3791955A0HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RTCWeb, I want to call to attention this proposed changes to the FlexFec format. Th= ere are some implications here. With the removal of the ToP option, if one = supports FlexFec and negotiate it, one should use this format for Retransmi= ssion, not only FEC. From my perspective this shifts some assumptions from = the FEC and RTP usage drafts. Cheers Magnus -------- Forwarded Message -------- Subject: [payload] Updates on FLEX FEC (ver -19) Date: Thu, 28 Mar 2019 19:19:31 +0100 From: Giridhar Mandyam To: payload@ietf.org Dear Payload WG, After offline discussion with the editors and reviewers (special thanks to = Bernard Aboba), we have decided that the spec needed to be slightly modifie= d. Version -19 contains the following changes: a) Recommendation against negotiation of RTP RTX when FLEX FEC is used. A n= ew section 1.1.7 on the use of FLEX FEC retransmissions has been added to i= ndicate as such. b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields). T= his means that the sender can send any FEC configuration (as indicated by t= he FEC header) as long as it stays consistent with the mandatory SDP parame= ters (rate and repair window). Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the prim= ary impacted sections. We believe this will greatly simplify SDP O/A and wh= ile retaining the "flexibility" of FLEX FEC to adapt FEC repair data on a p= acket-by-packet basis. - Note that L and D cannot be larger than 255, respe= ctively. As we gain implementation experience, if we decide that 255 is not= sufficient then it could be possible to extend the corresponding header fi= elds in the future. Currently there are header values that are reserved (R= =3DF=3D1 and L=3DD=3D0) that could be used to indicate the use of an extend= ed L and D field, as an example of one way to implement extended fields for= L and D. c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering erro= rs in the abstract procedure for grouping of source packets using their RTP= sequence numbers. d) Accounting for the remaining nit's in Benjamin Kaduk's last review. e) Explicitly defining "FLEX FEC" in the abstract. Please provide any feedback within 7 days of the sending of this notificati= on. Thank you, -The Editors of FLEX FEC _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_HE1PR0701MB2522550248ED1AA0500F3791955A0HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RTCWeb,

I want to call to attention this proposed changes to the FlexFec format.= There are some implications here. With the removal of the ToP option, if o= ne supports FlexFec and negotiate it, one should use this format for Retran= smission, not only FEC. From my perspective this shifts some assumptions from the FEC and RTP usage drafts= .

Cheers

Magnus


-------- Forwarded Message --------
Subject: [payload] Updates on FLEX FEC (ver -19)
Date: Thu, 28 Mar 2019 19:19:31 +0100
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: = payload@ietf.org <pay= load@ietf.org>


Dear Payload WG,

After offline discussion with the editors and reviewers (special thanks to = Bernard Aboba), we have decided that the spec needed to be slightly modifie= d. Version -19 contains the following changes:

a) Recommendation against negotiation of RTP RTX when FLEX FEC is used. A n= ew section 1.1.7 on the use of FLEX FEC retransmissions has been added to i= ndicate as such.

b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields). T= his means that the sender can send any FEC configuration (as indicated by t= he FEC header) as long as it stays consistent with the mandatory SDP parame= ters (rate and repair window). Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the primary impacted sections. We believe t= his will greatly simplify SDP O/A and while retaining the "flexibility= " of FLEX FEC to adapt FEC repair data on a packet-by-packet basis. - = Note that L and D cannot be larger than 255, respectively. As we gain implementation experience, if we decide that 255 = is not sufficient then it could be possible to extend the corresponding hea= der fields in the future. Currently there are header values that are reserv= ed (R=3DF=3D1 and L=3DD=3D0) that could be used to indicate the use of an extended L and D field, as an example of= one way to implement extended fields for L and D.

c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering erro= rs in the abstract procedure for grouping of source packets using their RTP= sequence numbers.

d) Accounting for the remaining nit's in Benjamin Kaduk's last review.

e) Explicitly defining "FLEX FEC" in the abstract.

Please provide any feedback within 7 days of the sending of this notificati= on.

Thank you,

-The Editors of FLEX FEC


_______________________________________________
payload mailing list
payl= oad@ietf.org
https://www.ietf.org/mailman/listinfo/payload

--_000_HE1PR0701MB2522550248ED1AA0500F3791955A0HE1PR0701MB2522_--