Re: [TLS] WG adoption call: SNI Encryption

[Christian Huitema]

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

Re: [TLS] WG adoption call: SNI Encryption

[Adam Langley]

On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema 
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.

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.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: draft-thomson-tls-record-limit

[Martin Thomson]

On 5 August 2017 at 06:07, Benjamin Kaduk  wrote:
> It is currently before 20170818, and I support adoption of this draft and am
> willing to review it as it progresses.
>
> I do agree with Ilari that limiting the ciphertext size seems to make more
> sense, but of course we can discuss that post adoption.

FWIW, I hope to merge PR #1 that addresses this point.  It isn't
perfect, but it keeps the happy path - those who don't pad more than
the minimum - happy.  We should discuss pros and cons, of course, and
I'd prefer to do that as an official WG product.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Martin Thomson]

On 5 August 2017 at 01:30, Brian Sniffen  wrote:
> ## Don't stand out
>
> I think the requirement that the browser check the CT log and perform
> DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I
> don't expect most browsers to do that most times.  Am I missing
> something?

Checking the CT log or doing DNSSEC validation would definitely cause
a red flag, but if the DNSSEC chain extension to TLS is used
(consistently), then the information is already on hand.  I don't know
what can be done for CT (SCT likely isn't what we're looking for
here).

The conclusion to the ORIGIN frame discussion ended with two choices
that increase confidence that a certificate isn't mis-issued without
violating this principle.  That was OCSP stapling or SCT.  It's an
important principle, maybe this draft should be clearer about that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls