Subject: [rtcweb] Security-arch IdP determination issue/DISCUSS

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Apr 2019 10:59:29 -0700

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

Authority:  The authority [RFC3986
<https://tools.ietf.org/html/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
<https://tools.ietf.org/html/draft-nottingham-rfc5785bis-09#page-2> 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

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 9 Apr 2019 14:17:47 -0700

> On 9Apr, 2019, at 10:59, Ted Hardie <[email-masked]> wrote:
> 
> 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.
> 
> Any objections to dropping this or preferences for specifying an alternate port?

I’m aware of small deployments using this. I don’t recall if they are using default ports.

But in general no objection against specifying an alternate port.

Best
  Nils Ohlmeier

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Apr 2019 18:38:14 -0600

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 <[email-masked]> wrote:
> 
> Authority:  The authority [RFC3986 <https://tools.ietf.org/html/rfc3986>] at which the IdP's service is
> 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 <https://tools.ietf.org/html/draft-nottingham-rfc5785bis-09#page-2> has this:
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 24 Apr 2019 00:35:24 -0400

On Wed, Apr 10, 2019, at 04:00, Ted Hardie wrote:
> 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 
> 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.
> 

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.