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--