Re: [Captive-portals] AD review of draft-ietf-capport-rfc7710bis-03

Erik Kline <ek.ietf@gmail.com> Sun, 26 April 2020 04:37 UTC

Return-Path: <ek.ietf@gmail.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C23A00C1; Sat, 25 Apr 2020 21:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 eHNn5Lr2OCl1; Sat, 25 Apr 2020 21:37:41 -0700 (PDT)
Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 C8CDF3A0B96; Sat, 25 Apr 2020 21:37:40 -0700 (PDT)
Received: by mail-oo1-xc32.google.com with SMTP id q204so3105431ooq.1; Sat, 25 Apr 2020 21:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TaeTWxbMC8s6X+H9y9Xr36giSi/HayYZ11EskpK6nDI=; b=FGQVDOTV52yXsiHTkrQ7yPPi65lFACSVAzToix8Pw8YmFC+BHu/9hUzgyD/Gnhnmm3 vTY4lAHVfKBBx1GTWDvtsf6wP4kIh6GUutPzPmxvJnn3+nVcHP78gNZaTIHGMQS/KQu4 yQEqywsMqg197wVKlJS3SoUpl9gsbKnMu3ccoLKGBcO458/5b4s264ok2rz9gi2YZwkb /BtciA/f7Q8Z0BFM/p0vs7iutkhdw3ElCN6diB0gcgTERB9/frbryb5dGBTjUosZrULl XBn5GDfFg15xb/31+/ajfBg9AaG0bQx4J3CeNXmVOQgz29vqezzjyjMT0z1jnNcwAeGe Tm7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TaeTWxbMC8s6X+H9y9Xr36giSi/HayYZ11EskpK6nDI=; b=rE6rdI/oHdfaabVq1M76K3nX5EX5nSYcpyoPoxApJ908BHW+nTLYy+QLXsafA4WHi9 qFi+cDEEuhN2SGU7vbSHLXsI5GfG/XhOeXjtaRTpTjXwsrmkNFYUJmNa8hrxACZxsW9b FCb0UX9IxYiBny8pp0hw3LcQS9twUWiodDh8yl+GNDOyVJuHnlJv/p1aIDdHTisdPM1U BX0DHU60cpXfXoLJuUnCP5z7uAftEPoZtcsK1pjuZGmPkaXLoewczcN7Unn4Kezkg6p2 8UzlVhYwqVF1X8hvp1FZpPfqNTYOPkcXoDNUtSCPm8N/n3Buq+7q7/g4zVHC++zq2Gy7 1Lxg==
X-Gm-Message-State: AGi0Pua2bMulOg6jzJEv/GMYNidXkjuftSvDRptY5RDExLrzk3umLqtn q30rTDoIerc8vJT5E9Bfs6m57jKjcs1tL1xZdBs=
X-Google-Smtp-Source: APiQypIg2xpJzSwslV3UVChQmEy+wzJEKEE83pJY8cOCvOiYPAPjoqscmm2Q0epbXUud1T9IVpZbRWjJirMi/tLP5Tg=
X-Received: by 2002:a4a:d355:: with SMTP id d21mr2964055oos.66.1587875860020; Sat, 25 Apr 2020 21:37:40 -0700 (PDT)
MIME-Version: 1.0
References: <CALaySJ+tmuU_DZU6ZvC4RsnuRJAVfLgYyw_=RYbA6XBcgvgKJQ@mail.gmail.com>
In-Reply-To: <CALaySJ+tmuU_DZU6ZvC4RsnuRJAVfLgYyw_=RYbA6XBcgvgKJQ@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Sat, 25 Apr 2020 21:37:29 -0700
Message-ID: <CAMGpriU0LbpZC+57hO-MAgjXq-nMTJgWSTWh1ycPjU1hCOsrpg@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: "draft-ietf-capport-rfc7710bis.all@ietf.org" <draft-ietf-capport-rfc7710bis.all@ietf.org>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000095811505a42a2836"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/Ti5ilnOzC8Iwf9GNVwvUdOk_14g>
Subject: Re: [Captive-portals] AD review of draft-ietf-capport-rfc7710bis-03
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 04:37:44 -0000

Barry,

Thanks for the prompt review.

On Thu, Apr 23, 2020 at 9:18 PM Barry Leiba <barryleiba@computer.org> wrote:

> Good work on this, folks: a nice improvement on 7710, and let’s hope for
> wider deployment.  Some comments below; I think we should have a quick
> revised I-D before we go to last call, mostly because of the comment about
> the diagrams in Sections 2.1 and 2.2, though most of the comments are
> editorial.
>
> — Section 1.1 —
> Please use the new BCP 14 boilerplate from RFC 8174.
>

Fixed in the repo (commit
<https://github.com/capport-wg/7710bis/commit/488e6b5df49b8a308d425a4911fd49613f7dd590>
).

— Section 2 —
>
>    negotiation ([RFC7231] Section 3.4), captive portals implementors
>
> Make it “captive portal implementors” (or “implementors of captive
> portals”).
>

Fixed in the repo (commit
<https://github.com/capport-wg/7710bis/commit/7f1d8a27e3a33e62aa7f161d0cbf02be084c53a6>
).

It looks like the two consecutive paragraphs that both begin with “A
> captive portal” have some duplication with regard to the absence of
> “Accept” headers; please check that and adjust if you agree that some
> information can be merged or removed.
>

Filed issue #17 <https://github.com/capport-wg/7710bis/issues/17>.

   The URI SHOULD NOT contain an IP address literal.
>
> Why not, and how does it maintain interoperability to have this as SHOULD
> NOT, rather than MUST NOT?
>

Filed issue #18 <https://github.com/capport-wg/7710bis/issues/18>.

   Networks with no captive portals MAY explicitly indicate this
>    condition by using this option with the IANA-assigned URI for this
>    purpose (see Section 4.1.1).  Clients observing the URI value
>    "urn:ietf:params:capport-unrestricted" MAY forego time-consuming
>    forms of captive portal detection.
>
> Two things here:  I don’t see that the forward reference to 4.1.1 adds
> anything, as the only thing that section does that’s useful here is to
> repeat the URI that you’re already including.  And why
> “capport-unrestricted” rather than “capport:unrestricted”?  The latter
> would seem more in line with how “ietf:param” URNs are generally done.
>

Filed issue: #19 <https://github.com/capport-wg/7710bis/issues/19>.

— Sections 2.1 and 2.2 —
> Why aren’t the diagrams for the two in the same format?  And neither
> explicitly says what the length of the “len” field is.  In the v4 version,
> one has to guess that it’s the same size as the “code” field, 1 byte.  In
> the v6 version, one can look at the diagram.  I suggest making the diagrams
> the same format (calibrated with bit/byte markings) and explicitly
> specifying in the text the size of the “len” field.
>

Filed issue: #20 <https://github.com/capport-wg/7710bis/issues/20>.

— Section 3 —
>
>    Specifically,
>    URIs learned via any of the options in Section 2 should take
>    precedence over any URI learned via some other mechanism
>
> Given the MUST that comes before this, I think the word “should” ought to
> be removed, to avoid any confusion.
>

Filed issue: #21 <https://github.com/capport-wg/7710bis/issues/21>.

— Section 5 —
> Purely a judgment thing here, so do what you hink is best: it seems to me
> that the Security Considerations in 7710 rather buried the lede.  The
> bottom line is that by removing the MitM interception, this mechanism
> improves security by making the portal and its actions visible, rather than
> hidden, and that vulnerabilities that exist here also existed before and
> are now lessened.  I would say something like that up front, in a new first
> paragraph, and then continue with the existing text as is.
>
> But, again, as you judge best; this is just a comment.
>

Filed issue: #22 <https://github.com/capport-wg/7710bis/issues/22>.

—
> Barry
>
>