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

That's not strictly true (or it needn't be strictly true).

The text in #section-3 as worded allows for a portal that lets the
clear-text query through but still adds the API link rel into the
response.  If the text somehow doesn't allow this, we could make it more
explicit.

If there are 2 equally good ways to do this (DNS and link relation) then it
does, I grant, seem like it would be worth the time to see if the group
could scope it back down to one.

On Tue, 3 Sep 2019 at 18:08, Lorenzo Colitti <lorenzo@google.com> wrote:

> If we have a way to discover the portal via DNS, then maybe we don't need
> <link rel> at all? The problem with <link rel> is that it cannot be used
> once the portal is open, so if the device logs in, and then disconnects and
> reconnects, it doesn't work.
>
> On Wed, Sep 4, 2019 at 10:05 AM Erik Kline <ek@loon.com> wrote:
>
>> Chair hat off, co-author hat on.
>>
>> We can certain craft some text to round out
>> https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4
>> when the time comes..  Certainly DHCP/RA would retain highest precedence.
>>
>> RFC 7553 URI records would obviate the inevitable discussion about the
>> merits of .well-known (I know nothing about .well-known/ except that it
>> tends to bring up some (.)well-known responses).
>>
>> Where would you slot DNS results relative to link relation in an HTTP
>> intercept/redirect?
>>
>> On Tue, 3 Sep 2019 at 17:32, Cappalli, Tim (Aruba Security) <timc@hpe.com>
>> wrote:
>>
>>> I like that idea, combined with well known. Ex:
>>> https://<targetofcname>/.well-known/capport-api/xyz
>>>
>>>
>>>
>>> Ideally there would be some standardized precedence order as there are
>>> different cases for each of these. An example would be a common DNS a
>>> service that doesn’t have views-like functionality so the ability to return
>>> a different value based on the source IP/subnet may not be possible. In
>>> this case, the operator may have control of DHCP and could use 7710.
>>>
>>>
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>>
>>> *Tim Cappalli* *|* Identity & Policy Architect *|* Aruba Security
>>> <https://www.arubanetworks.com/products/security/> *|* @timcappalli
>>> <https://twitter.com/timcappalli>
>>>
>>>
>>>
>>> *From: *Captive-portals <captive-portals-bounces@ietf.org> on behalf of
>>> Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
>>> *Date: *Tuesday, September 3, 2019 at 4:45 PM
>>> *To: *"captive-portals@ietf.org" <captive-portals@ietf.org>
>>> *Subject: *[Captive-portals] Discovering captive portal API URL via DNS?
>>>
>>>
>>>
>>> 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
>>>
>>