Re: [Captive-portals] Discovering captive portal API URL via DNS?

Lorenzo Colitti <lorenzo@google.com> Wed, 04 September 2019 03:32 UTC

Return-Path: <lorenzo@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 552EC120232 for <captive-portals@ietfa.amsl.com>; Tue, 3 Sep 2019 20:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LlbprbgX22nc for <captive-portals@ietfa.amsl.com>; Tue, 3 Sep 2019 20:32:38 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 EC32512083B for <captive-portals@ietf.org>; Tue, 3 Sep 2019 20:32:37 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id n2so1744196wmk.4 for <captive-portals@ietf.org>; Tue, 03 Sep 2019 20:32:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IfTKYTyo6x5wbqfN99XIuyzPQnTyMRIPcF/2YlvfQ+8=; b=JJJF9sLqd3mgvVK2p4fmYq56USASJvPLNHgWC7Z9VCZlydAxvbFr5R3arQX9dxv+Rz GcQb/LjD2lrsJ0p5iHstV4iHzgsqHJxKpwkNgvBXqUwpQsEQJx4GGnvUbKLwce1l/LJy BuCJGY5rmYYzjUOGZf7jDxngPDift3r7/2tXh3S2aPxnyYMbAt1TGG03Fv3onuCYG58H Z4zLz8Oa/jIMZXALWDXfiKGDWKC0sw9hoy2bzvjNAVBlNOEy7O4M5lQ3Wl6VjFX4Y8Vi 1G8IYvyx6fw+8jK9mNuM5RUa7xHRLIuFA8XrvNB9TXYmGh8ho3hrlDzj8rxCs/PcnlhV sxlw==
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=IfTKYTyo6x5wbqfN99XIuyzPQnTyMRIPcF/2YlvfQ+8=; b=Q5f8rsneCtSCUk/tffLdTiZLHBGF4BxRUwzViFlp3SLbf3vH9jRreZKvcXCvWtsmvn SYYQr+YeNHKS2tS4u6kXuITOKQDJXtXDIMQLUQLcwWicWOzwQp6dp8SPkN+JSC0enxUI qui8DbO0Gvn5ZsO5NEXUMMSDOwLc46tW0IcL2m+Fulo2FkL3tevc99WWWNs482R64jpQ Fw2wM05UHvon95iEWeL954IlrE6BFLItK8VjKxv59+Ftq51D6gves36a88Aem2/yy9wb F79jUfi39hupiJRfCdWSjIgO9oLSC0NyHuayANicVMu4iv23h5RGb1tcZ8dNq5dcv3jx k9YA==
X-Gm-Message-State: APjAAAWPID174c8s2h58yGs6gVqS/ivvIiah2XQ1uWkKUprK4Q0EtWMg xWVkpt5cOFRzDAsNi6xIkjoiKwETy4aYd9QOlN7tLvKPQEA=
X-Google-Smtp-Source: APXvYqyAPIOzPi0L+dKN2Q3+xz0n0jCI9GiIdG61RDzUkhN0yr1MnKcT12KAmGhtUHhXZ0bM7gjtxKtiQ9KcD7p+sHg=
X-Received: by 2002:a7b:c777:: with SMTP id x23mr2419856wmk.84.1567567956173; Tue, 03 Sep 2019 20:32:36 -0700 (PDT)
MIME-Version: 1.0
References: <CAKD1Yr1mR57OsOzDtjM=7YCV_R6zFF9WPxqA-XrWsuJWv+VTag@mail.gmail.com> <dc464cef-360a-4444-ba2d-fa878e79790f@www.fastmail.com>
In-Reply-To: <dc464cef-360a-4444-ba2d-fa878e79790f@www.fastmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 04 Sep 2019 12:32:24 +0900
Message-ID: <CAKD1Yr1nS+rB2B4yhpVnrmrND2RsW=SSvKKbszaZKMRGgQ1jJQ@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: captive-portals@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/ivJh6VzW6oE79aK6Mfo7BMWQZic>
Subject: Re: [Captive-portals] Discovering captive portal API URL via DNS?
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, 04 Sep 2019 03:32:41 -0000

Yes, the query would have to be directed to the resolver provided by
the network.

I agree that this could increases the attack surface compared to a
DHCP solution. DHCP is also a cleartext protocol, but it is typically
secured via other means like DHCP guard. If the network provides
equivalent protections to DNS traffic (most simply, by providing
strong protections against IP spoofing and on-link attacks), then the
security properties are likely equivalent.

On Wed, Sep 4, 2019 at 11:48 AM Martin Thomson <mt@lowentropy.net> wrote:
>
> What about those resolvers that collapse CNAME responses, effectively eliding them?
>
> I assume that you are going to explicitly say that this has to be directed to the resolver provided in network configuration.  If that resolver is outside the network or less tightly secured than DHCP/RAs, then we have the possibility of attack on the DNS-over-UDP-53 that is used to get the CNAME response.
>
> (Just contributin' not chairin'.)
>
> On Wed, Sep 4, 2019, at 09:44, Lorenzo Colitti wrote:
> > All,
> >
> > During discussions with captive portal operators about implementing the
> > capport API, one of the stumbling blocks that keeps coming up is that
> > the captive portal operator does not always control the DHCP
> > configuration and thus cannot easily use RFC7710.
> >
> > The WG has previously rejected the option of using a well-known DNS
> > name to discover the URL, because the API itself requires TLS, and
> > without a hostname it is not possible (or at least not easy) to
> > validate the server. However, what if the client did a CNAME query for
> > capport.arpa (or equivalent other local-only, non-DNSSEC-signed name),
> > got back a CNAME for the real server, and then assumed that the API
> > server was https://<targetofcname>/capport-api ?
> >
> > Alternatively, Erik and Warren suggest RFC 7553. In this scheme the
> > client would do a URI lookup for "capport.arpa" or equivalent, and
> > would take the result of that URL as the API endpoint.
> >
> > Thoughts?
> >
> > Regards,
> > Lorenzo
> > _______________________________________________
> > 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