[rtcweb] Security-arch IdP determination issue/DISCUSS

Ted Hardie <ted.ietf@gmail.com> Tue, 09 April 2019 17:59 UTC

Return-Path: <ted.ietf@gmail.com>
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 <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietfa.amsl.com>; 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 <rtcweb@ietf.org>; Tue, 9 Apr 2019 10:59:56 -0700 (PDT)
Received: by mail-it1-x134.google.com with SMTP id u65so6461704itc.2 for <rtcweb@ietf.org>; 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 <ted.ietf@gmail.com>
Date: Tue, 9 Apr 2019 10:59:29 -0700
Message-ID: <CA+9kkMCUVwC-uRe_pR2_M2DgNDfxCNNRihRApPzCji4PaeJtKg@mail.gmail.com>
To: RTCWeb IETF <rtcweb@ietf.org>, Sean Turner <sean@sn3rd.com>, Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="0000000000007551b605861cb835"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/8dtCkSeXWUsb_y2SRyFlbQ5r93w>
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 <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 18:00:00 -0000

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