Subject: [TLS] PRs for this morning

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Nov 2014 09:13:45 -1000

Hi folks. At the interim, people asked to see initial treatments of some
proposed changes to TLS 1.3 via the update mechanism. I've
uploaded Work in Progress (i.e., not ready for merging) versions
of these and put them up for comment as pull requests:

Update mechanism:
https://github.com/tlswg/tls13-spec/pull/94

Moving client auth to update:
https://github.com/tlswg/tls13-spec/pull/95

Merging session resumption and tickets and moving ticket
establishment to a update:
https://github.com/tlswg/tls13-spec/pull/96

Warning: both of the latter two build on the first but they are independent
for ease of understanding.

If we have time, we'll be talking about these in the meeting today and
then on the list. If people are generally happy with this approach I'll
prepare
new PRs for WG review (i.e., you will get another chance to take a look).

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Thu, 13 Nov 2014 21:00:37 +0100 (CET)

> https://github.com/tlswg/tls13-spec/pull/96

In case that you intend to add rfc5077 TLS session ticket support
to TLSv1.3, is that using the same bogus CBC-Encryption
(i.e. mac+pad+encrypt instead of pad+mac+encrypt) that Vaudenay
described as a security issue, that was never fixed in TLS up to v1.2
and provided the grounds for LuckyThirteen and Poodle?

If yes, then how about fixing a known design flaw _before_
it is demonstrated to be exploitable?

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 13 Nov 2014 12:13:07 -0800

> and provided the grounds for LuckyThirteen and Poodle?

Ticket encryption is not interop problem. This should be noted for
implementors, but strictly speaking isn't in the protocol.

> it is demonstrated to be exploitable?

Agreed. But do it EtM so it's obviously secure, no matter what encryption
is used.

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

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Thu, 13 Nov 2014 21:20:59 +0100

> and provided the grounds for LuckyThirteen and Poodle?
I'm not sure what you're talking about. To me, RFC 5077 section 4 looks like it
recommends pad+encrypt+mac (aka EEM) which is secure.

   The actual state information in encrypted_state is encrypted using
   128-bit AES in CBC mode with the given IV.  The Message
   Authentication Code (MAC) is calculated using HMAC-SHA-256 over
   key_name (16 octets) and IV (16 octets), followed by the length of
   the encrypted_state field (2 octets) and its contents (variable
   length).

Manuel.

---

From: [email-masked] (Martin Rex)
Date: Thu, 13 Nov 2014 21:21:31 +0100 (CET)

> it is demonstrated to be exploitable?

Although .. reading the relevant part of rfc5077 again, it's possible
that rfc5077 session tickets are already using EtM, and only the
PDU & description is misleading.

http://tools.ietf.org/html/rfc5077#section-4

   The ticket is structured as follows:

      struct {
          opaque key_name[16];
          opaque iv[16];
-         opaque encrypted_state<0..2^16-1>;
+         opaque cbc_encrypted_state<0..2^16-16>;
          opaque mac[32];
      } ticket;

-  length).
+  length, but integer multiple of the AES blocksize (16)).

Considering that a client will have to send a ticket to the server
inside a TLS extension for resumption, and that all extensions inside
ClientHello combined must fit within 2^16, the true maximum size
of encrypted_state is more like (2^16-128), but using (2^16-16)
is more indicative about the integer multiple of AES blocksize characteristic.

Sorry for the confusion.

-Martin