Subject: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

From: [email-masked]
Date: Mon, 12 Aug 2019 10:48: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           : A Flags Extension for TLS 1.3
        Author          : Yoav Nir
	Filename        : draft-ietf-tls-tlsflags-00.txt
	Pages           : 6
	Date            : 2019-08-12

Abstract:
   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.

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

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

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: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Aug 2019 21:25:19 +0300

> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00

Two things:

1) uint8 flags<0..31>;

That adds an extra byte that is not technically necressary (because
extensions have lengths anyway) and limits number of flags to 248
(which might be enough).

And I do not think the length of flags field can be 0 (if it would
be, one could just omit the extension).

2) I think the bit order within octets should be reversed

That is, pack flags so that 0 is LSB of first octet, 7 is MSB of
first octet, 8 is LSB of second octet and so on.

Then one can read status flags by index with code like:

fn read_flag(flags: &[u8], idx: usize) -> bool
{
        *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0
}

(That code will also happily handle out-of-array flags by reading
them as false.)

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Aug 2019 20:51:56 +0300

Hi.

This is an almost exact copy of draft-nir-tls-tlsflags-02.  Since that is the draft that was adopted, I submitted at as the -00 version.

I will reply to comments that came up during the adoption call later today or tomorrow, but feel free to comment some more.

Yoav

> On 12 Aug 2019, at 20:48, [email-masked] wrote:
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 19:59:11 -0500

> And I do not think the length of flags field can be 0 (if it would

I think you need to send it in at least one protocol "response", to
confirm support for the extension, even if none of the flags offered
require confirmation/echo individually.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Aug 2019 18:03:32 -0700

> require confirmation/echo individually.

I'm not sure this is the case: if in the future we define flags, then
what is the difference between not understanding any flag and not
understanding the extension?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 20:12:00 -0500

> understanding the extension?

Nothing -- the difference is between understanding the "please frobnitz
my baddle" flag and not understanding it (or the extension, for that
matter).  If "please frobnitz my baddle" is defined such that it appears
in the ClientHello and if the server supports the extension, the server
has the option to send a Thwarp handshake message to the client at any
time post-handshake if the server detects its imminent demise, then the
client that observes "I didn't get a Thwarp" cannot distinguish between
"the server doesn't support the extension" and "the server supports the
extension but is unaware of an imminent demise".

Does that help?

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Aug 2019 18:23:54 -0700

> extension but is unaware of an imminent demise".

But then you would send the flag back in the Server Hello, no?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 20:36:12 -0500

> But then you would send the flag back in the Server Hello, no?

If you define the extension with those semantics, yes.  We've in the
past wanted to reserve the option of having, well, the
post_handshake_auth semantics, where the client indicates a capability
and the server can optionally send a new protocol message.  Would it be
a huge loss if we didn't have that ability for things that want to use
the flags extension?  No.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 14 Aug 2019 08:41:17 +0300

> a huge loss if we didn't have that ability for things that want to use

Note that interpretation problems arise anyway if one has at least two
non-acknowledgeable flags:

- Client sends non-acknowledgeable flags X and Y.
- Server does not send flags / sends empty flags.

What do those mean? The case that come to mind are:

- Server does not support X nor Y.
- Server does not support X nor Y, but supports some other flags
  client did not send.
- Server supports X but not Y.
- Server supports Y but not X.
- Server supports both X and Y.

And server advertising some optional feature not releated to client
certificate or resumption is forbidden with regular extensions anyway.
But if one wanted such feature for flags, one would have to allow
"offer messages" (CH and CR) to contain empty flags, yes ("response
messages" (SH, EE, CT) do not need to be empty for that, and ST is
its own special case).

In general, if some extension only makes invalid into valid, one only
needs receiver acknowledgement of support (but may need sender
advertisment if protocol does not support recevier giving such
acknowledgement otherwise). If the extension alters meaning of valid,
one needs bidirectional negotiation anyway.

And there could be extensions that can alter what server sends before
server_hello (e.g., extended_alert that alters the alert format in
compatible way). Those are impossible to bidirectionally negotatiate,
but unidirectional capability advertisment is possible.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2019 20:21:17 +0300

> On 12 Aug 2019, at 21:25, Ilari Liusvaara <[email-masked]> wrote:
> 

I hope 248 is enough...

> be, one could just omit the extension).

There could be a future flag that the server sends unsolicited (client-auth-required?).  It’s important for the client to show support for the flags extension to make sure that it understands what the server is sending.

Depends on how we define the semantics in the draft.

> (That code will also happily handle out-of-array flags by reading

Makes sense. I get caught up in visualizing computer memory and protocol messages as a string of bits written from left to right.