Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

This is a pretty good piece of information that is very nearly done.

Regarding the idnits results, DoH is done, but DTLS and QUIC are still
a way off.  Would we prefer publication with downref or waiting?  For
me, this depends somewhat on the maturity of the documents that depend
on this.  I'd be willing to wait until those documents would have to
wait for this one.

3.6 mentions attack by the fronting server or the multiplexed server.
But the multiplexed server is the desired endpoint.  I think that you
can drop any reference to the multiplexed server here.  It might
require some reframing.

3.8.1 says that it "is thus desirable that SNI Encryption mechanisms
be also able hide the ALPN."  I think that we ultimately decided that
while the techniques might be usable, it would be preferable to
encrypt these independently.  (Noting that SNI encryption as specified
is rather bulky...)

3.9 suggests that parameters might be stripped from the ClientHello:

   When designing SNI encryption schemes, we have to take into account
   attacks that strip parameters from the Client Hello, or replay
   attacks.  In both cases, the desired behavior is to fall back to a
   connection with the fronting server, so there is no visble difference
   between a regular connection to that server and an attempt to reach
   the hidden server.

But any attack that modifies the ClientHello will cause the handshake
to fail when the client receives the Finished from the server (i.e.,
immediately). Not to mention the server certificate being for a name
the client doesn't expect.

The problem is that you can construct scenarios with controlled
release of a spoofed server flight to test whether a client is willing
to continue the connection.  Note that you can't do a controlled
release of a real flight from a server because any modification to the
ClientHello will result in different handshake keys.

(Note also the typo: visble)

I don't know what was really intended by this section, but it needs work.

4 fails to acknowledge other work in this area, like
draft-ietf-httpbis-http2-secondary-certs and the ORIGIN frame (RFC
8336).

Nits:

The document contains a mix of title- and sentence- case headings.

Terms are inconsistently capitalized throughout (like Fronting Server).

2.1 list construction requires "and" or "or"
   o  Enterprise firewalls blocking web sites not deemed appropriate for
      work, +and+

2.3 missing "of"
   Deploying SNI encryption will help thwarting most +of+ the "unanticipated"

3.8 subject object disagreement
   The SNI encryption requirement do+es+ not stop with HTTP over TLS.

3.9.  Fail to fronting <- not sure what this phrase means

3.9 also has inconsistent use of "client hello" vs. "Client Hello".  I
think that it's supposed to be "ClientHello".

4 just drop "/some-content" from the example, it doesn't help (and
it's badly wrapped)
4 mismatched quotes on 'co-tenant"

On Wed, Oct 17, 2018 at 10:04 AM Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> I ran I-D nits before hitting the appropriate buttons to place this draft in WGLC.  I figured we could address the following before we send the draft to Ben:
>
>   == Outdated reference: draft-ietf-tls-tls13 has been
>        published as RFC 8446
>
>   == Outdated reference: A later version (-14) exists of
>        draft-ietf-doh-dns-over-https-08
>
>   == Outdated reference: A later version (-15) exists of
>        draft-ietf-quic-tls-11
>
>   == Outdated reference: A later version (-28) exists of
>        draft-ietf-tls-dtls13-26
>
>   == Outdated reference: draft-mm-wg-effect-encrypt has
>        been published as RFC 8404
>
> To answer the other 5 I-D nits questions "Obsolete informational reference (is this intentional?)” - the answer is yes.
>
> spt
>
> > On Oct 16, 2018, at 18:43, Sean Turner <sean@sn3rd.com> wrote:
> >
> > All,
> >
> > This is the working group last call for the "Issues and Requirements for SNI Encryption in TLS" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.  Please review the document and send your comments to the list by 2359 UTC on 31 October 2018.
> >
> > Thanks your chairs: C-J-S
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls