Re: [Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-rfc7710bis-07: (with DISCUSS and COMMENT)
Hi Warren and Erik, On Tue, Jun 23, 2020 at 07:25:24PM -0400, Warren Kumari wrote: > On Tue, Jun 9, 2020 at 8:46 PM Benjamin Kaduk via Datatracker > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-capport-rfc7710bis-07: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ > > > > > > > > -- > > DISCUSS: > > -- > > > > There seems to be an internal inconsistency about whether, when the API > > URL is available in a given network via multiple mechanisms, the URLs > > provided by the different mechanisms must be "identical" (Section 3) or > > merely "equivalent" (Section 2). I think we need to be consistent in > > the requirement, as it is possible for URLs to be equivalent but not > > identical just by virtue of mundane encoding tricks, even without > > getting to the question of semantic equivalence of pointed-to resources. > > Thank you - we have addressed this in the most recent commit by using > "identical" and adding some words. > Please confirm that these meet with your approval. Yes, this looks good, and I've cleared my Discuss in the datatracker (but had it not send mail, since I'm sending this one). > > > > > > -- > > COMMENT: > > -- > > > > There is perhaps something to be said about how us moving from DHCP code > > point 160 to 114 is in effect making a mockery of the registration > > policy of IETF Review, when it is in practice First Come First Served as > > the squatter wins. I think we should consider making a stronger > > statement about squatting being bad (though if I understand correctly > > for this case, the registration policy in this range has changed since > > the creation of the registry, so maybe there are extenuating > > circumstances). [N.B. that this is the COMMENT section, not the DISCUSS > > section.] > > > > I also think we should be more explicit about the potential gap in the > > chain of custody for getting the user to the captive portal server to > > fulfil the Captive Portal Conditions. In order for the user to trust > > that they're in the right place (even as they may be, e.g., entering > > payment information), they rely on the network to only provide > > legitimate versions of the signals defined in this document, blocking > > sppofed ones. At present, this seems to involve a component of "blind > > faith", and though we do discuss the technical capabilities of the > > attacker we don't go into how this affects the "trust chain" from > > initial network attachment. (More discussion in the section-by-section > > comments.) > > > > Abstract > > > >In many environments offering short-term or temporary Internet access > >(such as coffee shops), it is common to start new connections in a > >captive portal mode. This highly restricts what the customer can do > >until the customer has authenticated. > > > > side note: I don't remember seeing "customer" used in the architecture or > > API > > document. > > DONE. > Thank you - we have gone with "user" (to address others comments) - I > was picturing someone (a customer) buying coffee, and so that is where > this usage originally came from. > > > > >This document describes a DHCPv4 and DHCPv6 option and a Router > >Advertisement (RA) option to inform clients that they are behind some > >sort of captive-portal enforcement device, and that they will need to > >authenticate to get Internet access. It is not a full solution to > > > > In the terminology of the architecture doc, the client will "satisfy the > > Captive Portal Conditions" (as opposed to "authenticate"). Is there a > > reason to use divergent terminology? > > DONE. Thank you -- using "satisfy the Captive Portal conditions" > > > > >hosts to interact with such portals. While this document defines how > >the network operator may convey the captive portal API endpoint to > >hosts, the specific methods of authenticating to, and interacting > >with the captive portal are out of scope of this document. > > > > ["authenticating" again] > > DONE. Thank you. As above. > > > > > Section 2 > > > >information faster and more reliably. Note that, for the foreseeable > >future, captive portals will still need to implement interception > >techniques
Re: [Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-rfc7710bis-07: (with DISCUSS and COMMENT)
On Tue, Jun 9, 2020 at 8:46 PM Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-capport-rfc7710bis-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ > > > > -- > DISCUSS: > -- > > There seems to be an internal inconsistency about whether, when the API > URL is available in a given network via multiple mechanisms, the URLs > provided by the different mechanisms must be "identical" (Section 3) or > merely "equivalent" (Section 2). I think we need to be consistent in > the requirement, as it is possible for URLs to be equivalent but not > identical just by virtue of mundane encoding tricks, even without > getting to the question of semantic equivalence of pointed-to resources. Thank you - we have addressed this in the most recent commit by using "identical" and adding some words. Please confirm that these meet with your approval. > > > -- > COMMENT: > -- > > There is perhaps something to be said about how us moving from DHCP code > point 160 to 114 is in effect making a mockery of the registration > policy of IETF Review, when it is in practice First Come First Served as > the squatter wins. I think we should consider making a stronger > statement about squatting being bad (though if I understand correctly > for this case, the registration policy in this range has changed since > the creation of the registry, so maybe there are extenuating > circumstances). [N.B. that this is the COMMENT section, not the DISCUSS > section.] > > I also think we should be more explicit about the potential gap in the > chain of custody for getting the user to the captive portal server to > fulfil the Captive Portal Conditions. In order for the user to trust > that they're in the right place (even as they may be, e.g., entering > payment information), they rely on the network to only provide > legitimate versions of the signals defined in this document, blocking > sppofed ones. At present, this seems to involve a component of "blind > faith", and though we do discuss the technical capabilities of the > attacker we don't go into how this affects the "trust chain" from > initial network attachment. (More discussion in the section-by-section > comments.) > > Abstract > >In many environments offering short-term or temporary Internet access >(such as coffee shops), it is common to start new connections in a >captive portal mode. This highly restricts what the customer can do >until the customer has authenticated. > > side note: I don't remember seeing "customer" used in the architecture or API > document. DONE. Thank you - we have gone with "user" (to address others comments) - I was picturing someone (a customer) buying coffee, and so that is where this usage originally came from. > >This document describes a DHCPv4 and DHCPv6 option and a Router >Advertisement (RA) option to inform clients that they are behind some >sort of captive-portal enforcement device, and that they will need to >authenticate to get Internet access. It is not a full solution to > > In the terminology of the architecture doc, the client will "satisfy the > Captive Portal Conditions" (as opposed to "authenticate"). Is there a > reason to use divergent terminology? DONE. Thank you -- using "satisfy the Captive Portal conditions" > >hosts to interact with such portals. While this document defines how >the network operator may convey the captive portal API endpoint to >hosts, the specific methods of authenticating to, and interacting >with the captive portal are out of scope of this document. > > ["authenticating" again] DONE. Thank you. As above. > > Section 2 > >information faster and more reliably. Note that, for the foreseeable >future, captive portals will still need to implement interception >techniques to serve legacy clients, and clients will need to perform >probing to detect captive portals. > > side note: I'd consider reiterating the "faster and more reliably" here > to incentivize adoption of the new mechanisms even though the legacy > ones are still needed. Thank you -- we were not able to parse this suggestion - unless you were suggesting that the second sentence say that legacy clients don't benefit from this?
[Captive-portals] Benjamin Kaduk's Discuss on draft-ietf-capport-rfc7710bis-07: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-capport-rfc7710bis-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ -- DISCUSS: -- There seems to be an internal inconsistency about whether, when the API URL is available in a given network via multiple mechanisms, the URLs provided by the different mechanisms must be "identical" (Section 3) or merely "equivalent" (Section 2). I think we need to be consistent in the requirement, as it is possible for URLs to be equivalent but not identical just by virtue of mundane encoding tricks, even without getting to the question of semantic equivalence of pointed-to resources. -- COMMENT: -- There is perhaps something to be said about how us moving from DHCP code point 160 to 114 is in effect making a mockery of the registration policy of IETF Review, when it is in practice First Come First Served as the squatter wins. I think we should consider making a stronger statement about squatting being bad (though if I understand correctly for this case, the registration policy in this range has changed since the creation of the registry, so maybe there are extenuating circumstances). [N.B. that this is the COMMENT section, not the DISCUSS section.] I also think we should be more explicit about the potential gap in the chain of custody for getting the user to the captive portal server to fulfil the Captive Portal Conditions. In order for the user to trust that they're in the right place (even as they may be, e.g., entering payment information), they rely on the network to only provide legitimate versions of the signals defined in this document, blocking sppofed ones. At present, this seems to involve a component of "blind faith", and though we do discuss the technical capabilities of the attacker we don't go into how this affects the "trust chain" from initial network attachment. (More discussion in the section-by-section comments.) Abstract In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. side note: I don't remember seeing "customer" used in the architecture or API document. This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive-portal enforcement device, and that they will need to authenticate to get Internet access. It is not a full solution to In the terminology of the architecture doc, the client will "satisfy the Captive Portal Conditions" (as opposed to "authenticate"). Is there a reason to use divergent terminology? hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of authenticating to, and interacting with the captive portal are out of scope of this document. ["authenticating" again] Section 2 information faster and more reliably. Note that, for the foreseeable future, captive portals will still need to implement interception techniques to serve legacy clients, and clients will need to perform probing to detect captive portals. side note: I'd consider reiterating the "faster and more reliably" here to incentivize adoption of the new mechanisms even though the legacy ones are still needed. to reduce the chance of operational problems. The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA options. I'm not sure whether this text is conveying the intended meaning -- the current version sounds like it's saying that because IPv4 DHCP is limited, we need an entirely new mechanism to convey longer URIs, leaving the reader to guess that this is out of some desire to keep the existing mechanisms at feature parity. Is the intent more along the lines of "URIs longer than 255 bytes should not be used at all, so that it's easier to present a consistent view across the three different provisioning mechanisms defined in this document"? In all variants of this option, the URI MUST be that of
