Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

From: Joseph Salowey <[email-masked]>
Date: Wed, 26 Oct 2016 19:56:12 -0700

This is a working group last call announcement for draft-ietf-tls-tls13-18,
to run through November 20. If possible, we would like to receive comments
on the list by November 13 so they can be discussed at the meeting in
Seoul. We hope to address any substantive issues raised during that process
shortly thereafter.

In order to allow for cryptographic review, we will delay submission of the
draft to the IESG until the end of January 2017; there will be an
opportunity to address any issues discovered by the cryptographic community
prior to submission to the IESG.

Cheers,

Joe

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Oct 2016 11:07:24 +0000

So isn't it really a WGLC that runs until end of January 2017?

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: [email-masked] (Martin Rex)
Date: Fri, 28 Oct 2016 18:00:03 +0200 (CEST)

> prior to submission to the IESG.

There are two seriously backwards-incompatible changes in the
current proposal that provide zero value, but completely break
backwards-compatibility with existing middleware infrastructure.

(1) hiding of the TLS record content types.
    Please leave the TLS record types (handshake/AppData/Alert/CCS)
    clearly visible on the outside of the TLS records, so that
    middleware protocol parsers (which interface to transport-free
    TLS protocol stacks) can continue to work, and continue to
    work efficiently.

(2) hiding of the TLS extension SNI.
    Right now it is perferctly fine to implement TLS extensions SNI
    on the server completely outside the TLS protocol stack to route
    to single-cert SNI-unaware backends.  The current proposal
    suggest to move TLS extension SNI into the encrypted part, if
    my superficial reading of the draft is correct, so TLSv1.3
    will not fly with existing architectures where spreading of
    TLS requests on the server-side based on TLS extension SNI
    is done outside of the TLS protocol stack (i.e. bottleneck-less
    without having to open TLS).

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 28 Oct 2016 19:24:26 +0300

>     TLS protocol stacks) can continue to work, and continue to

Hiding the types does have its benefits (and it is also used for
zero-overhead padding scheme).

And also, TLS 1.3 handshake is so darn different from TLS 1.2, that
you couldn't do anything sane even if you had record types.
 
>     without having to open TLS).

Who actually cares about server-side SNI? And it wasn't like you
could do anything useful with server-side SNI in TLS 1.2 either.

You can still route connections on SNI, and it even works the
same way it did in TLS 1.2 (so existing code works).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Oct 2016 05:03:56 +1100

>     TLS protocol stacks) can continue to work, and continue to

I'll let the chairs determine how to handle this.

>     without having to open TLS).

This isn't quite right. In RFC 6066, the client sends its server_name
extension in ClientHello and the server responds with an empty
server_name in its ServerHello to indicate that it accepted SNI.

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

In TLS 1.3, the client's extension remains where it is, but the server's
extension is in EncryptedExtensions. This shouldn't interfere with
configurations such as the one you describe, as the server already
needed to insert the SNI field itself and hash it into Finished.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Fri, 28 Oct 2016 20:23:42 +0200 (CEST)

If the server_name remains in plaintext and full sight in ClientHello
(where it needs to be for TLSv1.2 backwards compatibility anyway),
then I don't have an issue.  (I'm sorry for not reading the draft in full).

> server_name in its ServerHello to indicate that it accepted SNI.

Yes, I know that rfc6066 suggests the server responds with an empty SNI
extension.  This kind of server response is is a complete waste,
and server-side SNI works just fine with the server not returning
an empty SNI extension.

> needed to insert the SNI field itself and hash it into Finished.

Nope, the server doesn't need to insert anything at all.  The empty
TLS extensions SNI in ServerHello is completely superflouous.

If this is really about "hinding the empty TLS extension SNI response",
while leaving the actualy server_name in full sight in the cleartext
ClientHello, why not just dropping the ServerHello TLS extension SNI
response and be done with it?  It really has no functional value other
than information discovery for scanners (the bad guys).

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Oct 2016 05:30:08 +1100

On Sat, Oct 29, 2016 at 5:23 AM, Martin Rex <[email-masked]> wrote:

> then I don't have an issue.  (I'm sorry for not reading the draft in full)

Good to hear.

> than information discovery for scanners (the bad guys).

I would be fine with that if others are. Here's how we got here:

- RFC 6066 requires it (it's a SHALL level requirement).
- We didn't see a need to update the semantics of 6066
- Everything that doesn't have to be in ServerHello goes into EE.

If point #2 is wrong, then that's easy to change, though it would be a
change to
implementations. NSS, for instance, sends it:
http://searchfox.org/nss/source/lib/ssl/ssl3ext.c#436
-Ekr

---

From: [email-masked] (Martin Rex)
Date: Fri, 28 Oct 2016 20:35:45 +0200 (CEST)

Ilari Liusvaara wrote:
> Martin Rex wrote:

Nope, ZERO benefits.  But it totally breaks the middleware
_at_the_endpoints_!

> you couldn't do anything sane even if you had record types.

Wrong.

If one is using an architecture where the TLS protocol stack is
transportless, so that the network communication can be performed
efficiently (coalescing TLS records that are trickling in), then
the *REAL* content type is quite important for knowing whether
the TLS handshake is still ongoing, or whether it is already
complete.

The way I've built this is that the middleware has a timeout for
the TLS handshake in its entirety (independent of the number of
roundtrips), and at the same time promises the application a
network readable event for every incoming TLS record with
application data.  This only works if I can leave TLS appdata
records partially in the incoming network buffer, and for this
I must be able to recognize them.

For processing TLS records with Handshake messages, pre-reading and
passing multiple of them is preferable and much more efficient
(if TLS handshake messages come in seperate TLS records each, which
some implementations do).  Pre-reading TLS records with handshake messages,
but not prereading TLS records with AppData (so that network readable
events will remain visible for app data) is only possible if I see the
contents on the outside of the record by just reading the TLS record header.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 29 Oct 2016 17:22:28 +0300

> Nope, ZERO benefits.  But it totally breaks the middleware

Allowing padding is already a large benefit. TLS 1.2 AEAD modes don't
allow padding, causing rather large unavoidable information leaks.
Especially with HTTP/1.1, which doesn't have application-level padding
mechanism nor multiplexing.

Also, things like this should have been discussed like year or two
ago. Right now it is too late for major changes like this without good
cryptographic justifications (which AFAICT don't exist).

> the TLS handshake is still ongoing, or whether it is already

I implemented zero-copy (for TLS decoding) packet receving in TLS
lib I am writing. Works in both TLS 1.2 and 1.3.

Rather big efficiency boost too... I suspect doing the same for
encoding would be another big efficiency boost.

> I must be able to recognize them.

Note that even if the record is truly appdata, it may not contain
any data, and one can't tell this from just the type.

> contents on the outside of the record by just reading the TLS record header.

Also, TLS 1.3, it isn't safe to reorder appdata records across
handshake records, which can be sent after primary handshake
has completed.

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Mon, 31 Oct 2016 09:46:27 -0400

The concern here is that people won’t review it until the end and that is definitely not what we want.  I’d really like get the most out of our f2f meeting in Seoul so pretty please people review it before Seoul.

spt

> On Oct 27, 2016, at 07:07, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls