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