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

Reply via email to