[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Lorenzo Colitti <[email protected]> wrote:
    > 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.

Agreed.

    > 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.

RFC7553 seems like a better choice than a CNAME hack.

So we are trading the assumption that captive portal operator can control
DHCP to one where captive portal operator can control/influence DNS, and
that things like DoT/DoH can not be used by the captive portal client.
(I just want to make the assumption explicit. I'm not complaining about it)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [ 
	


Attachment: signature.asc
Description: PGP signature