Re: [Captive-portals] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04

Erik Kline <ek.ietf@gmail.com> Wed, 13 May 2020 17:36 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 159B73A0C4A; Wed, 13 May 2020 10:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 XRLnh4_dXScW; Wed, 13 May 2020 10:36:12 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 049CB3A0C31; Wed, 13 May 2020 10:36:11 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id k110so75293otc.2; Wed, 13 May 2020 10:36:11 -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:content-transfer-encoding; bh=J98nTqzFNnMZax/5VzMQKI30a9ZE9ixWD1qTeTRg9zg=; b=pVWkhZLdx9N0wepWSxZY3Vpw5BriyO29v6j7q9CWUUwT4Km2s89ckBfUKAyPiOG6IO c1VHZXbYOAGnoI6YkvnwE8NYb+/+5JHOZjdP+YT64C9pkMVcnYG6lPJwVeJ/lvVNpPiE WShBpaMAZA1LbgnrkqPyVY4VBqP9V6LuVQWYGU0mMIasE1pVLSsENZhyzlPoEG1kVwJr YzhX6mdAPBoCxTkYaEnvm6iEChPf8eh2shgeLtk/w3EtWiKhLTd3uyF4+1kBG8C+RvxZ W3lBjk5/04tPGE1ACJq8Li3fjPnhcy2lX3bSmCba5JG9qIGJnhvh8eHQ0rxYLx9ZCt4g s/vg==
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:content-transfer-encoding; bh=J98nTqzFNnMZax/5VzMQKI30a9ZE9ixWD1qTeTRg9zg=; b=r69EcubqqAEt2l4uJgXkuyJtEFlQR7ey1DAhLOPEJW+/o4RHyV31BfenDBW4mj6S4N Z+is04Q9cryweR/aH6IuipQx9+6kLto9Demf3XIc5m/C9UNwx7aTlEIybpGTzO+MqmD1 iL0S7OFtlG/CQg+7LE4+wrO1dgUF8qrvk6lSrMk6Hzo/uJC9oHkseF/CQaZvOJ6nniq+ J0t8X4x2+DaflctwdFYjL3DtgV7rYo9bpPHio0xVx0Y3uDZ/1NqnerXL4UMTev0HymHb U23Ki2qhhW2zBcTbomFyRKMrn4h3oo8HJCUN+ktisAgKC/0MaCNNvB1+Wl421U+KCa4Q Mf1Q==
X-Gm-Message-State: AOAM531A7fo7wlhSKkydqI6b4qTqkviiJOKGyIAQwBHcTMF3hTJVuIDe j6kzZhxpnr7Wad4Gpc5ic4jYGqszG9o5/sZfejM=
X-Google-Smtp-Source: ABdhPJxkxb0eL2pFu470rcAUHNQxhPTzXsOsNjCOsXF/8ZcWRmM3XjZH4+3IQh5dNagAwvOJbCPd2JSFg41L1MOdahQ=
X-Received: by 2002:a9d:7988:: with SMTP id h8mr423747otm.191.1589391371107; Wed, 13 May 2020 10:36:11 -0700 (PDT)
MIME-Version: 1.0
References: <85873c75-0d4d-4ec5-91a1-a28b92378ec3@www.fastmail.com> <20200511045150.GI27494@kduck.mit.edu> <CAMGpriW2-1FrmNz1egtHd=_ZdDtMhK6QMGAawsDO=EcCPsyavA@mail.gmail.com> <CAMGpriXpc=2xnya2Uy3zU_yv2fcmPs-qOP5iGxG9uWA9RwicnA@mail.gmail.com> <CALaySJLbdkzHVKRnemShAdTs4u+GHrSW39vdVKbYrLfFRXdxsg@mail.gmail.com> <CAMGpriVE5moixhVVnQZ79UKP0gZEJcT8aeue1JsUu9HTkrD=7A@mail.gmail.com>
In-Reply-To: <CAMGpriVE5moixhVVnQZ79UKP0gZEJcT8aeue1JsUu9HTkrD=7A@mail.gmail.com>
From: Erik Kline <ek.ietf@gmail.com>
Date: Wed, 13 May 2020 10:36:00 -0700
Message-ID: <CAMGpriUGQo8ayJu9utoQFP+NjKPwQy5mOb1LaZL9RaLsdJFvMQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Martin Thomson <mt@lowentropy.net>, Erik Kline <ek@loon.com>, draft-ietf-capport-rfc7710bis.all@ietf.org, captive-portals <captive-portals@ietf.org>, IETF SecDir <secdir@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/UzEMwvr1XcSZJl2-7pTrqToZkDU>
Subject: Re: [Captive-portals] Fwd: [Last-Call] Secdir last call review of draft-ietf-capport-rfc7710bis-04
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: Wed, 13 May 2020 17:36:14 -0000

-05 uploaded, but I see now I need to do an -06 for the IANA comments.

On Wed, May 13, 2020 at 10:29 AM Erik Kline <ek.ietf@gmail.com> wrote:
>
> Forthwith!
>
> On Wed, May 13, 2020 at 9:29 AM Barry Leiba <barryleiba@computer.org> wrote:
> >
> > Erik, is there a revised I-D coming for this?
> >
> > Thanks,
> > Barry
> >
> > On Mon, May 11, 2020 at 1:09 AM Erik Kline <ek.ietf@gmail.com> wrote:
> > >
> > > Gah! Sorry, I didn't mean to imply that the conversation should be
> > > moved there.  Only pointing to text-in-progress for your review.
> > >
> > > On Sun, May 10, 2020 at 10:08 PM Erik Kline <ek.ietf@gmail.com> wrote:
> > > >
> > > > For the record: trying to improve text over on
> > > > https://github.com/capport-wg/7710bis/pull/31 .
> > > >
> > > > On Sun, May 10, 2020 at 9:52 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > > > >
> > > > > [adding back some lists]
> > > > >
> > > > > -Ben
> > > > >
> > > > > On Wed, May 06, 2020 at 02:37:39PM +1000, Martin Thomson wrote:
> > > > > > What does "extra cautious" mean?  I assume that this is intended to apply to what a human might do, further implying that there is a role for a human decision.
> > > > > >
> > > > > > None of this architecture requires the involvement of a human in this way. Nor do I think that there is any meaningful distinction between an opaque string of characters (that might include confusables) and an opaque string of digits.
> > > > > >
> > > > > > I appreciate the sentiment here, but the fundamental problem is that once you decide that this information is not from the network, it is useless. If it is from the network, it is only of limited use. That use cannot depend on the identity of the server, so there is no value in any sort of caution.
> > > > > >
> > > > > > On Wed, May 6, 2020, at 13:36, Benjamin Kaduk wrote:
> > > > > > > [My unicast reminder got a unicast reply; forwarding to someplace at least
> > > > > > > vaguely useful.]
> > > > > > >
> > > > > > > -Ben
> > > > > > >
> > > > > > > On Tue, May 05, 2020 at 07:57:14PM -0400, Rifaat Shekh-Yusef wrote:
> > > > > > > > Thanks for the reminder Ben.
> > > > > > > >
> > > > > > > > Erik,
> > > > > > > >
> > > > > > > > Since this document allows the use of IP address to represent the portal
> > > > > > > > URI, I think it would important to add some text that explicitly states
> > > > > > > > that the user might be presented with an IP address instead of the hostname
> > > > > > > > of the API, and in that case the user should be extra cautious when this
> > > > > > > > happens.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >  Rifaat
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, May 5, 2020 at 7:30 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > > > > > > >
> > > > > > > > > Hi Rifaat,
> > > > > > > > >
> > > > > > > > > I just wanted to follow-up and check that you had received Erik's question.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > >
> > > > > > > > > Ben
> > > > > > > > >
> > > > > > > > > On Sun, May 03, 2020 at 02:58:29PM -0700, Erik Kline wrote:
> > > > > > > > > > Rifaat,
> > > > > > > > > >
> > > > > > > > > > Thanks for your reading of the document.
> > > > > > > > > >
> > > > > > > > > > The security section has a paragraph that begins:
> > > > > > > > > >
> > > > > > > > > > """
> > > > > > > > > >    An attacker with the ability to inject DHCP messages or RAs could
> > > > > > > > > >    include an option from this document to force users to contact an
> > > > > > > > > >    address of his choosing.  As an attacker with this capability could
> > > > > > > > > >    simply list himself as the default gateway (and so intercept all the
> > > > > > > > > >    victim's traffic); this does not provide them with significantly more
> > > > > > > > > >    capabilities, but because this document removes the need for
> > > > > > > > > >    interception, the attacker may have an easier time performing the
> > > > > > > > > >    attack...
> > > > > > > > > > """
> > > > > > > > > >
> > > > > > > > > > Do you have any specific ideas for what text might be added to clarify
> > > > > > > > > vis.
> > > > > > > > > > your concern?  Would a sentence that captures your "the use of TLS and
> > > > > > > > > > presenting the identity in the certificate might not be of much help"
> > > > > > > > > > observation suffice?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > -Erik
> > > > > > > > > >
> > > > > > > > > > On Fri, 1 May 2020 at 05:10, Rifaat Shekh-Yusef via Datatracker <
> > > > > > > > > > noreply@ietf.org> wrote:
> > > > > > > > > >
> > > > > > > > > > > Reviewer: Rifaat Shekh-Yusef
> > > > > > > > > > > Review result: Has Issues
> > > > > > > > > > >
> > > > > > > > > > > Since the use of IP address literal is not forbidden by this document,
> > > > > > > > > > > what if
> > > > > > > > > > > an attacker with the ability to inject DHCP messages or RAs uses this
> > > > > > > > > > > option
> > > > > > > > > > > to force the user to contact an IP address of his choosing? In this
> > > > > > > > > case,
> > > > > > > > > > > the use
> > > > > > > > > > > of TLS and presenting the identity in the certificate might not be of
> > > > > > > > > much
> > > > > > > > > > > help.
> > > > > > > > > > >
> > > > > > > > > > > I think this case should be discussed in the security consideration
> > > > > > > > > > > section.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > last-call mailing list
> > > > > > > > > > last-call@ietf.org
> > > > > > > > > > https://www.ietf.org/mailman/listinfo/last-call
> > > > > > > > >
> > > > > > > > >
> > > > > > >