Hi Martin, -- quote -- In writing this, I realize that this conclusion would be something of a cop-out on our part. In other words, lacking consensus on the fundamental issue, we instead to shift the responsibility to the individual least able and empowered in this entire transaction. While acknowledging that flaw, the benefits here could still outweigh that negative. We might not fix the underlying problem, but we can still fix the technical side-effects of it (attempts to MitM HTTPS, lack of clarity at the UE end, etc...). I'm guessing here, but it's possible that attempting to use this work as a means of forcing people to change their practices is more likely to result in the work we produce being roundly ignored. -- /quote --
Thanks for this... it sums up my thoughts nicely too. The key word is *could* -- it is a gamble. My conclusion, however, is that unless we address the fundamental issues at the network layer, we can't really fix the technical side effects of it (indeed, we can only add more side effects). My conclusion is that enforcement function vendors will have no idea if the API is implemented, integrated, and deployed correctly (enough) for them to phase out MitM HTTPS - even after 10 years of CAPPORT solutions and UE support - because there are too many edge cases. Also, as the API is seen to be wrong or misleading in the wild, UEs continue to probe, they don't really have clarity we anticipated... On Sun, Jul 22, 2018 at 8:20 PM Martin Thomson <[email protected]> wrote: > (I thought this needed a new thread.) > > On Sat, Jul 21, 2018 at 5:30 AM Michael Richardson > <[email protected]> wrote: > > > darshak - logged in is not necessary a binary state - what if the > > > network wants to block netflix > > > > It is noted that we can't get consensus. Some questions: > > 1) is that we can't get consensus on whether this is a good idea? > > 2) that we can't get consensus on how to signal this? > > 3) on how to represent this in the protocol? > > Good question. > > My reading is that it could be all three, but my hope is that it turns > out that we can agree to a weaker form of signaling that will allow us > to avoid having to agree on 1, even if that is what lies at the root > of this particular issue. > > My reading of the conversation thus far is that we might get consensus > to make this part of the communication between the network operator > and a human. That is, the network operator is expected to use the web > page to communicate this sort of information rather than to encode it > in the sort of terms that we would express in something as precise and > harsh as JSON. > > As David mentions here and on the other thread, the ways in which the > network access you get and the network access you assume you have (or > each of us might assume is ideal) differ are virtually innumerable. > Blocking of access to certain destination is not the only thing that > might be considered: rate limiting, path selection, quality of > service, packet markings, and all sorts of variations are possible. > > The IAB attempted to look at this problem a while back with RFC 4084 - > https://tools.ietf.org/html/rfc4084 - which was mentioned in the > meeting. That might be a useful reference in any text that addresses > this point. Not because the taxonomy there is useful (it's long since > been overtaken by events), but because it helps illustrate the > complexities involved. > > In writing this, I realize that this conclusion would be something of > a cop-out on our part. In other words, lacking consensus on the > fundamental issue, we instead to shift the responsibility to the > individual least able and empowered in this entire transaction. While > acknowledging that flaw, the benefits here could still outweigh that > negative. We might not fix the underlying problem, but we can still > fix the technical side-effects of it (attempts to MitM HTTPS, lack of > clarity at the UE end, etc...). I'm guessing here, but it's possible > that attempting to use this work as a means of forcing people to > change their practices is more likely to result in the work we produce > being roundly ignored. > > > I think that it's useful to clearly state what is going to be > out-of-scope. > > (and I think that we really do need this) > > I opened https://github.com/capport-wg/architecture/issues/13 during > the meeting to track this. You weren't the only one to realize this (I > won't claim credit, but can't remember who to give credit to - you can > try the recording if you like). > > Thanks, > Martin (not a chair at this time, though the chair part would > definitely like to see this resolve) > > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals >
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
