Subject: Re: [TLS] Proposed change in TLS-Flags

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 1 Jul 2020 15:54:39 +0000

Yoav,

I looked at the draft and the PR. I am fine with the proposed changes.
This is a short and useful draft.

Ciao
Hannes

From: TLS <[email-masked]> On Behalf Of Yoav Nir
Sent: Monday, June 29, 2020 11:34 PM
To: <[email-masked]> <[email-masked]>
Subject: [TLS] Proposed change in TLS-Flags

Hi

I’ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:

  *   It is no longer allowed to send an empty flags extension.  If you don’t support any flags, don’t send the extension.
  *   The server is no longer allowed to respond with flag types that the client didn’t indicate support for first.
  *   I’ve split the extension description section into a format section and a rules section

Please comment. Barring any objections, I’ll merge the PR just before the submission deadline.

Yoav

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 1 Jul 2020 16:00:13 +0000

One question: Wouldn’t you want to register a flag for "Post-Handshake Client Authentication" in this document?

Ciao
Hannes

From: TLS <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, July 1, 2020 5:55 PM
To: Yoav Nir <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Proposed change in TLS-Flags

Yoav,

Ciao
Hannes

Hi

Three changes:
• It is no longer allowed to send an empty flags extension.  If you don’t support any flags, don’t send the extension.
• The server is no longer allowed to respond with flag types that the client didn’t indicate support for first.
• I’ve split the extension description section into a format section and a rules section

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Jul 2020 21:01:32 +0300

I don’t know. There already is an extension for this.

We haven’t discussed whether we want to “cover” semantics that already exist in other extensions.

If that’s something the group wants, we can add it, but it’s not generally a good thing for a protocol to have two ways of expressing the same thing.

Yoav

> On 1 Jul 2020, at 19:00, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 1 Jul 2020 11:17:23 -0700

Thanks for the context, everyone!
Based on that, PR looks good to me. Ship it!

David

On Tue, Jun 30, 2020 at 9:18 PM Martin Thomson <[email-masked]> wrote:

> More to the point, this makes it more difficult to analyze relative to an
> empty "flag" extension of the likes we currently use.
>
> I haven't implemented this, but I imagine one strategy would be to rewrite
> these flags and pretend that they were empty extensions.  That would allow
> implementations to reuse a lot of infrastructure, like the stuff we added
> for custom extensions.  That would be more difficult if the server can
> speak first.
>
> On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote:
> > Yeah, the thread that Nick mentioned.
> >
> > Also, since there are no such extensions defined in the base TLS 1.3
> > spec, the server can’t assume that the client knows what either the
> > specific flag means, or the entire flags extension means.
> >
> > So suppose we invent some new client authentication scheme for TLS, it
> > does make sense for the server to signal that it supports this so that
> > the client can do. But I don’t think it’s too onerous to require that
> > the client indicate support first.
> >
> > Yoav
> >
> > > On 1 Jul 2020, at 2:30, David Schinazi <[email-masked]>
> wrote:
> > >
> > > Hi Yoav,
> > >
> > > Could you elaborate on the rationale for this change please?
> > > I was assuming that the ability for servers to send extensions not
> requested by clients was useful.
> > >
> > > Thanks,
> > > David
> > >
> > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <[email-masked]> wrote:
> > >> Hi
> > >>
> > >>  * It is no longer allowed to send an empty flags extension. If you
> don’t support any flags, don’t send the extension.
> > >>  * The server is no longer allowed to respond with flag types that
> the client didn’t indicate support for first.
> > >> _______________________________________________
> > >>  TLS mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/tls
> >
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 2 Jul 2020 09:05:46 +0000

Hi Yoav,

> If that’s something the group wants, we can add it, but it’s not generally a good thing for a protocol to have two ways of expressing the same thing.
I saw it more as a "compression" mechanism for those cases where an extension doesn't carry additional content.

Ciao
Hannes

Yoav