Re: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

Martin Thomson <> Sun, 01 March 2020 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E5943A0B20 for <>; Sun, 1 Mar 2020 15:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=JZNtcWum; dkim=pass (2048-bit key) header.b=R5lJuCgq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wSpgaWt6rYq3 for <>; Sun, 1 Mar 2020 15:07:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 257793A0B21 for <>; Sun, 1 Mar 2020 15:07:21 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 4D11F69F for <>; Sun, 1 Mar 2020 18:07:20 -0500 (EST)
Received: from imap2 ([]) by compute2.internal (MEProxy); Sun, 01 Mar 2020 18:07:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ClKdRCxgVCUFMMCWPAnp8GsL0hi5p2g bBUGQAeptLhc=; b=JZNtcWumaGvT0GT4ln4lLoAtC0gLFjstI201nRB8wZ6dMWv CnLg3rENWBP+0B+YbVOf88eCm/R5Ko96UhMTSdgrCD9iYy5B7O2vclp1b/ug7raH sZYk+7Og9aCT58bUvRvKfY5wRlpBtDPNQ+H9nnEjLc+JIJ/bh/7JcnDoce1ofKyz KXPvoeg8xa52jBMn9xasFgtAIY7stfEC5gFTfJE+tb0VNqqBY6347/wUe1uRzuop Aq+BgwfK94zHcV1nfZU5DNnqKZPiGhF/Vv9YI03U3z04bNafTAgCeUJ/T8s5e7HT tk5w0tMSj7GCKYkja7gfTrv7phzuu2ZAAeB/IvA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=ClKdRC xgVCUFMMCWPAnp8GsL0hi5p2gbBUGQAeptLhc=; b=R5lJuCgqBtpgIowPmbPUA0 Ald1TqrPy9Cii2twsPKHA7VdYkDaCQDQdjjtz+OM57lrGLh0ef71cep3Vj82Yx4P KvknrcF5sJdLdfdUQsASn6L6grsjW0fr0IbKyg05uO/MBcNIm55vww0r7++li9Ez j8hkwsd45rAE1aF9tmwDqfXuzyZLMNTqAcyqEnJ9Kog54NvpSlt45/BUhDB/u2cA 3ZnWBsrz72LIkcbbJwIh10BG+L6SqId1F9ss2nGPXh7lJqtllAjF0Pam/mHzZ6tV AZltke9pZpgC6I/aGi5a+GQLAc1+I2o43F4Xt4W5WkFw5320AwMAnYurzRb/0Y/A ==
X-ME-Sender: <xms:J0BcXr9VjRJrCjR6_YcWu_2ZsEu5nIGfMXt5MpNxUYnATIE0LgLDLw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtfedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghn thhrohhphidrnhgvth
X-ME-Proxy: <xmx:J0BcXhBOqYDYeHWF9x51kZb7xUyVfSjTtBwIpI1eOQ5IYyB4-8gSHw> <xmx:J0BcXhAGygRAzCfMXavDiL8PQOkSam76bRRepa_F0OzGUak-tOmQFQ> <xmx:J0BcXhJURkYvmxIm3fRvD8PCwkEoXJiAKqOZ0pl8tOyx6Lj2ifNB1Q> <xmx:J0BcXpGMfuDDaw3OnRSWNdLpw4HX_JCK_boSWirD0esOGxicSZPgBA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 69AD3E00AC; Sun, 1 Mar 2020 18:07:19 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Mon, 02 Mar 2020 10:07:00 +1100
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Mar 2020 23:07:24 -0000

I have two minor comments of my own to add:

The prioritization section (S3) suggests that conflicting sources of URIs be prioritized.  However, this specifically avoids stating any preferred order.  Rather than saying we don't specify it, how about explicitly letting implementations decide?

   URI precedence in this situation is not
   specified by this document.
   Implementations can select their own precedence order.

The security considerations (S5) includes this text:

   Operating systems should conduct all interactions with the API in a
   sand-boxed environment and with a configuration that minimizes
   tracking risks.

I would suggest that this is a bad idea.  I personally would recommend against it.  It might have been wise in the past when HTTPS rates were lower, but 2020 is not 2014.  Captive portals occasionally do things like access SSO services (Facebook being one) and a sandbox often doesn't have access to the same persistent storage as a genuine browser.  Asking people to enter passwords in a sandbox can have the effect of building insensitivity to phishing attempts; especially when that sandbox could have limited anti-phishing capabilities compared to a full-fat browser.

I realize that this is in tension with the desire to minimize tracking of people across points of physical connectivity.  I think that the best we can do is recognize that tension and let people reach their own conclusions.

On Mon, Mar 2, 2020, at 09:49, Martin Thomson wrote:
> Hi everyone,
> The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready 
> for publication.
> Please send comments on this before 2020-03-16.
> Comments supporting publication as-is are valued as much as comments 
> highlighting issues.
> Note that Erik is an editor of this document, so he won't be assessing 
> consensus.
> _______________________________________________
> Captive-portals mailing list