huitema
commented
5 years ago Hi Christian,
Please see below.
Am 11.09.2019 um 19:18 schrieb Christian Huitema huitema@huitema.net:
On 9/11/2019 9:53 AM, Mirja Kuehlewind wrote: Hi Ekr, hi all,
On 11. Sep 2019, at 18:15, Eric Rescorla ekr@rtfm.com wrote:
On Wed, Sep 11, 2019 at 12:36 AM Mirja Kuehlewind ietf@kuehlewind.net wrote: Hi Christian,
See below.
On 10. Sep 2019, at 23:25, Christian Huitema huitema@huitema.net wrote:
Thanks for the feedback, Mirja.
Some questions in line.
On 9/9/2019 9:07 AM, Mirja Kühlewind via Datatracker wrote: ...
COMMENT:
Thanks for clearly writing down attacks and requirements in this document.
One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path.
And two editorial comments:
Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar... The paragraph is definitely meant as story telling. The initial design of the SNI did not envisage or encourage usage by middle-boxes. That came later, and I don't know of IETF RFC or even drafts that define or normalize the middle-box usage. The point is, the developers of these boxes made a unilateral decision to use the field, without asking the IETF advice. I think the proposed rewriting would change the meaning of the paragraph. I don’t think there is or ever was a requirement to ask the IETF for permission to read unencrypted control data. That’s just what happened if we like it or not. My proposed rewrite was an attempt to phrase this more neutrally. You don’t have to use my words, but I think your wording is not appropriate for an RFC.
I don't agree with this. Christian's description of the situation is historically accurate as far as I can tell I didn’t comment on the accurateness but I still find the wording chosen not appropriate for an RFC.
However, I don’t know that it is possible to saying anything about the historical accurateness of “soon found out” because I neither know what’s meant by “soon” nor if they actually found something out in a timely close incidence after SNI was standardised/deployed (?), nor I can tell if developer of middleboxes actually "found it out” or maybe someone told them…? Given you added "as far as I can tell” to your sentence it's actually an indication that this might not be proven to be historically accurate but rather some personal view or even guess-work…
However, this was a comment in IESG evaluation. The working group and the responsible AD can figure out if you want to address it or not.
OK. So your basic objection is that "soon found out" is too colloquial. I could replace it by "some time after that" or some similar phrasing.
From my point of view „some time after“ wouldn’t make it much better because I think the important part of the information of this sentence is that middleboxes use that information (for good or bad) and not who had the idea when. But again just a comment...
By the way, you also made a remark on the mention that "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." I was not specifically referring to DSCP. I understand that flow prioritization is provider networks does not rely on the DSCP marking, in part because solutions can use deep packet inspection instead. On the other hand, it is entirely possible that if DPI stops working DSCP will become an attractive alternative, at least inside provider networks. I am trying to find the minimal change that would alleviate your concern. How about "Per-stream QoS can be provided by a combination of packet marking and contractual agreements"? That would remove the end-to-end mention.
Yes, removing end-to-end does help but it also sounds a bit as if that is a solution ready to use which I don’t think is the case. Maybe also say “could” instead “can” (to propose another minimal change)?
Mirja
-- Christian Huitema
Thanks for clearly writing down attacks and requirements in this document.
One small technical comment on this sentence: Sec 2.3: "Per-stream QoS can be provided by a combination of packet marking and end-to-end agreements." If this sentence is meant to mean use of DSCP, I don't think this is true, as DSCP is usually not available end-to-end but most often gets changed or bleached somewhere on the path.
And two editorial comments:
Sec 2.1: "The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information." "soon found out" does sound a bit story-telling like to me. I recommend a more objective phrasing like: "The SNI was defined to facilitate management of servers, though other usages by middleboxes also take advantage of the information." or something similar...
Also sec 2.1: "The SNI is probably also included in the general collection of metadata by pervasive surveillance actors." This sentence is phrased a bit speculatively and at the same kind seems inherently true as a "pervasive surveillance actor" usually just collect all available data/traffic... I guess the more interesting question would be if and how this information is used. Anyway I recommend some rephrasing like: "The SNI could also be utilised by the general collection of metadata by pervasive surveillance actors."