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

Martin Thomson <mt@lowentropy.net> Mon, 04 May 2020 00:08 UTC

Return-Path: <mt@lowentropy.net>
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 7F3D43A0985 for <captive-portals@ietfa.amsl.com>; Sun, 3 May 2020 17:08:53 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=KRjYKxQt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EZCEdhcg
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 du-K-phrtBz1 for <captive-portals@ietfa.amsl.com>; Sun, 3 May 2020 17:08:52 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0141D3A097A for <captive-portals@ietf.org>; Sun, 3 May 2020 17:08:51 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 398325C0183 for <captive-portals@ietf.org>; Sun, 3 May 2020 20:08:51 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 03 May 2020 20:08:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=hW5eyRA4makUs2zlnWid8dgXr6mR/Oi vZgeT7J74npM=; b=KRjYKxQtm0jLtLmT7MO4aR3/XBBm8esiGlA8URQwOTlk3Ns wOHIbjUXcU8K0bPxq1I6H5rnaGq+S4cSENIDsowWH0Kl9sLCG+7x3Ctny9bB36TY kLSyYB//x+h7k9s4/v4UZkijnq9gWoMdPsRJtovWgUYGLT3RjoK0U4GnL588q6su EqVqGGfm8ZV7S6hCLg5fGWdmT0R7HnqgsiLVnmaH9Q4xYMw/f9+Zn826XzXGzYuT 9D75/UV2GbXk0uY+GcxQYPCCumF4rWhxFo8OvnT8jyawAwM5EUJOE0tdHyZi356X QDw8H4xufV99bQ6TGYsXdCJUKEIg4Khb4OFGsDQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=hW5eyR A4makUs2zlnWid8dgXr6mR/OivZgeT7J74npM=; b=EZCEdhcg2h0qxdW7sgEaQG VWzUKkXSaSNXND3zxzkJhVFU5u6Dnfs1l4O6FMX2X5b6rFh/tqY0NyA9/4LMcBzT wwJ1y8mHuwByunrgUZb45sTt+4xAMJNGaGNC0iK93s/Tbdt0TqRhgkfhFniSM/Sl eHFg1rqVhJJ/cpmmfabv6HHe/qzASL/tQ7U2rwg1UF5fOcWNTfK4b7bifaYlH76K ao3jOeCLoYN05C0p/xgoi73RIBnpkE2yAX9p/KYthRLUppIz2hjKtToZxdpJXWGz D6gmX/XRBzVZ4gBzcJHxJGbLR7zUi4jiGFqjvuG0Wr3uPwKZgMqNLWIgdmeNkACQ ==
X-ME-Sender: <xms:El2vXmNrcqURFCfG5sXTfi_2KkSYKOQ652OGtfaBGltfGCMKvhvJGg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeefgddvlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepleefudfgleegiefgueevle dujeejuedtleegvdetheeuvefhvdehgfegueffiedvnecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:El2vXuDA6DzzCK54gQasYxKuwUktRfxtZq5438rrWGZL0WRmmz-Tkw> <xmx:El2vXgN2hA2_DAOXNSnpmsJ6LSIG3aC2Px1nel7jENp5RnhaGuc9lQ> <xmx:El2vXjwB34p-1lYJyEO3zmepRy3nWgcslK6gfuP_g1jCWyOgz6CZNQ> <xmx:E12vXlob8K0RJQXqNnyU5Y6NAXtNJjzxUutuR-nZ5Ip6woOjlGqjEg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93D7FE00FA; Sun, 3 May 2020 20:08:50 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <a060ae05-faaa-41f5-ae79-24e6c375a6ee@www.fastmail.com>
In-Reply-To: <CAAedzxpnruRmqdqfHXnxTOhDWQ705pOqw8NiNMCtR2vOZKv9NA@mail.gmail.com>
References: <158833501993.21190.4904257765699741589@ietfa.amsl.com> <CAAedzxpnruRmqdqfHXnxTOhDWQ705pOqw8NiNMCtR2vOZKv9NA@mail.gmail.com>
Date: Mon, 04 May 2020 10:08:31 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: captive-portals@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/VYZuuUx1Nh89GY5ZjoncNlM51_Y>
Subject: Re: [Captive-portals] =?utf-8?q?Secdir_last_call_review_of_draft-iet?= =?utf-8?q?f-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 00:08:53 -0000

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
>