Subject: [TLS] WG adoption call: SNI Encryption

From: Sean Turner <[email-masked]>
Date: Fri, 4 Aug 2017 08:50:33 -0400

At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the list so please let the list know whether you support adoption of the draft and are willing to review/comment on the draft before 20170818.  If you object to its adoption, please let us know why.

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 04 Aug 2017 09:21:37 -0400

On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
> At our IETF 99 session, there was support in the room to adopt
> draft-huitema-tls-sni-encryption [0].  We need to confirm this support
> on the list so please let the list know whether you support adoption
> of the draft and are willing to review/comment on the draft before
> 20170818.  If you object to its adoption, please let us know why.

I support wg adoption of this draft and am willing to review before
20170818.

        --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Aug 2017 15:17:00 +0100

On 04/08/17 14:21, Daniel Kahn Gillmor wrote:
> I support wg adoption of this draft and am willing to review 

+1

> before

Not sure about the date - if it's finished by then that'd
be pretty speedy:-)

S

> 
>         --dkg
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 4 Aug 2017 10:53:45 -0400

I support adoption and have reviewed the draft.

---

From: Christopher Wood <[email-masked]>
Date: Fri, 4 Aug 2017 08:03:49 -0700

I also support adoption, have reviewed it, and will continue to do so.

Best,
Chris

---

From: Brian Sniffen <[email-masked]>
Date: Fri, 04 Aug 2017 11:17:14 -0400

-Brian

-- 
Brian Sniffen
Akamai Technologies

---

From: Adam Langley <[email-masked]>
Date: Fri, 4 Aug 2017 10:39:07 -0700

On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner <[email-masked]> wrote:

> draft-huitema-tls-sni-encryption [0].  We need to confirm this support on
> the list so please let the list know whether you support adoption of the
> draft and are willing to review/comment on the draft before 20170818.  If
> you object to its adoption, please let us know why.
>

Section two of the draft discusses the design space, which is to be
welcomed, but also MUST/MUST NOTs sections of that design space. While I
generally agree with its opinions, it's confused about whether it's a
technical document or a policy document. If it decides to be a policy
document, then I'm unconvinced of its utility.

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.

Thus I'm not sure that the draft is ready for an adoption call at this time.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 4 Aug 2017 11:03:31 -0700

> process, there's a big gap between the two ideas and I'd support one but

The tunneling mechanism described in Section 4.1 seems useful (at least to
me) for more things than encrypted SNI, such as being able to use different
TLS extensions for the frontend load balancer versus a backend service,
while still eventually negotiating an end-to-end encrypted session with the
backend service.

I wonder if the draft should be framed around the TLS-in-TLS tunneling
mechanism, with encrypted SNI as a potential use case.

-- 
Tony Arcieri

---

From: Adam Langley <[email-masked]>
Date: Fri, 4 Aug 2017 11:42:48 -0700

> mechanism, with encrypted SNI as a potential use case.

But my point is that, in this situation, I would expect there to be two
competing drafts—one for each proposal. The WG would then only adopt one of
them.

Cheers

AGL

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Aug 2017 20:37:24 -0700

On 8/4/2017 10:39 AM, Adam Langley wrote:
> On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     draft-huitema-tls-sni-encryption [0].  We need to confirm this
>     support on the list so please let the list know whether you
>     support adoption of the draft and are willing to review/comment on
>     the draft before 20170818.  If you object to its adoption, please
>     let us know why.
>
>
> welcomed, but also MUST/MUST NOTs sections of that design space. While
> I generally agree with its opinions, it's confused about whether it's
> a technical document or a policy document. If it decides to be a
> policy document, then I'm unconvinced of its utility.
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.

>
> 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.

-- 
Christian Huitema

---

From: Tom Ritter <[email-masked]>
Date: Fri, 4 Aug 2017 23:30:50 -0500

On Aug 4, 2017 9:22 AM, "Daniel Kahn Gillmor" <[email-masked]> wrote:

+1 although I agree with AGL about must/must nots setting policy (and that
the section should be reworked in the frame of "we have chosen a design to
avoid these undesirable characteristics) and that it's odd to adopt the
draft without choosing which of the designs we're adopting.

However I at this time I'm not opposed to either design.

-tom

---

From: Adam Langley <[email-masked]>
Date: Sat, 5 Aug 2017 09:44:18 -0700

> 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.

The IETF does do such policy documents from time-to-time, but not mixed
with a technical document like this in my experience.

> 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.

Cheers

AGL

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Aug 2017 10:40:48 -0700

On 8/5/2017 9:44 AM, Adam Langley wrote:
> On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <[email-masked]
> <mailto:[email-masked]>> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 6 Aug 2017 20:40:23 +0000

> it's odd to adopt the draft without choosing which of the designs we're adopting.

On the contrary, I think it's ridiculous for the WG to pick one design without discussion.  I really look forward to AGL's comments on each

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Aug 2017 16:40:48 -0500

> At our IETF 99 session, there was support in the room to adopt draft-huitema-tls-sni-encryption [0].  We need to confirm this support on the list so please let the list know whether you support ado…

It is before 20170818, and so I make my reply to the call for adoption now.

I think that the WG should discuss this topic and produce a document
with it, but I am not convinced that this document, as it stands, is a
good starting point for a product of the WG.  As has already been
discussed, it is a bit strange to have normative language in the catalog
of known attacks, but removing those is easy and also uncontroversial. 
That said, my main reason for believing that changes are needed before
this is a good starting point for a WG document is that it does not
present itself as a single cohesive solution, but rather a choice. 
This, of course, has also already been noted, but I will note that I
also prefer to have the choice resolved before adopting a WG document. 
(It is possible, of course, that the choice of the WG will be that both
flavors are necessary, or even something not yet included.)

That said, I am happy to review and comment on drafts in this area as
the WG discusses options and settles on a consensus choice.

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Aug 2017 10:13:50 +1000

On 17 August 2017 at 07:40, Benjamin Kaduk <[email-masked]> wrote:
> I think that the WG should discuss this topic and produce a document with
> it, but I am not convinced that this document, as it stands, is a good
> starting point for a product of the WG.

Maybe the right answer here is to declare that we have consensus for
working on the problem, but that we need more time to find the
solution we want to write down (or solutions, which seems like an
entirely plausible outcome in this case).

Note that I am NOT arguing for a requirements document.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Aug 2017 19:19:22 -0700

We don't need to adopt to have the discussion. I think we definitely can
have a discussion of the merits of the solutions before going to adoption

> it's odd to adopt the draft without choosing which of the designs we're
adopting.

On the contrary, I think it's ridiculous for the WG to pick one design
without discussion.  I really look forward to AGL's comments on each
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 16 Aug 2017 20:06:57 -0700

As I expressed on a separate thread, I think tunneling TLS is a very
interesting problem with many potential use cases, from SNI encryption to
egress proxies to service discovery proxies (e.g. linkerd, Envoy).

SNI encryption is one of the use cases, but SNI encryption is pointless
until we have encrypted DNS. That's not to say we shouldn't work on SNI
encryption, but that SNI encryption isn't immediately valuable, whereas I
think there are many other TLS tunneling use cases where the same proposed
mechanism is immediately valuable as opposed to a future "when the DNS
loophole is closed" scenario for SNI encryption.

I am all for tunneling as a general WG item, but I think framing the
discussion specifically in terms of SNI encryption is missing the forest
for the trees.

-- 
Tony Arcieri

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Aug 2017 14:18:13 +1000

On 17 August 2017 at 13:06, Tony Arcieri <[email-masked]> wrote:
> until we have encrypted DNS.

https://tools.ietf.org/html/rfc7858

I hear that there are even implementations and deployments.

It's certainly time to have the discussion about closing the next gap.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Aug 2017 09:31:33 +0100

> I hear that there are even implementations and deployments.

Yes, I used the resolver doing this at the last IETF meeting.
It worked. Not "just worked," but pretty good.

> It's certainly time to have the discussion about closing the next gap.

Yes. I'm in favour of adopting as a strong signal that this
is a WG item. I don't think anyone needs to be allergic to
a wg draft-00 that still documents more than one proposal,
there's no specific place in the evolution of an RFC before
which such things MUST get sorted out, so while being a bit
concerned that we still have two options is very reasonable,
that's not IMO a winning argument against wg adoption.

S.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 28 Aug 2017 20:12:44 -0700

The working has expressed consensus to work on the problem of SNI
encryption.  More work is needed to determine the technical approach to SNI
encryption.  The chairs believe there is enough interest and energy to
adopt this draft and continue work within the working group instead of
asking the constituents to arrive at a solution before adoption.

This document will serve as the basis for discussion.  Whether the document
will cover the solution to the problem will be determined by the chairs at
a later point in time.  The chairs request the author remove the normative
text from the description of the attacks and submit draft-ietf-tls-sni-encr
yption-00.txt.

Thanks,

J&S