Draft: draft-ietf-tls-sni-encryption

Commentary: Comments and discussion are found in issue . The proposed changes are minimal . 
 Once this is processed one way or another , I would like to publish a revised draft . 
 Thanks for clearly writing down attacks and requirements in this document . One small technical comment on this sentence :  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 do n'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  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 . " 
 Hi Christian , Please see below . On 9/11/2019 9:53 AM ,   wrote : Hi Ekr , hi all , On 11 . Sep 2019 , at 18:15 ,   < : Mirja Kuehlewind < : Hi Christian , See below . On 10 . Sep 2019 , at 23:25 , Christian Huitema < : Thanks for the feedback ,  . Some questions in line . On 9/9/2019 9:07 AM ,   via Datatracker wrote : ... COMMENT : Thanks for clearly writing down attacks and requirements in this document . One small technical comment on this sentence :  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 do n'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  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 do n'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 do n’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 do n’t have to use my words , but I think your wording is not appropriate for an RFC . I do n't agree with this . Christian 's description of the situation is historically accurate as far as I can tell I did n’t comment on the accurateness but I still find the wording chosen not appropriate for an RFC . However , I do n’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 " 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 . From my point of view „ some time after “ would n’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 ... Yes , removing end - to - end does help but it also sounds a bit as if that is a solution ready to use which I do n’t think is the case . Maybe also say “ could ” instead “ can ” ( to propose another minimal change ) ? Mirja 
 Addressed in PR
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors.
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
Deploying SNI encryption will help thwart most of the "unanticipated"
SNI usages described in snileak, including censorship and pervasive
surveillance.  It will also thwart functions that are sometimes
described as legitimate.  Most of these functions can, however, be
realized by other means.  For example, some DNS service providers
offer customers the provision to "opt in" filtering services for
parental control and phishing protection.  Per-stream QoS can be
provided by a combination of packet marking and end-to-end
agreements.  As SNI encryption becomes common, we can expect more
deployment of such "end-to-end" solutions.
Deploying SNI encryption will help thwart most of the "unanticipated"
SNI usages described in snileak, including censorship and pervasive
surveillance.  It will also thwart functions that are sometimes
described as legitimate.  Most of these functions can, however, be
realized by other means.  For example, some DNS service providers
offer customers the provision to "opt in" filtering services for
parental control and phishing protection.  Per-stream QoS could be
provided by a combination of packet marking and end-to-end
agreements.  As SNI encryption becomes common, we can expect more
deployment of such "end-to-end" solutions.