From nobody Tue Apr 9 11:00: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 6CB911200EA for ; Tue, 9 Apr 2019 10:59:59 -0700 (PDT) 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 8ENmQqNIMYwK for ; Tue, 9 Apr 2019 10:59:57 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 941FB1203A6 for ; Tue, 9 Apr 2019 10:59:56 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id u65so6461704itc.2 for ; Tue, 09 Apr 2019 10:59:56 -0700 (PDT) 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=pv1z+0nA7uYEsfCFM/wXZwjHVNLROyST65lv23qk2W8=; b=Xpp7KU5P7HCVbjjIfeVIuu5JPebmuKk8nvSqbfwErxJLoMTTa7h07XYFQeooFDEbL/ dsT696rYUIIB/X73xdJbZO6IN0TP/h0J3rvjhOSMiE5S3WmggQbfcu39Yv7z5Pithvzw NxsCozQxg+amL6rD08wdYVrR2EqVLGJ2379BzHNzFxeLTJODuaCao3b0O2A3bRnrtMQi 85k1EvLfHWy+9F3gWOyuOZ6cAukatSoMqrM0CnWgX73v07RIVQKzI9NQ2TBieJA/E0kF YFpXBvxRZnJsH5dgFN7EArzFBg+dGKJbJHDxdu0JcVUW00ujm59dvChLYUtpLAAaZVI2 izOQ== 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=pv1z+0nA7uYEsfCFM/wXZwjHVNLROyST65lv23qk2W8=; b=HwroofQgvS/euG4ETEDZgE+ucjZ6QQ1xkAo1oK3wnkkgfjOFkvGHnqK0L91u4F1gF4 Iib1hfAsH4Dw3dIYfXDBM7ucq7qFOtAjXF7L+Fy0ocqh22KlpHVwILl/CHBcGn9MiQie ZMD2AqNBY+YW5bF9LA1DLh0tqzEbqUTrO7w4H/K/xzyegBdlgOobFDiwWqrMJBkiUjzm bkOjJqb0oKq6EZrnA98mzWfyOr1s73aYVJy/lFgmjmRlGfO0C23Rpq+kexLhwYYc2+mR Gyy5OtNdMTshKPHFt0AFnOMcYmX/pc45uXeiGcC0NUhWfSVm25mEHvNXcDFvsaPfM8g5 I9sg== X-Gm-Message-State: APjAAAWonheQ051ITWAPMu6gmA8+OUhGE0WjXPTMm3wmQBB2Z38Bivmo vdvkxUxuueU3x5GxRzRmv33BSsC4EDSuOsafPhZCvy1g X-Google-Smtp-Source: APXvYqw7Hf0CUyOZEYcvgl+3wLwdgpruX8dKLkLj6to7uHXZzQF/atI7gyLjEtbHxZxCOIkAjuqCUkvt/biE16exkks= X-Received: by 2002:a24:4161:: with SMTP id x94mr26510567ita.83.1554832795454; Tue, 09 Apr 2019 10:59:55 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Tue, 9 Apr 2019 10:59:29 -0700 Message-ID: To: RTCWeb IETF , Sean Turner , Adam Roach Content-Type: multipart/alternative; boundary="0000000000007551b605861cb835" Archived-At: Subject: [rtcweb] Security-arch IdP determination issue/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, 09 Apr 2019 18:00:00 -0000 --0000000000007551b605861cb835 Content-Type: text/plain; charset="UTF-8" In section 7.5 of the Security-arch draft, the document says: Authority: The authority [RFC3986 ] at which the IdP's service is hosted. Note that this may include a non-default port or a userinfo component, but neither will be available in a certificate verifying the site. Benjamin Kaduk raised a DISCUSS on this: 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. > Given that we discover this via a .well-known location which is meant to be deterministic, I went looking for the more general .well-known advice on this topic. Turns out that the updated version in 578bis has this: Typically, applications will use the default port > for the given scheme; if an alternative port is > used, it MUST be explicitly specified by the > application in question. > Obviously, our doc predates 5785bis, but given the discuss and that advice, I think the right thing to do here is to drop the ability to have a non-default port or to specify an alternate port. Is there anyone currently using this with a non-default port? Any objections to dropping this or preferences for specifying an alternate port? regards, Ted --0000000000007551b605861cb835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In section = 7.5 of the Security-arch draft, the document says:

Authority:  The authority [RFC3986] at which the IdP's servi=
ce is
      hosted.  Note that this may include a non-default port or a
      userinfo component, but neither will be available in a certificate
      verifying the site.

Benjamin Kaduk raised a DISCUSS on this:=
I'm = a bit unclear about how the port in the
IdP URI's Authority (Sectio= n 7.5) would get
discovered. If it can be remotely supplied,
there= may be risks in just trusting blindly
whatever value is received.
<= /blockquote>

Given that we discover this via a .we= ll-known location which is meant to be deterministic, I went looking for th= e more general .well-known advice on this topic.=C2=A0 Turns out that the u= pdated version in 578bis has this:

<= 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">Typically, applications wi= ll use the default port
for the given scheme; if an alternative port is=
used, it MUST be explicitly specified by the
application in questi= on.

Obviously, our doc predat= es 5785bis, but given the discuss and that advice, I think the right thing = to do here is to drop the ability to have a non-default port or to specify = an alternate port.

Is there anyone currently using= this with a non-default port?

Any objections to d= ropping this or preferences for specifying an alternate port?
regards,

Ted
--0000000000007551b605861cb835-- From nobody Tue Apr 9 14:17:54 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 1C791120232 for ; Tue, 9 Apr 2019 14:17:53 -0700 (PDT) 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=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 DFUOG6Euq7eV for ; Tue, 9 Apr 2019 14:17:51 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 2CAC7120456 for ; Tue, 9 Apr 2019 14:17:51 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id j26so129265pgl.5 for ; Tue, 09 Apr 2019 14:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yM66VPLk9goRuGFKqKmCsaxAv3HCodG5SsJkxoVAzGU=; b=BE4VDv0lIc1EWED5tOiFcgd57mMcQmqOMO0IlwFApK5Wv3/UAwuKnXlE7OlH82ArYd x7k17LU3ni7m3kcJym9E0MZY3282ZaoSWgDeoJEUeS26COczCuQ//V3aNywWTTQzxDJG 4xtNerkBcayaSMihEzDvvbOO2D0RfmIVmYAxY= 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=yM66VPLk9goRuGFKqKmCsaxAv3HCodG5SsJkxoVAzGU=; b=tpY6D0GHs+k7xMNXFF1pU3N/SDjRT+z1o9avvnSTTFNiJu2gGYNYFb2w6S+x9fro/i imiEG2SoTHDrGuFBG6hx+Y3tAingI2122SMXYQly3+jgQJOoC84d8g52eIrWVD5MB6mz A03LmnRcMkbzEtDpFJ10jCk7RSNLDaZflP735oBRKlbIbUi3JnE79Ihuq4sy9JEz+kBp 13eWLwauMoll1dsdD6UCwex5lJRVdw0W4dsV1uAmtsLmOICIwEHmUnmvQW3v97k6uBdI 7ScIUx5PDoFlEMXhdh2G4zZNktHetnrmWEMoZ1WlMk0e0Q5yl6E5mil88rUWMBTzAy7Q Tdkw== X-Gm-Message-State: APjAAAVZro1jtzvERyqJE/u1F+amGb6ErDeH0HGRIsQa9YPV89vgxG9J +udwroltGmTLNT+wN4G6U+wVLw== X-Google-Smtp-Source: APXvYqwlf4O/v+kxf01EzaGegT1M+qAKiyxAI8crUf8h1H+PpKOUldxtBouhcY+LbqtK6D7x0FBvUQ== X-Received: by 2002:a65:64d3:: with SMTP id t19mr36780236pgv.57.1554844670565; Tue, 09 Apr 2019 14:17:50 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:973:4d4c:aa24:f66c? ([2601:647:4600:3f31:973:4d4c:aa24:f66c]) by smtp.gmail.com with ESMTPSA id y37sm48144774pgk.78.2019.04.09.14.17.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 14:17:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Nils Ohlmeier In-Reply-To: Date: Tue, 9 Apr 2019 14:17:47 -0700 Cc: RTCWeb IETF , Sean Turner , Adam Roach Content-Transfer-Encoding: quoted-printable Message-Id: <17C6C0E9-4748-44D8-A8EE-CEA9F9A6ADB4@mozilla.com> References: To: Ted Hardie X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [rtcweb] Security-arch IdP determination issue/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, 09 Apr 2019 21:17:53 -0000 > On 9Apr, 2019, at 10:59, Ted Hardie wrote: >=20 > Obviously, our doc predates 5785bis, but given the discuss and that = advice, I think the right thing to do here is to drop the ability to = have a non-default port or to specify an alternate port. >=20 > Is there anyone currently using this with a non-default port? >=20 > Any objections to dropping this or preferences for specifying an = alternate port? I=E2=80=99m aware of small deployments using this. I don=E2=80=99t = recall if they are using default ports. But in general no objection against specifying an alternate port. Best Nils Ohlmeier= From nobody Thu Apr 11 03:30: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 4EE1B1204BF for ; Thu, 11 Apr 2019 03:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 jfl-UwZICfEz for ; Thu, 11 Apr 2019 03:30:18 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0900212011D for ; Thu, 11 Apr 2019 03:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1008E7C05B1; Thu, 11 Apr 2019 12:30:16 +0200 (CEST) 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 BCGFk-DwIezp; Thu, 11 Apr 2019 12:30:14 +0200 (CEST) Received: from hta-rhino.sto.corp.google.com (unknown [IPv6:2620:0:1043:12:b37c:814:7aec:8f6]) by mork.alvestrand.no (Postfix) with ESMTPSA id DADF47C0566; Thu, 11 Apr 2019 12:30:13 +0200 (CEST) References: <155497849785.12672.2988988646899076493.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" , "public-webrtc@w3.org" From: Harald Alvestrand Openpgp: preference=signencrypt X-Forwarded-Message-Id: <155497849785.12672.2988988646899076493.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 11 Apr 2019 12:30:13 +0200 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: <155497849785.12672.2988988646899076493.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E1AA337D5240D29D152BA485" Content-Language: en-US Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt 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, 11 Apr 2019 10:30:21 -0000 This is a multi-part message in MIME format. --------------E1AA337D5240D29D152BA485 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I have made a proposal. Note: This is strictly a *personal* contribution. Do not attach undue authority to it. Harald -------- Forwarded Message -------- Subject: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt Date: Thu, 11 Apr 2019 03:28:17 -0700 From: internet-drafts@ietf.org To: Harald Alvestrand A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-alvestrand-mmusic-simulcast-ssrc Revision: 00 Title: Using SSRC with WebRTC Simulcast Document date: 2019-04-11 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-00.txt Status: https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/ Htmlized: https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc Abstract: This document describes a convention for sending "a=ssrc" attributes in SDP together with "a=simulcast" attributes. This allows SFUs that need SSRC information to have this info easily accessible. Given that it is intended as an interim measure, it does not aim for being published as an RFC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------E1AA337D5240D29D152BA485 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I have made a proposal.

Note: This is strictly a *personal* contribution. Do not attach undue authority to it.


Harald



-------- Forwarded Message --------
Subject: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt
Date: Thu, 11 Apr 2019 03:28:17 -0700
From: internet-drafts@ietf.org
To: Harald Alvestrand <harald@alvestrand.no>



A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name: draft-alvestrand-mmusic-simulcast-ssrc
Revision: 00
Title: Using SSRC with WebRTC Simulcast
Document date: 2019-04-11
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-00.txt
Status: https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/
Htmlized: https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc


Abstract:
This document describes a convention for sending "a=ssrc" attributes
in SDP together with "a=simulcast" attributes. This allows SFUs that
need SSRC information to have this info easily accessible.

Given that it is intended as an interim measure, it does not aim for
being published as an RFC.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------E1AA337D5240D29D152BA485-- From nobody Thu Apr 11 07:45:09 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 12B481202D7 for ; Thu, 11 Apr 2019 07:45:08 -0700 (PDT) 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 yuseh1_Fa7ul for ; Thu, 11 Apr 2019 07:45:04 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 7EA2C1200B8 for ; Thu, 11 Apr 2019 07:45:04 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id w3so5433175edu.10 for ; Thu, 11 Apr 2019 07:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=7VSZh6UcP76pm8S8oxT8Eo8NtQ3/Z4MFx5s4VtlDWnY=; b=VvpcvcfbgHwG0G20m3ZXpjWiYukyGcwWToEvunZkfIC0yFsi2DwtS74KTrf4Oo+yVR ax2CzjUFCHxweY6un9KvG8NsEIyBTkCFDeqK7RYubExW0Oa634edEbfylcy75PsxQTwf VovmTTp3cV4JOopI0MXtWWDx6Kozsyq9dKkJp82PGeJhmIrN+Wmu9oLaQP0jADXO/SXn M7QdbD9MfJNqmeGUA/z46RARuR086fXaOcNMphRwy2HCUFLg7aTIGqFP4CYHQGfINxIE 9AbN7m8mkULnUt+DQgJ93Ykiu6Iqb+rqdVqZpKSpjG4pyxHGCrN40x6BoKTKdVMypsol xg/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7VSZh6UcP76pm8S8oxT8Eo8NtQ3/Z4MFx5s4VtlDWnY=; b=bEqsh4uXvxhR5thrrH7pUbxCQyRKZCUJrKDiwCJWQ42/T6vBsLc0A4L1hIPkvn2zDK +dIdf59gBjWgVVTf8cgjtzLlRgG3OIc1k/iHmCkcgpf9tleurSFdNUEuZCyCCk1euEXw TgjhChLU4pSclMHTwfBOpjxngmIxHZqQwDUoIXVq1Vd2K3f/09hTaI5UKUoy+l8fbjvr 1TdMeoNf30T2Y21ihxTuzI+k5H0erFg0ynY1u3dWHy8MgXInklrCNkSFTlutMfvdxCfp neuA8LSf9UbkPxZop7uPINOszENSbGc+5WEO4nV8OkMrBFZbhdb0po77ohEtT7oPVLZM vJfg== X-Gm-Message-State: APjAAAXk/Qc+8VIx66m+eZF1NzVwFjRQqTZQOZ/xH/UYOHt6jQcCch9K o7HEk0kBmTupSLLlk7gyjuVtE9z/ X-Google-Smtp-Source: APXvYqwZLyjGr3E9mcrDGkwQbddRzV90/YlJ39uX6Gb8ZZvSSx8hleq/BpQzivFX0wKC1g5IiYyAxg== X-Received: by 2002:a50:a3b1:: with SMTP id s46mr30305405edb.99.1554993902864; Thu, 11 Apr 2019 07:45:02 -0700 (PDT) Received: from [10.255.0.170] (82.red-80-38-205.staticip.rima-tde.net. [80.38.205.82]) by smtp.googlemail.com with ESMTPSA id w3sm4455832edq.33.2019.04.11.07.45.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 07:45:01 -0700 (PDT) To: rtcweb@ietf.org References: <155497849785.12672.2988988646899076493.idtracker@ietfa.amsl.com> From: Sergio Garcia Murillo Message-ID: Date: Thu, 11 Apr 2019 16:45:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5F67EE26E71BF9CD44BF5712" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt 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, 11 Apr 2019 14:45:08 -0000 This is a multi-part message in MIME format. --------------5F67EE26E71BF9CD44BF5712 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Harald, Just one quick comment in case you find it useful. I have been using this format for signaling both rids and ssrcs (and association between both): a=simulcast:send c;b;a a=rid:c send ssrc=2564467881 a=rid:b send ssrc=1 a=rid:a send ssrc=3 a=ssrc-group:FID 2564467881 32941417 a=ssrc-group:FID 1 2 a=ssrc-group:FID 3 4 a=ssrc:2564467881 cname:eRUkt2XxiSTlri77 a=ssrc:32941417 cname:eRUkt2XxiSTlri77 a=ssrc:1 cname:eRUkt2XxiSTlri77 a=ssrc:2 cname:eRUkt2XxiSTlri77 a=ssrc:3 cname:eRUkt2XxiSTlri77 a=ssrc:4 cname:eRUkt2XxiSTlri77 Note that the ssrc param (as a rid-param-other) in rid attribute is valid per the ABNF in: https://tools.ietf.org/html/draft-ietf-mmusic-rid-15#page-19  rid-param = rid-width-param                        / rid-height-param                        / rid-fps-param                        / rid-fs-param                        / rid-br-param                        / rid-pps-param                        / rid-bpp-param                        / rid-depend-param                        / rid-param-other  rid-param-other   = 1*(alpha-numeric / "-") [ "=" param-val ]  param-val         = *( %x20-58 / %x60-7E ) ; Any printable character except semicolon IMHO the usage of FID for signaling the "SIM" group is not a good choice as it is being used today for signaling the rtx association, and should be still present in the SDP if not using rids/rrids (which I understand that is the goal of the draft) Best regards Sergio On 11/04/2019 12:30, Harald Alvestrand wrote: > > I have made a proposal. > > Note: This is strictly a *personal* contribution. Do not attach undue > authority to it. > > > Harald > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-alvestrand-mmusic-simulcast-ssrc-00.txt > Date: Thu, 11 Apr 2019 03:28:17 -0700 > From: internet-drafts@ietf.org > To: Harald Alvestrand > > > > > A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-00.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Name: draft-alvestrand-mmusic-simulcast-ssrc > Revision: 00 > Title: Using SSRC with WebRTC Simulcast > Document date: 2019-04-11 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-00.txt > Status: > https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/ > Htmlized: > https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc > > > Abstract: > This document describes a convention for sending "a=ssrc" attributes > in SDP together with "a=simulcast" attributes. This allows SFUs that > need SSRC information to have this info easily accessible. > > Given that it is intended as an interim measure, it does not aim for > being published as an RFC. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------5F67EE26E71BF9CD44BF5712 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Harald,

Just one quick comment in case you find it useful.

I have been using this format for signaling both rids and ssrcs (and association between both):
a=simulcast:send c;b;a
a=rid:c send ssrc=2564467881
a=rid:b send ssrc=1
a=rid:a send ssrc=3
a=ssrc-group:FID 2564467881 32941417
a=ssrc-group:FID 1 2
a=ssrc-group:FID 3 4
a=ssrc:2564467881 cname:eRUkt2XxiSTlri77
a=ssrc:32941417 cname:eRUkt2XxiSTlri77
a=ssrc:1 cname:eRUkt2XxiSTlri77
a=ssrc:2 cname:eRUkt2XxiSTlri77
a=ssrc:3 cname:eRUkt2XxiSTlri77
a=ssrc:4 cname:eRUkt2XxiSTlri77
 
Note that the ssrc param (as a rid-param-other) in rid attribute is valid per the ABNF in:

https://tools.ietf.org/html/draft-ietf-mmusic-rid-15#page-19

 rid-param         = rid-width-param
                       / rid-height-param
                       / rid-fps-param
                       / rid-fs-param
                       / rid-br-param
                       / rid-pps-param
                       / rid-bpp-param
                       / rid-depend-param
                       / rid-param-other
 rid-param-other   = 1*(alpha-numeric / "-") [ "=" param-val ]
 param-val         = *( %x20-58 / %x60-7E ) ; Any printable character except semicolon


IMHO the usage of FID for signaling the "SIM" group is not a good choice as it is being used today for signaling the rtx association, and should be still present in the SDP if not using rids/rrids (which I understand that is the goal of the draft)

Best regards
Sergio

On 11/04/2019 12:30, Harald Alvestrand wrote:

I have made a proposal.

Note: This is strictly a *personal* contribution. Do not attach undue authority to it.


Harald



-------- Forwarded Message --------
Subject: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt
Date: Thu, 11 Apr 2019 03:28:17 -0700
From: internet-drafts@ietf.org
To: Harald Alvestrand <harald@alvestrand.no>



A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name: draft-alvestrand-mmusic-simulcast-ssrc
Revision: 00
Title: Using SSRC with WebRTC Simulcast
Document date: 2019-04-11
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-00.txt
Status: https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/
Htmlized: https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc


Abstract:
This document describes a convention for sending "a=ssrc" attributes
in SDP together with "a=simulcast" attributes. This allows SFUs that
need SSRC information to have this info easily accessible.

Given that it is intended as an interim measure, it does not aim for
being published as an RFC.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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


--------------5F67EE26E71BF9CD44BF5712-- From nobody Thu Apr 11 09:20: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 0155E1203AF for ; Thu, 11 Apr 2019 09:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=aruba.it 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 LVw1QFRC9n1b for ; Thu, 11 Apr 2019 09:19:56 -0700 (PDT) Received: from smtpcmd0871.aruba.it (smtpcmd0871.aruba.it [62.149.156.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7F098120304 for ; Thu, 11 Apr 2019 09:19:55 -0700 (PDT) Received: from lminiero ([93.33.169.44]) by smtpcmd08.ad.aruba.it with bizsmtp id z4Kr1z00t0xotn9014Ks58; Thu, 11 Apr 2019 18:19:53 +0200 Date: Thu, 11 Apr 2019 18:19:51 +0200 From: Lorenzo Miniero To: Harald Alvestrand Cc: "rtcweb@ietf.org" , "public-webrtc@w3.org" Message-ID: <20190411181951.729451c4@lminiero> In-Reply-To: References: <155497849785.12672.2988988646899076493.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1554999593; bh=IDR56W4WgsAFBbB0edWUwESXSVWIro/03rY5dcdGYzY=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=cwqMJMZCj4qM0Vb0jaFJLV4lqBsS9+n8UBMvTVrfNIRtVlb3G73mVujl9j7gg71pz omFNgOeWVp8AzGbLdRK6WMSVjiVayV4dj4HXtS6E1pTQsGX7yaM+bgTa6Yy3Q1OscF 02edSzK/RmqzqypUvOneTY2IQ7a5jWXhFXq20P0YrRyr9TVc1mZzPbBn1Up7BNO2Od H7oVH2Bc/51isLrQmZLAWqGhXPRseV5e+9D8vKuYYZDH9ayrk2LkM36qjRJUNYhkGK eOIg0H4fyh1J+3aD9poh13jPn42YEsvmSf/ogFbMm7e02RV4zYNTSNY1hJIkzYgdY/ 8EMC+T94Jr1XA== Archived-At: Subject: Re: [rtcweb] New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-00.txt 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, 11 Apr 2019 16:20:00 -0000 Hi Harald, why drop SSRC advertisement for rtx for simulcast? While I understand rtx is still there if you use the repaired-rid extension, Chrome was able to do both using different ssrc-groups. I realize SIM was not standard, but it gave the right context, and FID provided the rtx mappings instead. As such, as an interim solution, that sounded like an easier approach. Anyway, the rest looks good to me! Lorenzo On Thu, 11 Apr 2019 12:30:13 +0200 Harald Alvestrand wrote: > I have made a proposal. > > Note: This is strictly a *personal* contribution. Do not attach undue > authority to it. > > > Harald > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-alvestrand-mmusic-simulcast-ssrc-00.txt > Date: Thu, 11 Apr 2019 03:28:17 -0700 > From: internet-drafts@ietf.org > To: Harald Alvestrand > > > > > A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-00.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Name: draft-alvestrand-mmusic-simulcast-ssrc > Revision: 00 > Title: Using SSRC with WebRTC Simulcast > Document date: 2019-04-11 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-00.txt > Status: > https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/ > Htmlized: > https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc > > > Abstract: > This document describes a convention for sending "a=ssrc" attributes > in SDP together with "a=simulcast" attributes. This allows SFUs that > need SSRC information to have this info easily accessible. > > Given that it is intended as an interim measure, it does not aim for > being published as an RFC. > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > -- I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero From nobody Sun Apr 14 10:02: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 9541612012F for ; Sun, 14 Apr 2019 10:02:40 -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 RywfjFffSttW for ; Sun, 14 Apr 2019 10:02:37 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 EF8ED1200DF for ; Sun, 14 Apr 2019 10:02:36 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id z76so8494101qkb.12 for ; Sun, 14 Apr 2019 10:02:36 -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=BjYVAeqPHK+QOLVkRyPxfvgfeM1GX2haA+wWAB0tBoY=; b=HTc87oDzuMYXdrzud8EoR8ePJK031G0OTT3FN2bVGDHIAqslOUR9Nnar2dVN8+Qd3A Y4H6ZHoqCO5T4XVomFhQEfctobZSOx/rLKbYo1WAC9fE5FPmfscXswjqb0dyUFH2FwR/ lir2BXJAFPQZwvowwJZLKvHP2emmOW6PlY8Zk= 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=BjYVAeqPHK+QOLVkRyPxfvgfeM1GX2haA+wWAB0tBoY=; b=mYEXfNA77/vlcGL8bdk8ckLCagtOLQzffn1w2U5ltU97oUiW2VqW3J6zEyJF04+wcy ooysIvx9aXNLuxOe0ARDGTvGdvLgkFKtFcOWZvTPTxJzHBRBzV/xS8X4HRyMrcL6E9AK QePUnApsSKiNVe3QkbsA4jpn/k4WOPpbI7acwAv0zV2wwRMyP+whd3k9Q6Gm8OXJuipt s+H7lCnBC8/z3VF8wwldfLWHOQbthWDEWhqXXmECwZ5r9KFzMfW3AFLcSsM9dsH6q6HB DkDf2tRMz7e4zY/bXzohf6/2JWBJ7xB3QMaOT6Fv1xeTLfUMC99znUzFwxWJ5dOinq/p j2Fg== X-Gm-Message-State: APjAAAWy0ubXlYcerLcSX+NgnJfYrIMmfwzrl2ajD8BzTyhA9R/9Pc49 K0AhXoYb2lnj6u/C35HCGUzfrQ== X-Google-Smtp-Source: APXvYqy3+yxnjP9DBrANHY3xQPlZoZFoUNAkC5gikC+zDecByahz7svd+weveLTR0Ta62Rk2gp2Y/A== X-Received: by 2002:a37:4757:: with SMTP id u84mr46805487qka.275.1555261355953; Sun, 14 Apr 2019 10:02:35 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id u16sm38980269qtc.84.2019.04.14.10.02.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 10:02:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Sean Turner In-Reply-To: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> Date: Sun, 14 Apr 2019 13:02:33 -0400 Cc: The IESG , draft-ietf-rtcweb-security@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B580977-EDD3-4EEC-ABDB-413F5A9911B5@sn3rd.com> References: <155189932716.14137.9903426522882898659.idtracker@ietfa.amsl.com> To: Datatracker on behalf of Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.8) 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: Sun, 14 Apr 2019 17:02:40 -0000 Didn=E2=80=99t get all the way through the comments, but I got a pretty = start. If there=E2=80=99s something else we need to discuss I can = organize a time to get folks on a call. > On Mar 6, 2019, at 14:08, Datatracker on behalf of Benjamin Kaduk = wrote: >=20 > Benjamin Kaduk 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'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): >=20 > 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"? >=20 > 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? Looks like you and Adam worked it out and now we need to come up with = some text. A PR to address this is here: https://github.com/rtcweb-wg/security/pull/17 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- I filled a "comments PR=E2=80=9D here: https://github.com/rtcweb-wg/security/pull/19 > I mostly only have editorial comments, though there are a few that are > more content-ful. >=20 > Section 1 >=20 > 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. >=20 > The user can observe the javascript running the browser, though maybe > this distinction is not necessary here. I re-read this a couple of times and the only thing I could add is what = is probably very obvious, i.e., the user is in control of the end-point = so it can see anything. I am too am not sure that=E2=80=99s really = worth pointing out here. > Section 3 >=20 > Huang et > al. [huang-w2sp] summarize the core browser security guarantee as: >=20 > Users can safely visit arbitrary web sites and execute scripts > provided by those sites. >=20 > 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? Eh ... I can see where maybe not much would be added if there was just = one author and the paper hadn=E2=80=99t been accepted by a conference, = but there are five and it was accepted. > The use of ALL-CAPS to call out new terms feels a bit dated. Haha - I can fix TCB, WEB ATTACKERS, and NETWORK ATTACKERS :). Fixed in = this =E2=80=9Ccomments PR=E2=80=9D. > 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. >=20 > 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=E2=80=9D.) It=E2=80=99s include the comment PR noted above. > Section 3.1 >=20 > It might be appropriate to provide some example references in place of > "extensive research=E2=80=9D. So there=E2=80=99s lots and I=E2=80=99m not even really sure where to = start here, but we do reference [cranor-wolf] later so I=E2=80=99ll add = that here. > Section 4.1 >=20 > In either case, all the > browser is able to do is verify and check authorization for whoever > is controlling where the media goes. [...] >=20 > 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). Maybe =E2=80=9CIn both cases, ..." > 00000000000000000000000000000000000000000000000000000000000000000000By > contrast, consent to send network traffic is about preventing the > user's browser from being used to attack its local network. [...] >=20 > nit: "local" is perhaps overly restricting, depending on = interpretation I can see striking =E2=80=9Clocal=E2=80=9D. > Section 4.1.1 >=20 > 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. Something like:=20 A more sophisticated attack would be open up a source view window to a site and use the screen sharing result to simply view anti cross-site request forgery tokens which would leak = pixels and not structured text. > Section 4.1.3 >=20 > Now that we have seen another use case, we can start to reason about >=20 > nit: I'm confused by "another" here. I think this should be: Now that we have the calling scenarios, we can start to reason about = .. This links this para back to the previous calling scenarios and user = expectations. > 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 >=20 > 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. Okay so -04 included a section that was referred to by this section that = addressed the =E2=80=9CCalling to an AD Target=E2=80=9D, but that = section was removed because the WG decided not treat the case = =E2=80=9Cspecially=E2=80=9D. So yeah there was some more background = provided like 6 years ago. I have to admit I=E2=80=99m not entirely = sure I know how to address this comment. > 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. >=20 > 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. yep > Section 4.1.4 >=20 > 3. The attacker forges the response apparently http://calling- > service.example.com/ to inject JS to initiate a call to himself. >=20 > seem to be missing a word or two here. I think r/apparently/from fixed in comments PR > 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. >=20 > nit: "If any page" is more emphatic, I think. Yep fixed in comments PR. > Section 4.2 >=20 > Do we want any discussion of the risks when metered bandwidth (pay per > byte) is in use? Do you mean concerns that the connection will be closed if your bill = isn=E2=80=99t paid up? :) > Section 4.2.1 >=20 > 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?). Yes, but that=E2=80=99s the whole point of the intro, this is a browser = focused world that has a JavaScript API. > 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. Yes, but those are the actual terms used by ICE, which is referred to in = the first sentence in the paragraph. > Section 4.2.2 >=20 > 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). >=20 > 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. >=20 > nit: "employed" to obfuscate what, exactly? >=20 > Section 4.2.3 >=20 > 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 >=20 > nit: "incorporated" into what? >=20 > 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?) >=20 > leaves. The appropriate technologies here are fairly similar to > those for initial consent, though are perhaps weaker since the > threats is less severe. >=20 > nit: "threat is=E2=80=9D It got switched to =E2=80=9Care=E2=80=9D as a result of some other = review. > Section 4.2.4 >=20 > 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. >=20 > Is "answered" supposed to be some interaction with the controlling = site? >=20 > 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. [...] >=20 > 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. >=20 > Section 4.3.1 >=20 > [Obligatory note about "Forward Secrecy" vs. "Perfect Forward = Secrecy"] >=20 > 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. >=20 > 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? >=20 > Section 4.3.2.1 >=20 > 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. >=20 > nit: "browser to use trusted UI=E2=80=9D Fixed in the comments PR. > Section 4.3.2.3 >=20 > 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? >=20 > Section 4.3.2.4 >=20 > 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. >=20 > 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?) Dropped the first person (I also hope the RFC editor) can help with this = elsewhere. See the comments PR. > Section 9.2 >=20 > The coordinates for [OpenID] don't seem quite right. The title was off. Fixed in the comments PR. From nobody Sun Apr 14 10:03:04 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 456071201C7 for ; Sun, 14 Apr 2019 10:02:54 -0700 (PDT) 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=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 ssk5n6fxnXwW for ; Sun, 14 Apr 2019 10:02:51 -0700 (PDT) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) (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 C521A12012A for ; Sun, 14 Apr 2019 10:02:42 -0700 (PDT) Received: by mail-qk1-f194.google.com with SMTP id c20so8510739qkc.10 for ; Sun, 14 Apr 2019 10:02:42 -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=WyGc4Hf4mjyZuFnqfidZ76pKQMgkXAWsTtZZQeK62DI=; b=Eh36HpLEN3pXjdtkgEuOlWnhBsJGGFPnnd/Y6OZwxIXFSsmwrhXyYLf49m7CMngVje R6MKRH+hilwlOLCyLOWD2eOjP5mK/Uk+jDLPFFq9RenVDMVaukbl1gcv0JF9WujVT2m1 fkTd1M87twDZ3An+Y09rt3xpST0A5EqjJZlew= 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=WyGc4Hf4mjyZuFnqfidZ76pKQMgkXAWsTtZZQeK62DI=; b=kI1TM8tV77A4/0nUSrc5lIMVvYd4oBH7ehfHioEF4yKU7tuOL9gWb4YajDMkN+uSkP 6ZB3AnJhnj1DuWkfobXct98a9GsmZ6sAlUYcUtUuIpaAlkdpDgLYVUKJq81zDqGkr/YD 5hrT2riXIwd3RH9MA3GGYbR1x3kqytb8gNcws7EmXcyc49F8G3QKUn/BoRGzr407+NUC KjD7KwAYrWVgL68CZEfD6qWhqSybAtDzgNJGMJ9U0y8tCTIFHQ2EDdQvFfMypba3HkfI v2DJCfFiIGJ8qBYV6vLhtAxLmnmbKP/wfUUF2+e/sT6ESfJFnKINogGqt7Ik9SyoFUq8 xmYw== X-Gm-Message-State: APjAAAUvdM4i7tpq6UpaFkDqBJIKzcF3Rb9SXpfU8wDg7+FbO47Lo3GW fqP/FtsUersbhsgOSc1lp2ygnQ== X-Google-Smtp-Source: APXvYqwKaS9kBvUE/lDB72ipW7SA+Rr23IkQ9fs1IoWIWTLM2VW7+29olDwbajlrSJ9g/bsnlMQKdw== X-Received: by 2002:a37:9b46:: with SMTP id d67mr55651493qke.276.1555261361393; Sun, 14 Apr 2019 10:02:41 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id u16sm38980269qtc.84.2019.04.14.10.02.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 10:02:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Sean Turner In-Reply-To: <155192582265.13773.4546017380973569678.idtracker@ietfa.amsl.com> Date: Sun, 14 Apr 2019 13:02:39 -0400 Cc: The IESG , draft-ietf-rtcweb-security-arch@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <746BFA74-9B05-4754-B610-ED24BF0EC049@sn3rd.com> References: <155192582265.13773.4546017380973569678.idtracker@ietfa.amsl.com> To: Datatracker on behalf of Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [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 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: Sun, 14 Apr 2019 17:02:55 -0000 I didn=E2=80=99t get all the way through the comments, but I got a = pretty start. If there=E2=80=99s something else we need to discuss I = can organize a time to get folks on a call. > On Mar 6, 2019, at 21:30, Datatracker on behalf of Benjamin Kaduk = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-rtcweb-security-arch-18: 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-arch/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- I filed an issue here for these: https://github.com/rtcweb-wg/security-arch/issues/89 > 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). Thanks for the parenthetical ;). We=E2=80=99ll pick through them and see = what we can do. > 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.. I am trying to figure out what we could include to address this. I have = to tell you my first thought is that the IdP is just doing its job, = i.e., it signs assertions that an authenticated party wants signed. > The "Modifying the Session" treatment for the SDP "identity" attribute > seems incompletely specified. I am hoping you might expand here a bit on what you think might be = needed. We had the SDP directorate review and they (Christer) gave it = the thumbs up. > 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. Ted started a thread on this here: https://mailarchive.ietf.org/arch/msg/rtcweb/8dtCkSeXWUsb_y2SRyFlbQ5r93w We=E2=80=99ll see where it lands. > 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. I=E2=80=99m struggling to think what more might be said because the AP = is asking the IdP to vouch for its identity so the IdP is literally = doing what the AP asked it to do. > 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. I think that all three sections are consistent wrt to the IdP binding = the user identified in the assertion with the key fingerprints. Section = 7.4 and 7.6 are just saying that the IdP doesn=E2=80=99t need to know = what it is signing. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- I filed an issue for this here: https://github.com/rtcweb-wg/security-arch/issues/90 > Section 3 >=20 > (My comment about TCB and the other browser from the companion = document > is probably relevant here, too.) I am hoping the text that we put in the -security draft address this = concern. > Section 4.1 >=20 > 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 >=20 > 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.) Sure I=E2=80=99ll drop preferably. Fixed in the =E2=80=9Ccomment" PR: https://github.com/rtcweb-wg/security-arch/pull/91 > 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. [...] >=20 > 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? Don=E2=80=99t forget this part from earlier in the Section: They are both connected to the calling service via HTTPS and so know the origin with some level of confidence. They also have accounts with some identity provider. > Section 4.3 >=20 > Once the ICE checks have completed [more specifically, once some ICE > checks have completed], [...] >=20 > nit: that's not really more specific. Maybe "Once the requisite ICE > checks have completed=E2=80=9D? Sounds good. Fixed in the comments PR. > Section 5 >=20 > I see that the 4566 includes the pad characters, though > sometimes we will mention explicitly whether they are or are not > included. >=20 > 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. >=20 > leading whitespace, too, right? Yes :). Fixed in the comments PR. > Section 5.1 >=20 > This section defines the SDP Offer/Answer [RFC6454] considerations > for the SDP 'identity' attribute. >=20 > 6454 is "the Web Origin Concept"; presumably this is supposed to be > 4566 (or 3264?). good catch. Fixed in the comments PR > Section 5.1.3 >=20 > I feel like we need some text here about the (non?)trustworthiness of > the IdP. >=20 > Section 5.1.4 >=20 > 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? >=20 > 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. >=20 > nit: is this "each media section"/"every media section" redundant? >=20 > Section 6.1 >=20 > 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. >=20 > 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. >=20 > Section 6.2 >=20 > 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 > Just to check: this last sentence applies for one-time requets, too? >=20 > 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. [...] >=20 > 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". >=20 > 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()). [...] >=20 > Do we need to say anything about that state transition being visible = to > the peer, here? >=20 > 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.] >=20 > nit: s/windows/window/? >=20 > 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). >=20 > Is there anything to say about why clients might not opt to do so (and > what such approval might look like)? >=20 > (My comments about "verified user" including the IdP in some way will > apply here as well.) >=20 > Section 6.3 >=20 > 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 >=20 > Is the "the current WG consensus" language going to age well? >=20 > 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]. >=20 > Is there a WIP draft for this separate document? >=20 > Section 6.4 >=20 > 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. >=20 > nit: maybe make it more clear that this only applies for incoming = calls? >=20 > Section 6.5 >=20 > Media = traffic > MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, > implementations MUST NOT negotiate cipher suites with NULL = encryption > modes. [...] >=20 > 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?) >=20 > [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] >=20 > Implementations MUST NOT implement DTLS renegotiation and MUST = reject > it with a "no_renegotiation" alert if offered. >=20 > "MUST NOT implement" isn't really something that 2119 language can > enforce; "MUST NOT use" is the best we can get. >=20 > Endpoints MUST NOT implement TLS False Start [RFC7918]. >=20 > (7918 doesn't claim to be applicable to DTLS anyway) >=20 >=20 > 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.) >=20 > nit: might be appropriate to note why we care about a super-cookie = (and > what it is) >=20 > * 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. >=20 > I'm not sure I see anywhere that we allow the usage of null ciphers. >=20 > Section 7 >=20 > 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. [...] >=20 > I agree with Alissa that the first person is not needed here. >=20 > Section 7.1 >=20 > 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. >=20 > This probably needs some qualifier, given recent developments with CAA > and similar mechanisms. >=20 > 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 >=20 > The RP still needs to establish somehow that the IdP in use is in fact > an authoritative IdP, though! >=20 > Section 7.2 >=20 > 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 >=20 > A reference to that W3C API spec might be handy. >=20 > Section 7.3 >=20 > There are two parts to this work: >=20 > 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. >=20 > 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. >=20 > Section 7.4 >=20 > The indentation of the line with "}, {" is a bit confusing. I tweaked it a bit in the comments PR. > 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 >=20 > I'm a little confused what this "encoded in a JSON string" is supposed > to mean. >=20 > 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. >=20 > The IdP probably wants to know enough about its structure to not turn > into a signing oracle for other protocols, though. It=E2=80=99s as specified in the webrtc-api :) > Section 7.4.1 >=20 > (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention > that.) True but it doesn=E2=80=99t really hurt to leave it. > 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. Can somebody please generate a SHA-256 example for me? > 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. >=20 > leading whitespace, too, right? Yes :) Added in the comments PR. > Section 7.5.2 >=20 > (Still need to say how it's know than authoritative assertions are in > fact authoritative for what they claim.) >=20 > Section 7.6 >=20 > 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. >=20 > (IdP still doesn't want to become a signing oracle.) >=20 > For use in signaling, the assertion is serialized into JSON, > Base64-encoded [RFC4648], and used as the value of the "identity" > attribute. >=20 > nit: it's unclear that "serialized into JSON" adds any value, since = the > thing is defined to be a JSON object. >=20 > Section 7.7 >=20 > 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). >=20 > Section 8 >=20 > 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. >=20 > IMPORTANT: Do we need a freshness property for the assertion? Some of > these schemes do not provide freshness. >=20 > Figure 6 shows an example response formatted as JSON for = illustrative > purposes. >=20 > (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?) he webrtc-api spec says its JSON so: Figure 6 shows an example response, which is JSON-formatted. > Section 8.1 >=20 > 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: >=20 > 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. since it=E2=80=99s =E2=80=9Cand=E2=80=9D after the first sub-bullet = I=E2=80=99ll add =E2=80=9Cboth=E2=80=9D. > Any "@" or "%" characters in the "user" portion of the identity MUST > be escaped according to the "Percent-Encoding" rules defined in >=20 > We just said in the first paragraph that "user" has "any character > except '@'", so this is a bit redundant. I dropped =E2=80=9Cexcept =E2=80=98@=E2=80=98 from the 1st para. = Somebody will tell me if I did this wrong, but there is some kind of x1 > Section 9.1 >=20 > 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. >=20 > I suppose an "untrustworthy" IdP is basically a malicious one, though > there are perhaps some subtleties that could be distinguished here. >=20 > 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. >=20 > 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? >=20 > Section 9.2 >=20 > Otherwise, the other side will learn linkable information. >=20 > nit: "linkable information that would allow them to correlate the > browser across multiple calls=E2=80=9D. Added in the comments PR. > Section 9.3 >=20 > 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. >=20 > 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? >=20 > 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. >=20 > nit: "must be used to suppress the misbehaving flow", I think. >=20 > Section 9.4.3 >=20 > 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. >=20 > I don't see an "origin" field in the signature request; is this = supposed > to be the "domain=E2=80=9D? Changed it to =E2=80=9Cdomain=E2=80=9D to match the structure. Also, = instead of "signature request=E2=80=9D I change it to =E2=80=9Cassertion = request=E2=80=9D to match the earlier heading title. > Section 9.4.5.1 >=20 > nit: it might be friendlier to the reader to prefix this with "When > popup blocking is in use, =E2=80=9C. Added in comments PR. > Section 13.2 >=20 > It's perhaps debatable that JSEP is only an informative reference. Moved it to normative in the comments PR. From nobody Thu Apr 18 17:38:20 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 034BD120251 for ; Thu, 18 Apr 2019 17:38:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=g001.emailsrvr.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 s78z9guB5F_Y for ; Thu, 18 Apr 2019 17:38:16 -0700 (PDT) Received: from smtp97.ord1d.emailsrvr.com (smtp97.ord1d.emailsrvr.com [184.106.54.97]) (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 B99CB12024C for ; Thu, 18 Apr 2019 17:38:16 -0700 (PDT) Received: from smtp13.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 13A7CC018C; Thu, 18 Apr 2019 20:38:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1555634296; bh=x8Dn31rKoeMzKkT5e+RGM0157LWy8Xh4HMhWy0b44Ck=; h=Subject:From:Date:To:From; b=s8xsdDjgt7zKOw5Ms7rv1+E93iU/YaDXLJdwCjiJ8VOOt+VDy1lR+0RpPf/aTD+Ba 7/QbFJQRK7MKSYlv5/3OU/kljOb295I7mWsQEKZMbM52FRvsnJKj5J3Cj3peQKMWxf GxAB8qYNAq3XTsMQcwPdnvHQwfcn13GsdBMJvQr8= X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 922EFC0180; Thu, 18 Apr 2019 20:38:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Thu, 18 Apr 2019 20:38:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_FE14113F-78A8-4296-92F0-9F4BB8809E13" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Cullen Jennings In-Reply-To: Date: Thu, 18 Apr 2019 18:38:14 -0600 Cc: RTCWeb IETF , Sean Turner , Adam Roach Message-Id: References: To: Ted Hardie X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [rtcweb] Security-arch IdP determination issue/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: Fri, 19 Apr 2019 00:38:19 -0000 --Apple-Mail=_FE14113F-78A8-4296-92F0-9F4BB8809E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree this change makes sense. It is so easy to get domain names and = certs and SNI is so widely adopted that I do not see many arguments = against this.=20 > On Apr 9, 2019, at 11:59 AM, Ted Hardie wrote: >=20 > In section 7.5 of the Security-arch draft, the document says: >=20 > Authority: The authority [RFC3986 = ] at which the IdP's service is > hosted. Note that this may include a non-default port or a > userinfo component, but neither will be available in a = certificate > verifying the site. >=20 > Benjamin Kaduk raised a DISCUSS on this: > I'm a bit unclear about how the port in the=20 > IdP URI's Authority (Section 7.5) would get=20 > discovered. If it can be remotely supplied,=20 > there may be risks in just trusting blindly=20 > whatever value is received. >=20 > Given that we discover this via a .well-known location which is meant = to be deterministic, I went looking for the more general .well-known = advice on this topic. Turns out that the updated version in 578bis = has = this: >=20 > Typically, applications will use the default port=20 > for the given scheme; if an alternative port is=20 > used, it MUST be explicitly specified by the=20 > application in question. >=20 > Obviously, our doc predates 5785bis, but given the discuss and that = advice, I think the right thing to do here is to drop the ability to = have a non-default port or to specify an alternate port. >=20 > Is there anyone currently using this with a non-default port? >=20 > Any objections to dropping this or preferences for specifying an = alternate port? >=20 > regards, >=20 > Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_FE14113F-78A8-4296-92F0-9F4BB8809E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I agree this change makes sense. It is = so easy to get domain names and certs and SNI is so widely adopted that = I do not see many arguments against this. 

On Apr = 9, 2019, at 11:59 AM, Ted Hardie <ted.ietf@gmail.com> wrote:

In = section 7.5 of the Security-arch draft, the document = says:

Authority:  The authority [RFC3986] =
at which the IdP's service is
      hosted.  Note that this may include a non-default port or a
      userinfo component, but neither will be available in a certificate
      verifying the site.

Benjamin Kaduk raised a DISCUSS on this:
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.

Given that we discover this via a .well-known location which = is meant to be deterministic, I went looking for the more general = .well-known advice on this topic.  Turns out that the updated = version in 578bis has this:

Typically, applications will use the = default port
for the given scheme; if an alternative port = is
used, it MUST be explicitly specified by the
application in question.

Obviously, = our doc predates 5785bis, but given the discuss and that advice, I think = the right thing to do here is to drop the ability to have a non-default = port or to specify an alternate port.

Is there anyone currently using this = with a non-default port?

Any objections to dropping this or preferences for specifying = an alternate port?

regards,

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

= --Apple-Mail=_FE14113F-78A8-4296-92F0-9F4BB8809E13-- From nobody Sun Apr 21 16:12:57 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 1D0601202CB; Sun, 21 Apr 2019 16:12:42 -0700 (PDT) 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, 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] 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 CiTJQ6yYOfXb; Sun, 21 Apr 2019 16:12:39 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60088.outbound.protection.outlook.com [40.107.6.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF3120142; Sun, 21 Apr 2019 16:12:38 -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=JUX0E6Ak9wgM9MPCalfpMj66nREimidwYuT7M+GOypg=; b=KtX+Sq1KbBpU673Kl6LT62am80psVsWqiDUwZEKtPyA75fElHffV0rmtvwADz58sptvSTBmPe9W7PnJiNiUopyn3IYDSPyoNlYYRWq9lQNNixMb1B5l+rGFi6ySaGffzF7h0s2tKCqN7xNxhZ5L4gA8oz7HjrLCYS7+Oayu2nrE= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Sun, 21 Apr 2019 23:12:35 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Sun, 21 Apr 2019 23:12:35 +0000 From: Christer Holmberg To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" Thread-Topic: Scope of SDP m= line 'webrtc-datachannel' Thread-Index: AQHU+Je0/HMXLDHCpUOf+vA6YZZ9Og== Date: Sun, 21 Apr 2019 23:12:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [176.93.29.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3756916f-34ff-4562-cf7f-08d6c6aed74d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3259; x-ms-traffictypediagnostic: HE1PR07MB3259: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(39860400002)(136003)(199004)(189003)(58126008)(110136005)(66446008)(6506007)(14454004)(6486002)(6436002)(66066001)(6116002)(36756003)(68736007)(7736002)(66946007)(76116006)(73956011)(66556008)(64756008)(2501003)(2906002)(44832011)(66476007)(86362001)(2201001)(83716004)(186003)(102836004)(8936002)(26005)(81156014)(81166006)(71190400001)(71200400001)(99286004)(5660300002)(606006)(478600001)(450100002)(25786009)(966005)(3846002)(82746002)(97736004)(54896002)(6306002)(2616005)(33656002)(256004)(14444005)(476003)(486006)(236005)(6512007)(53936002)(316002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3259; H:HE1PR07MB3161.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: Ly4tRHBlMTBfmdlixAnRumQF1QqR1ALYKbP4Q3HA5DQgoRvhY5gqYN8epWRKqkcitOFEwIACKEbmpIK2NQ805bw0U6SA7M4nvNhcsmnw6gx209rYIo4GdeXFGTyJYP0NNDzxSS0oauTe3WXvQLh70gg8ErbzgfFFmYqAkrqQK1ny4S7AMaAhXB7ZrGr/MyJugpiN9P/+mOg+XLRpzLuVNA5o+q2Hwt1FbSC92ISkpwmcJhv5KA0arQ9B6GSbtVTwJEzAR29n8U4hPv8Fx7hcvtMRY6nfK7FWmhSkO5zj434gHFVdUu9RE/bfBYsda12fTW3o1+Su53VbyLsM8/qdbcovTg6JY/JYLnLhcJ+wQKG14J520+vCfZv8MPOtXkplwEz0g2j/JIa+fXrbVOdPRWR6lYctwkU6B1GfYb4ZLBI= Content-Type: multipart/alternative; boundary="_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3756916f-34ff-4562-cf7f-08d6c6aed74d X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2019 23:12:35.6712 (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: HE1PR07MB3259 Archived-At: Subject: [rtcweb] Scope of SDP m= line 'webrtc-datachannel' 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: Sun, 21 Apr 2019 23:12:42 -0000 --_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gY3Jvc3MtcG9zdGluZyB0aGlzIG9uIG11bHRpcGxlIGxpc3QsIHRvIG1ha2Ug cGVvcGxlIGF3YXJlIG9mIHRoZSBpc3N1ZS4gSG93ZXZlciwgSSBhc2sgdGhhdCBhbnkgY29tbWVu dHMgYW5kIGRpc2N1c3Npb25zIHRha2UgcGxhY2Ugb24gdGhlIE1NVVNJQyBsaXN0IG9ubHkuDQoN CkkgZm91bmQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiA0LjUgb2YgZHJhZnQt aWV0Zi1tbXVzaWMtc2N0cC1zZHA6DQoNCiAgIOKAnE5PVEU6ICd3ZWJydGMtZGF0YWNoYW5uZWwn IGluZGljYXRlcyB0aGUgV2ViUlRDIERhdGEgQ2hhbm5lbA0KICAgRXN0YWJsaXNobWVudCBQcm90 b2NvbCBkZWZpbmVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0u4oCdDQoNCklu IGFkZGl0aW9uLCBpbiB0aGUgSUFOQSByZWdpc3RyYXRpb24gb2Yg4oCYd2VicnRjLWRhdGFjaGFu bmVs4oCZIChzZWN0aW9uIDE1LjMpLCBkcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sIGlz IHJlZmVyZW5jZWQuDQoNClRvIHJlZnJlc2ggZXZlcnlvbmUsIGRyYWZ0LWlldGYtcnRjd2ViLWRh dGEtcHJvdG9jb2wgZGVmaW5lcyBEQ0VQICh0aGUgaW5iYW5kIHByb3RvY29sIGZvciBoYW5kbGlu ZyBXZWJSVEMgRGF0YSBDaGFubmVscyksIGFuZCDigJh3ZWJydGMtZGF0YWNoYW5uZWzigJkgaXMg dXNlZCBpbiB0aGUgU0RQIG09IGxpbmUgd2hlbiBlc3RhYmxpc2hpbmcgYW4gU0NUUCBhc3NvY2lh dGlvbiBmb3Igc3VjaCBjaGFubmVsLg0KDQpIb3dldmVyLCBib3RoIGRyYWZ0LWlldGYtbW11c2lj LWRhdGFjaGFubmVsLXNkcC1uZWcgYW5kIGRyYWZ0LWlldGYtY2x1ZS1kYXRhLWNoYW5uZWwgdXNl IOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBpbiB0aGUg4oCcbT3igJ0gbGluZSwgYW5kIHRob3Nl IGRyYWZ0cyBkbyBub3QgdXNlIERDRVAuDQoNCk15IHN1Z2dlc3Rpb24gdG8gZml4IHRoaXMgaXMg dG8gbW9kaWZ5IHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLCB0byBhbHdh eXMgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBmb3IgV2ViUlRDIERhdGEgQ2hhbm5lbHMg 4oCTIG5vIG1hdHRlciB3aGV0aGVyIERDRVAgaXMgdXNlZCBvciBub3QuDQoNCkkgaGF2ZSBjcmVh dGVkIGEgcHVsbCByZXF1ZXN0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2N0 cC1zZHAvcHVsbC8xNQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K --_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkki IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SSBhbSBjcm9zcy1wb3N0aW5nIHRoaXMgb24gbXVsdGlwbGUgbGlzdCwgdG8gbWFrZSBwZW9w bGUgYXdhcmUgb2YgdGhlIGlzc3VlLiBIb3dldmVyLCBJIGFzayB0aGF0IGFueSBjb21tZW50cyBh bmQgZGlzY3Vzc2lvbnMgdGFrZSBwbGFjZSBvbiB0aGUgTU1VU0lDIGxpc3Qgb25seS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SSBmb3VuZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiBzZWN0aW9uIDQuNSBvZiBk cmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IOKAnE5PVEU6ICd3ZWJy dGMtZGF0YWNoYW5uZWwnIGluZGljYXRlcyB0aGUgV2ViUlRDIERhdGEgQ2hhbm5lbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEVzdGFibGlzaG1lbnQgUHJvdG9jb2wgZGVmaW5l ZCBpbiBbSS1ELmlldGYtcnRjd2ViLWRhdGEtcHJvdG9jb2xdLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBh ZGRpdGlvbiwgaW4gdGhlIElBTkEgcmVnaXN0cmF0aW9uIG9mIOKAmHdlYnJ0Yy1kYXRhY2hhbm5l bOKAmSAoc2VjdGlvbiAxNS4zKSwgZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbCBpcyBy ZWZlcmVuY2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UbyByZWZyZXNoIGV2ZXJ5b25lLCBkcmFmdC1pZXRmLXJ0 Y3dlYi1kYXRhLXByb3RvY29sIGRlZmluZXMgRENFUCAodGhlIGluYmFuZCBwcm90b2NvbCBmb3Ig aGFuZGxpbmcgV2ViUlRDIERhdGEgQ2hhbm5lbHMpLCBhbmQg4oCYd2VicnRjLWRhdGFjaGFubmVs 4oCZIGlzIHVzZWQgaW4gdGhlIFNEUCBtPSBsaW5lIHdoZW4gZXN0YWJsaXNoaW5nDQogYW4gU0NU UCBhc3NvY2lhdGlvbiBmb3Igc3VjaCBjaGFubmVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ib3dldmVyLCBib3Ro IGRyYWZ0LWlldGYtbW11c2ljLWRhdGFjaGFubmVsLXNkcC1uZWcgYW5kIGRyYWZ0LWlldGYtY2x1 ZS1kYXRhLWNoYW5uZWwgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBpbiB0aGUg4oCcbT3i gJ0gbGluZSwgYW5kIHRob3NlIGRyYWZ0cyBkbyBub3QgdXNlIERDRVAuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk15 IHN1Z2dlc3Rpb24gdG8gZml4IHRoaXMgaXMgdG8gbW9kaWZ5IHRoZSB0ZXh0IGluIGRyYWZ0LWll dGYtbW11c2ljLXNjdHAtc2RwLCB0byBhbHdheXMgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKA mSBmb3IgV2ViUlRDIERhdGEgQ2hhbm5lbHMg4oCTIG5vIG1hdHRlciB3aGV0aGVyIERDRVAgaXMg dXNlZCBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1 L2RyYWZ0LXNjdHAtc2RwL3B1bGwvMTUiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1 Yi5jb20vY2RoNHUvZHJhZnQtc2N0cC1zZHAvcHVsbC8xNTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_-- From nobody Mon Apr 22 12:08:54 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 0AE3B1200E9; Mon, 22 Apr 2019 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR7_rZsc34eR; Mon, 22 Apr 2019 12:08:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B27120128; Mon, 22 Apr 2019 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9058; q=dns/txt; s=iport; t=1555960116; x=1557169716; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=XwFz4oM/tofrRj/Prz2as/Ru8X9Jw+3imBVIlDcxuk0=; b=mGy0SjlIbllWhGjdRKGJS4kJNggTm5RI5ne2tz1mLPv55EP6HC1PwmwC wdRxyt/8qBw9PjSVL+o3lQY8lWb97AtPRQMuLwJ6NhVlnP6PPZNTnpUhq MRt1wBsEGyZVmFtbW0V6hKM6cAqa0a5O3jVdUzpXc+Cpl5UHgtijkugIV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAADQEL5c/5xdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAMBAQELAYEOgQJoUTMohA6TKIFgLYlIiQmHdRAYAQqEBEYChiM?= =?us-ascii?q?jNwYOAQMBAQQBAQIBAm0cDIVLAQEBAwEBIUsbCQIYKgICJzAGAQwGAgEBgx4?= =?us-ascii?q?BgXQUD4s9m2WBLx+FKIRdBoEyAYtJF4FAP4ERJ4JrPoJhAQGEa4JXBKZWCYI?= =?us-ascii?q?Khg+MFQYbgguGKYNBiR+IeoMKgR6FH44mgWUiKIEuTSMVO4JshX2FFIVbIwM?= =?us-ascii?q?wkHIBAQ?= X-IronPort-AV: E=Sophos;i="5.60,382,1549929600"; d="scan'208,217";a="539064283" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Apr 2019 19:08:35 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id x3MJ8YHK006499; Mon, 22 Apr 2019 19:08:34 GMT To: Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" References: From: Flemming Andreasen Message-ID: <62f7a5fe-a78e-4c80-cc96-e73b18c12629@cisco.com> Date: Mon, 22 Apr 2019 15:08:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CD0390048F45B55C26CA224E" Content-Language: en-US X-Outbound-SMTP-Client: 10.118.10.21, rtp-fandreas-2-8814.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [rtcweb] Scope of SDP m= line 'webrtc-datachannel' 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: Mon, 22 Apr 2019 19:08:39 -0000 This is a multi-part message in MIME format. --------------CD0390048F45B55C26CA224E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks Please take a look at the proposed update below and let the authors and MMUSIC chairs know if you have any concerns with this change (by April 29). Thanks -- Flemming (as MMUSIC co-chair) On 4/21/19 7:12 PM, Christer Holmberg wrote: > > Hi, > > I am cross-posting this on multiple list, to make people aware of the > issue. However, I ask that any comments and discussions take place on > the MMUSIC list only. > > I found the following statement in section 4.5 of > draft-ietf-mmusic-sctp-sdp: > >    “NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel > >    Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol].” > > In addition, in the IANA registration of ‘webrtc-datachannel’ (section > 15.3), draft-ietf-rtcweb-data-protocol is referenced. > > To refresh everyone, draft-ietf-rtcweb-data-protocol defines DCEP (the > inband protocol for handling WebRTC Data Channels), and > ‘webrtc-datachannel’ is used in the SDP m= line when establishing an > SCTP association for such channel. > > However, both draft-ietf-mmusic-datachannel-sdp-neg and > draft-ietf-clue-data-channel use ‘webrtc-datachannel’ in the “m=” > line, and those drafts do not use DCEP. > > My suggestion to fix this is to modify the text in > draft-ietf-mmusic-sctp-sdp, to always use ‘webrtc-datachannel’ for > WebRTC Data Channels – no matter whether DCEP is used or not. > > I have created a pull request: > > https://github.com/cdh4u/draft-sctp-sdp/pull/15 > > Regards, > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------CD0390048F45B55C26CA224E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks

Please take a look at the proposed update below and let the authors and MMUSIC chairs know if you have any concerns with this change (by April 29).

Thanks

-- Flemming (as MMUSIC co-chair)

On 4/21/19 7:12 PM, Christer Holmberg wrote:

Hi,

 

I am cross-posting this on multiple list, to make people aware of the issue. However, I ask that any comments and discussions take place on the MMUSIC list only.

 

I found the following statement in section 4.5 of draft-ietf-mmusic-sctp-sdp:

 

   “NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel

   Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol].”

 

In addition, in the IANA registration of ‘webrtc-datachannel’ (section 15.3), draft-ietf-rtcweb-data-protocol is referenced.

 

To refresh everyone, draft-ietf-rtcweb-data-protocol defines DCEP (the inband protocol for handling WebRTC Data Channels), and ‘webrtc-datachannel’ is used in the SDP m= line when establishing an SCTP association for such channel.

 

However, both draft-ietf-mmusic-datachannel-sdp-neg and draft-ietf-clue-data-channel use ‘webrtc-datachannel’ in the “m=” line, and those drafts do not use DCEP.

 

My suggestion to fix this is to modify the text in draft-ietf-mmusic-sctp-sdp, to always use ‘webrtc-datachannel’ for WebRTC Data Channels – no matter whether DCEP is used or not.

 

I have created a pull request:

 

https://github.com/cdh4u/draft-sctp-sdp/pull/15

 

Regards,

 

Christer

 

 

 


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

--------------CD0390048F45B55C26CA224E-- From nobody Tue Apr 23 21:35: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 D4C1E1201B2 for ; Tue, 23 Apr 2019 21:35:27 -0700 (PDT) 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=ZetWJTo2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MIjWDT9C 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 39tFhR5Ij5Ps for ; Tue, 23 Apr 2019 21:35:26 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA02120106 for ; Tue, 23 Apr 2019 21:35:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4254E21B5A for ; Wed, 24 Apr 2019 00:35:25 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 24 Apr 2019 00:35:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=9Tqhl7vufNC5DRvsTVorwKotdXvr5YJ 7Lo40z0QA35o=; b=ZetWJTo2VUpNiRjTx5/xHtU73gMwKwcIr3aDbU1ZRnIISbC O1sZVRUH/mZPOMNvOkWWrjAT/U0dXzUi+tiwn10ZSm2QxRV5aMyF2FepDXyq4j89 SvDlJCuhg7CmP0pHEWQ9N+hxs/O4M9XHyjXFmxMx4ppEIkKi0BEWwGRERj8ukbLi +6jGBSySpbLJgH9gYobjCZ59xpRom0CUYUo8eiYuiAqgvfrfOky05QYAQRDgGRw5 ga6vIaBF2NnAbod0/Re477w48yHRXs2ixIp+yohpoOgOBILswCmAf7/6N9+oj3y/ InQgUqRHmMU4jXKqGl6SgnZV1n3Q9YXqiyjbfzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=9Tqhl7 vufNC5DRvsTVorwKotdXvr5YJ7Lo40z0QA35o=; b=MIjWDT9CKf8WfdcojIiqOf b4Ce1646RYEHcPOmKIpyABr/G7vUaH5WD8HpDmbgx01d3nAuyEm/awjPvmN29VbM ISWgxWUMItjulQxdCCFwbExhaxSSeDqb63blJObKTGQ/DPrp9j1j3cUYRyl64JEb AtTr4TBRgt+GfNw4w9BjHW5Ulj0SdysGKJzWznbIZirLqlAIKOFVTbJyaG88/QwH R0ppJ7p8Ix+JxKzRfAu0rBgn+PR9Cuq4wXwcS6wfjdFoj+95mt/EzmUQepyOHGCZ i5vvUkaqhIOnvq8zVW4uUAVuIq1H+30Gp5914zuG+CQkNSFRgWqpfSs2exPGmBbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeelgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8DCFD7C199; Wed, 24 Apr 2019 00:35:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1 Mime-Version: 1.0 Message-Id: <7b879787-78b3-4c4f-81c9-e78958b8597f@www.fastmail.com> In-Reply-To: References: Date: Wed, 24 Apr 2019 00:35:24 -0400 From: "Martin Thomson" To: rtcweb@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [rtcweb] Security-arch IdP determination issue/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, 24 Apr 2019 04:35:28 -0000 On Wed, Apr 10, 2019, at 04:00, Ted Hardie wrote: > In section 7.5 of the Security-arch draft, the document says: > > Authority: The authority [RFC3986 > ] at which the IdP's service is > hosted. Note that this may include a non-default port or a > userinfo component, but neither will be available in a certificate > verifying the site. > > Benjamin Kaduk raised a DISCUSS on this: > > 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. > > Given that we discover this via a .well-known location which is meant > to be deterministic, I went looking for the more general .well-known > advice on this topic. Turns out that the updated version in 578bis > has > this: > > > Typically, applications will use the default port > > for the given scheme; if an alternative port is > > used, it MUST be explicitly specified by the > > application in question. > > Obviously, our doc predates 5785bis, but given the discuss and that > advice, I think the right thing to do here is to drop the ability to > have a non-default port or to specify an alternate port. > > Is there anyone currently using this with a non-default port? > > Any objections to dropping this or preferences for specifying an alternate port? I hope that this also includes dropping the userinfo part, so that this is just the host portion (https://tools.ietf.org/html/rfc3986#section-3.2.2). Firefox does support the port number, but I'm not aware of anyone using it. As Cullen points out, getting a unique name is not the biggest barrier to deployment. You might even argue that there is a security benefit in that arbitrary ports can be used to assert identities. From nobody Tue Apr 30 11:05:16 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 515B21202F6; Tue, 30 Apr 2019 11:05:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <155664751524.7509.1436015996023149122@ietfa.amsl.com> Date: Tue, 30 Apr 2019 11:05:15 -0700 Archived-At: Subject: [rtcweb] Secdir last call review of draft-ietf-rtcweb-security-11 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, 30 Apr 2019 18:05:15 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits SECDIR review of draft-ietf-rtcweb-security-11 Reviewer: Nancy Cam-Winget Review result: Ready with Nits I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines the threat model and security analysis of WebRTC. There are a few normative clauses to suggest requirements, I think the document could benefit of having more normative requirements to make it a stronger standards track document. Otherwise, it reads more as an informational document. The following are general comments and suggestions (and editorial nits at the end): Section 3. Should it also be noted that as it (browser) has no purview to the actual application running, attacks from the application layer can still occur but is not in scope for WebRTC? Section 4.1 - The conceptual model is a bit confusing, as I think Entity can refer to both the webRTC server as well as the receiving client application? The notion is that the User is trusting the webRTC (client) application (Entity A) to send the media to another user, but really to the receiving application (Entity B). Perhaps model 1 has a typo where the Òtalk toÓ should be Entity B? - The paragraph following the conceptual models is a bit awkward. If I understand correctly, the intent is to state that the user believes Entity A when attempting to call Entity B, Entity A (the client app) could in fact also send it to Entity C? Which is valid, but the writing is awkward as the AÕs, BÕs and CÕs are not explicitly stated as such or at least from the end userÕs viewpoint. - ÒIn either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goesÓ Is ÒwhoeverÓ meant to be the webRTC application controlling media paths? That should be clarified - ÒÉconsent to access local devices is largely orthogonal to consent to transmitÉÓ It should be both consent to local devices and the deviceÕs resources, unless you mean Òlocal devicesÓ as in camera and microphone; but I think processes and stored or cached files (e.g. other resources) need to be considered too. § - Òconsent to send network traffic is about preventing the userÕs browser from being used to attack its local networkÓ This is true, though, I think you are inferring that the network traffic is enforced to be encrypted, which IÕm not sure is always the case; so I would think it is up to the browser to ensure that this is the case unless the browserÕs policy has made an exception Section 4.1.2.1 ÒÉbug my computerÓ should be clarified. I think there are at least two dimensions to the ÒbugÓ, being it has ÒfreeÓ access to my resources and it can actually potentially ÒlistenÓ to my calls; it could also potentially override the use of my resources. The last sentence on the paragraph ÒNote that question of consentÉ.Ó, the note makes sense, but I am not sure how the last clause ÒÉ.the site is not listening inÓ, can you clarify this? Section 4.1.2.2 ÒÉthe need for a second consentÓ, perhaps it is the need for a ÒdistinctÓ consent as there may not be a previous consent? By ÒdistinctÓ I mean that it is a different type of consent than what may have been granted to the car manuf (in your example) from getting my geolocationÉ.or perhaps I missed the ÒfirstÓ consent type. The last sentence of the paragraph is difficult to parse. I think it is asserting a requirement that the GUI used to launch the call must show the call status (active, continuing, stopped)? This section eludes to granting ÒcallÓ access only for the duration of the call and the access should be limited (Òjust because I want some information on a car doesnÕt meanÉ.Ó); the attack vector should be better highlighted. As I also believe that the browser can only grant the full client application access, so for the duration of the call, it can very well be that the app can get access to my resources beyond just the call (audio only vs. audio + videoÉ.) Section 4.1.3 - The countermeasures can also be combined (e.g. consent is only given to a given user for each call, as well as also having the appropriate keying material). It is subtly eluded to in the 2nd to last paragraph but doesnÕt consider that it can be done for all calls. Section 4.1.4 - It should also be noted that weaknesses in the HTTPS stack can also be exploited (weak authentication or key establishment use) by an attackerÉ.and perhaps should be a MUST enforce strong mutual authentication and key management. Section 4.2.3 - As IÕm unfamiliar to ICE/STUN, IÕm not sure what checks are referred to in ÒÉunsafe to completely remove the requirement for some checkÓ, this should be clarified. Not sure (in the succeeding sentence) if there is a forward reference to proposed checks or if they are listed elsewhere? Section 4.3.1: since the draft is listing requirements, ÒÉ.exchange mechanism imperative forÉÓ The ÒimperativeÓ should be normative ÒMUSTÓ? Section 4.3.2: who is the Òremote endpointÓ? Editorial nits: Section 1. It may be useful to describe why it is Òimmediately apparentÓ that new security challenges resultÉ..suggest remove ÒimmediatelyÓ. Section 4.1.1 (last sentence in the 2nd to last paragraph) is missing a toÕ: Òsophisticated attack would be open up aÓ Section 4.1.3 : ÒNow that we have seen another use caseÓ Seems odd or superfluous. Suggest to just remove that clause or ÒWith the aforementioned use cases, we can startÉ.Ó Section 4.2.1: as it is a first reference, title should call out ÒInteractive Connectivity Establishment (ICE)Ó, same for STUN (and STUNÕs reference, RFC 5389) should be called out. Section 4.2.2 SRTP as a first reference should have its full reference to match the acronym and TURN TCP should have reference too Section 4.2.3 RTCP needs a reference? Section 4.3: is it Òa problem from the SIP worldÓ or Òa problem familiar to the SIP worldÓ? - Extra is Òcalling service is is non-maliciousÓ Section 4.3.1: ÒinÓ should be removed ÒÉ.if end-to-end keying is in usedÓ Section 4.3.2.1: ÒOne natural approach is to use É.Ó, natural approach to what? I think it is to mitigate the during-call attack only?