On 8/5/2017 9:44 AM, Adam Langley wrote: > On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <huit...@huitema.net > <mailto:huit...@huitema.net>> wrote: > > Clearly, Section 2 could be turned into some kind of 'problem > statement" draft. I personally don't like splitting problem > statement and proposed solution in separate documents, but if > that's the group consensus, why not. > > I don't think it need be split into a separate document. Indeed, I > think explaining the design space and the reasons for that a specific > design was selected should be welcomed in an RFC. > > What makes this document distinct are the sentences like "SNI > encryption designs MUST mitigate this attack." This appears to be > constraining /other/ documents by saying that such designs are not > merely unattractive (in the views of the author), but forbidden to be > considered.
I see your point. How about we remove the MUST/SHOULD language from section 2, and put it instead in the actual specification sections, something like "choosing a design that mitigates the attacks described in section 2?" > > The IETF does do such policy documents from time-to-time, but not > mixed with a technical document like this in my experience. > >> If it wants to be a technical document, then the draft includes >> two very different designs with a note saying that one will be >> chosen at some point. So which are we talking about adopting? >> While drafts evolve during the WG process, there's a big gap >> between the two ideas and I'd support one but not the other. > My goal was to list the current state of solutions. The document > could be split with different drafts presenting different > solutions, but I believe there is value in an attempt at unification. > > > Eventually we have to pick one, right? I feel that drafts are > generally more opinionated before a call for adoption, although the > chairs might well feel that the design-space span is this document is > focused enough already. I expect that we will see that eventually, focusing on one solution, or on an architecture that mixes several mechanisms. When I wrote the draft, I was collecting ideas from various places and I did not feel like making choices without WG input. But there are three main ideas: some kind of "delegation token" that expresses the agreement by a hidden site to be access through a front-end; the possibility of sending a second Client Hello as 0-RTT data; and, the idea of expressing a fronting SNI as part of a resumption ticket. I am not sure that we know at this stage whether these are three different solutions or three components of a single solution. -- Christian Huitema -- Christian Huitema
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
