Subject: [TLS] I-D Action: draft-rescorla-tls-ctls-04.txt

From: [email-masked]
Date: Mon, 09 Mar 2020 13:21:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Compact TLS 1.3
        Authors         : Eric Rescorla
                          Richard Barnes
                          Hannes Tschofenig
	Filename        : draft-rescorla-tls-ctls-04.txt
	Pages           : 17
	Date            : 2020-03-09

Abstract:
   This document specifies a "compact" version of TLS 1.3.  It is
   isomorphic to TLS 1.3 but saves space by trimming obsolete material,
   tighter encoding, and a template-based specialization technique. cTLS
   is not directly interoperable with TLS 1.3, but it should eventually
   be possible for a cTLS/TLS 1.3 server to exist and successfully
   interoperate.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-rescorla-tls-ctls-04
https://datatracker.ietf.org/doc/html/draft-rescorla-tls-ctls-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rescorla-tls-ctls-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Mar 2020 20:17:12 -0700

One thing I noticed from my reading is there is no gain from knowing
an extension will be present if one doesn't also know the value. I
could imagine SNI being very useful to include, and knowing the order
of extension values permits their omission, keeping only the length.
This does mean very little freedom to add new unknown extensions.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Mar 2020 15:27:30 +1100

On Tue, Mar 10, 2020, at 14:17, Watson Ladd wrote:
> an extension will be present if one doesn't also know the value.

That is only true if the extension has a value.  (See also flags)

> I could imagine SNI being very useful to include, and knowing the order

I believe that is the idea: put the extension at a fixed location so that you don't have to signal its type, just its value.

> This does mean very little freedom to add new unknown extensions.

I don't think that is necessarily true.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Mar 2020 12:42:13 -0400

So it seems like that would add a third class of extension:

1. Required extensions (type + value), not serialized
2. Required extensions (type only) [<--new], serialized as length+value
3. Optional extensions, serialized as type+length+value

There is some appeal to the logical completeness.  The main complication
would be serialization, just because you now have two serialized
representations of an extension, length+value and type+length+value.  You
would probably want to serialize in two vectors (one of each type), to
avoid switching within the Extension struct, which means that you'd always
have two vector lengths instead of one, thus at least one byte of wire
overhead for having the mechanism at all.

Net/net, I'm not sure the need justifies the complexity.

--Richard

On Tue, Mar 10, 2020 at 12:28 AM Martin Thomson <[email-masked]> wrote:

> I believe that is the idea: put the extension at a fixed location so that
> you don't have to signal its type, just its value.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>