Hi Ben, Thanks for your responses! Comments inline for the points that needed replies.
Best, Tommy > On Jan 23, 2020, at 10:20 AM, Benjamin Kaduk <[email protected]> wrote: > > Hi Tommy, > > Also inline. > > On Wed, Jan 22, 2020 at 12:42:59PM -0800, Tommy Pauly wrote: >> >>> >>> 399, inclusive, it MUST follow the redirection(s). If the HTTP >>> status of the answer is between 200 and 299, inclusive, the host MAY >>> get a file containing a single JSON object. >>> >>> Is redirect-chasing recursive or one-time? >>> I agree with Alissa that this "MAY" is not normatiave. >> >> Fixed with Alissa's feedback: >> >> If the HTTP status of >> the answer is between 200 and 299, inclusive, the response is expected to >> be a single JSON object. > > Great! (What's the answer to the redirect-chasing question, though?) It should follow the usual HTTP client logic—it will follow multiple redirects up to a point, but prevent loops. > >>> >>> nit: if we are going to say "uniformly random" for the [(B-A)/2,B] >>> interval, we should probably also use "uniformly" for the "random time >>> between zero and 2**(Delay * 2) milliseconds". > > (This is just a nit and doesn't really need a response, but putting a > remark here just in case it was accidentally overlooked.) Sorry! I did fix this, just forgot to reply to this line. >>> >>> Section 4.2 >>> >>> RA by the network operator. In particular, when a captive portal is >>> present, hosts MUST still be allowed to perform DNS, PKI and HTTP >>> over TLS operations related to the retrieval of the object, even >>> before logging into the captive portal. >>> >>> I assume "DNS" here means "DNS over UDP(/TCP) on port 53 in the >>> traditional, unencrypted, protocol of STD 13"? It may be prudent to be >>> clear about the expectations here. >> >> I'd prefer to not specify the DNS protocol here. If the local network ends >> up provisioning DoT or DoH, and in the future doesn't allow Do53, I'd want >> that to be equally included. > > My concern is more along the lines of "if what is allowed is not what the > client is willing/planning to do, the client is in for a sad time". If the > client's author reads this differently than the captive portal's author, we > would run the risk of interop failure. I think in the case of captive portals and bootstrapping traffic like PvDs, it's the responsibility of the client to use appropriate protocols that will be able to traverse the network. It may certainly gate user-sensitive DNS queries behind being able to do DoH, but should use Do53 or DoH or DoT based on what the network provides/allows for captive and PvD queries. > > > >>> and the HTTPS server. However, this does not mean the Advertising >>> Router and the PvD server belong to the same entity. >>> >>> Can you give me an example of when they would not be part of the same >>> entity? I can only partially see how that would happen. >> >> I think it's clearer to remove the sentence, since it's not a particularly >> interesting point. The idea is that you may have a PvD server provider >> that's run by a larger service (say your local network is a one-off cafe >> network, but it points to extended info that's generic for a larger set of >> deployments), but I don't know if that really is relevant here. > > It may be useful to give the reader a reminder about the distinction > between advertising router and PvD server in the context of there only > being a unidirectional authorization binding (PvD authorizes addresses, but > router-to-PvD is mostly not authorized/authenticated), but I agree that > this is probably not the best place in the document for such discussion. Agreed. > >>> Section 5.2 >>> >>> In the above example, non-PvD-aware hosts will only use the first RA >>> sent from their default router and using the 2001:db8:cafe::/64 >>> prefix. PvD-aware hosts will autonomously configure addresses from >>> >>> nit(?): I can't decide whether "from" or "for" is intended in "from >>> their default router". >> >> Changed to "sent by their default router". > > Oh, hmm, that's not where I thought this was going. Perhaps I was just > confused! Anyway, I was reading this along the lines of "a host will join > a network and listen for RAs, possibly solicting them too. The first > received RA will be used as the default router", but on a re-read, it seems > likely that "first" just means "the first one in the example, not the > second one in the example". (But will the host know that the sender is > their default router at the time they receive that RA?) Ah, I see the confusion. Yes, it was referring to the first one in the list. I can say "first listed RA" rather than just "first RA". > > >>> >>> From a user privacy perspective, retrieving the PvD Additional >>> Information is not different from establishing a first connection to >>> a remote server, or even performing a single DNS lookup. For >>> example, most operating systems already perform early queries to well >>> known web sites, such as http://captive.example.com/hotspot- >>> detect.html, in order to detect the presence of a captive portal. >>> >>> I understand the desire to only use names/numbers designated as "for >>> example use" in RFCs, but this seems like a case where it might be worth >>> making an exception. >> >> I don't see an issue with using "example.com" here as the example domain. >> Did you have something specific in mind? > > The phrasing "well known web sites" made me think there were specific ones > that are actually well-known; captive.example.com > <http://captive.example.com/> does not really seem > "well-known" to me. IIRC there were some apple.com <http://apple.com/> and > other examples > listed in a reference or some of the email discussion, and I thought those > were what this was trying to refer to. I see; yes, this is referring to the fact that there are static queries that go out, which vary by platform (apple will use captive.apple.com). Perhaps rather than "well known web sites", this can be "static web sites". > >>> Network operators SHOULD restrict access to PvD Additional >>> Information to only expose it to hosts that are connected to the >>> local network, especially if the Additional Information would provide >>> information about local network configuration to attackers. This can >>> >>> (It seems that even the existence of a vendor-* subobject might be >>> considered "sensitive" in this fashion.) >> >> Indeed! >>> >>> Section 8.2 >>> >>> Is there any additional guidance we wish to give to the Experts? >> >> How about: >> >> Experts are requested to ensure that defined keys do not overlap, >> and represent non-vendor-specific use cases. Vendor-specific keys >> SHOULD use sub-dictionaries, as described in {{aiformat}}. > > That seems reasonable, though perhaps clarifying if the non-overlap is in > the semantics of keys or their naming would be helpful. Sure, I can clarify that the "that defined keys do not overlap in names or semantics..." > >>> > > -Ben
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
