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

Erik Kline <ek@loon.com> Mon, 04 May 2020 04:09 UTC

Return-Path: <ek@google.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 AB59B3A0BCB for <captive-portals@ietfa.amsl.com>; Sun, 3 May 2020 21:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.249
X-Spam-Level:
X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.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 FnCbEvD7CUS5 for <captive-portals@ietfa.amsl.com>; Sun, 3 May 2020 21:09:43 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 0C3823A0BC8 for <captive-portals@ietf.org>; Sun, 3 May 2020 21:09:42 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id l5so8521368ybf.5 for <captive-portals@ietf.org>; Sun, 03 May 2020 21:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=+DPsAvL0Mals3xEZW0zZl2v3I2E9FANiWrqUorhedjU=; b=gYGJ2odjl2Nc0Bty6KJy7Col19vP4wF6Dq18ApRb/IvzkyrScp5zcutFLlMi9jEFTx d9TbVzSgIu4KUC0z5sjYYvkkOw26egcuM6zNwlvpIyoy2vmRubQuFNNb+ToULFLRhuGB Go4WJDhb+Ur9UHnUl4SYD2uQEZRsxVDB/oplo=
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:reply-to :from:date:message-id:subject:to:cc; bh=+DPsAvL0Mals3xEZW0zZl2v3I2E9FANiWrqUorhedjU=; b=uI+6p0tmE7GpQYieem051xh4Ure6TSQdNBblzqlh2E1cfjx2eo7SBlq1U3kwAoyrtS v8evh8vLgAqCJ6xb+wrPNh4ycxpI3ujESk56YEvX6AHJ7B/xNM5NnegzBKrJ7BTmrAzs 7tLuGD9NJ+PdIjSyRREIrc9h13xus4L+oitwOg/bMLXkeXU5Yo7USHPxKVgJ4k8hfg6T n7i37IfAkjscH7ssTqt3zEc7t0QjOoD9E8V7zvzJ3h/hLfMkfUDW5F+J7C629lpcnge6 PTNgePTGCiKm3s/JsTGTKY2hoJKrDRd9RYrbbHhtbIBDiQ46QhKC2gXrw3EgAzw/bSRU 2UHg==
X-Gm-Message-State: AGi0PuapPk0qfSVz6mIiY4/gkaAoIbxv/lee38SwUhxDML+LuwITKdHa RBfmi4ZG1X/7JpxiXrMlHk59KiEPq2dNk1EpBZBU//yC77lwlQ==
X-Google-Smtp-Source: APiQypIEIJpOxmtWJDwkSRofSYo1kXqo7fvDXdt27N9qFgnlkj3h8aiorwMI47ub73NfD4SAy66JBwwZiSVk1CFlGdo=
X-Received: by 2002:a25:6c08:: with SMTP id h8mr9490389ybc.345.1588565381596; Sun, 03 May 2020 21:09:41 -0700 (PDT)
MIME-Version: 1.0
References: <158833501993.21190.4904257765699741589@ietfa.amsl.com> <CAAedzxpnruRmqdqfHXnxTOhDWQ705pOqw8NiNMCtR2vOZKv9NA@mail.gmail.com> <a060ae05-faaa-41f5-ae79-24e6c375a6ee@www.fastmail.com>
In-Reply-To: <a060ae05-faaa-41f5-ae79-24e6c375a6ee@www.fastmail.com>
Reply-To: ek@loon.com
From: Erik Kline <ek@loon.com>
Date: Sun, 3 May 2020 21:09:29 -0700
Message-ID: <CAAedzxr-dbzQiara1tEdWeRDsGCtCm+hz0JU0ZXn3F2oJ85CAw@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: captive-portals <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000463c1605a4cab313"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/V8frIiZcEcJ_dPPMd1Kiq4FOY8I>
Subject: Re: [Captive-portals] 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: Mon, 04 May 2020 04:09:45 -0000

Perhaps a reference to https://tools.ietf.org/html/rfc3756 as well as the
security considerations sections of 2131, 4861, 4862, and 8415.

I'm capturing notes in https://github.com/capport-wg/7710bis/issues/30 .

On Sun, 3 May 2020 at 17:09, Martin Thomson <mt@lowentropy.net> wrote:

> I think that the standard assumption is that we can equate the ability to
> send a DHCP response or a RA with control of the network (or at least those
> aspects of the network upon which clients rely on DHCP/RA for).  I don't
> know if that assumption is written down in a place we could cite it, but if
> it were, I would suggest a citation.
>
> On Mon, May 4, 2020, at 07:58, 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..
> > >
> > >
> > _______________________________________________
> > Captive-portals mailing list
> > Captive-portals@ietf.org
> > https://www.ietf.org/mailman/listinfo/captive-portals
> >
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>