Re: [TLS] WG adoption call: SNI Encryption

[Martin Thomson]

On 17 August 2017 at 13:06, Tony Arcieri  wrote:
> SNI encryption is one of the use cases, but SNI encryption is pointless
> 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.

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

Re: [TLS] WG adoption call: SNI Encryption

[Tony Arcieri]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Watson Ladd]

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

On Aug 6, 2017 1:40 PM, "Salz, Rich"  wrote:

> 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Martin Thomson]

On 17 August 2017 at 07:40, Benjamin Kaduk  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.

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

Re: [TLS] WG adoption call: SNI Encryption

[Benjamin Kaduk]

On 08/04/2017 07:50 AM, 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP status_request_v2 extension

[Hubert Kario]

On Tuesday, 15 August 2017 19:42:30 CEST Benjamin Kaduk wrote:
> On 08/14/2017 01:26 PM, Ilari Liusvaara wrote:
> > On Mon, Aug 14, 2017 at 08:03:08PM +0200, Hubert Kario wrote:
> >> Current (21) draft references RFC 6961 in multiple places, in particular
> >> 
> >>  * Section 4.4.2:
> >>  Valid extensions
> >>  include OCSP Status extensions ([RFC6066] and [RFC6961])
> >>  
> >>  * and therein implicitly:
> >>  If
> >>  an extension applies to the entire chain, it SHOULD be included in
> >>  the first CertificateEntry.
> >> 
> >> at the same time section B.3.1 ExtensionType and table from Section 4.2
> >> do not list status_request_v2 as a valid extension.
> >> 
> >> 
> >> If the intention was to deprecate status_request_v2, I think the
> >> references to RFC 6961 should be a bit more cautious. If it wasn't (as
> >> old messages sent to the list would indicate), quite a bit of text is
> >> missing.
> > 
> > The introduction suggests that TLS 1.3 intends to deprecate
> > status_request_v2.
> 
> Yes, the intention was to deprecate status_request_v2.

Proposed text to remove the ambiguity:
https://github.com/tlswg/tls13-spec/pull/1075

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls