Subject: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda)

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Mar 2015 05:18:45 +0000

Ilari Liusvaara <[email-masked]> writes:

>Backwards compatibility:
>
>Is this about what is needed for compatiblity with past TLS versions?

TLS 1.3, which I've already pointed out several times has so little backwards
compatibility that it should be called TLS 2.0, doesn't need to be hamstrung
with retaining stuff from the other TLS 1.x versions, for example the totally
pointless:

>- The first byte of record header needs to remain subprotocol id (for
>  muxing TLS with other stuff)

(and many others).  It's already so different even to TLS 1.2 that there's no
point in retaining some crufty old artefact of SSL 3.0 just because we've
always done it this way.  If there's a feature that's useful or important to
the functioning of the protocol then by all means include it, but there's no
point in dragging along old protocol misfeatures "for backwards compatibility"
when so much else has changed incompatibly.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 11 Mar 2015 11:15:15 +0200

> with retaining stuff from the other TLS 1.x versions, for example the totally

Here by backwards compatiblity, I interpret:

"Possiblity to securely downnegotiate to earlier versions without reconnect."

This has the following implications:
- TLS 1.2 servers have to be able to interpret the TLS 1.3 first flight in
  a sane way, so handshake can continue.
- TLS 1.3 clients have to be able to interpret the TLS 1.2 first flight in
  a sane way, so handshake can continue.

Not doing this is basically either a major security hole or serious deployment
obstacle.

> when so much else has changed incompatibly.

There actually are _protocols_ that _break_ if TLS ever generates first byte
of record that isn't on certain range (20-63 / 0x14-0x3F), and that is the
only non-abstract requirement (not easily re-definable by TLS). Radical
handshake changes are OK.

Or protocols that break if TLS ever starts the connection with byte that isn't
0x16 (but this is also required by "backward compatiblity" as defined above).

E.g. Redefine what record type 0x17 (which is appdata in TLS 1.2) means? Sure,
no problem. Drop 0x14 (ChangeCipherSpec)? No problemo. Enable encryption in
the middle of hanshake? Ditto.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Mar 2015 08:16:53 -0700

> when so much else has changed incompatibly.

I agree. We should focus in simplifying implementations of TLS 1.3 and TLS
1.2, and it seems that this means assuming minimal (read none)  code reuse,
and focusing on simplifying TLS 1.3 on its own terms.

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 11 Mar 2015 20:56:12 +0200

> and focusing on simplifying TLS 1.3 on its own terms.

The kind of backward compatiblity I am talking about:
- Be able to do secure downnegotiation to TLS 1.2.
- Don't break protocols using TLS.

These would impose the following constraints:
- The first flight can only have TLS 1.2-compatible ClientHello (unless
  server is known to be 1.3-capable and client is prepared to take
  heavy latencies otherwise).
- The second flight has to be always distinguishable from TLS 1.2.
  (recordversion field should do here?)
- Not using record types (first byte of record) outside 20-63 range.
- TLS-Unique and TLS-Exporter APIs are still there.

The following are examples of changes outside scope of backwards compat:
- Removing recordversion from encrypted records.
- Redefining recordtype values (within range, some of that already done).
- Redefining TLS-Unique and TLS-Exporter internals.
- Totally rearranging the handshake (already done)

Also, to me the current TLS 1.3 draft looks to be much more hardened
against cryptographic attacks than TLS 1.2 (even with session_hash).
And the source of this resistance is precisely encrypting as much as
possible together with CRK.

-Ilari