Subject: [TLS] I-D Action: draft-ietf-tls-grease-02.txt

From: [email-masked]
Date: Wed, 16 Jan 2019 12:25:26 -0800

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           : Applying GREASE to TLS Extensibility
        Author          : David Benjamin
	Filename        : draft-ietf-tls-grease-02.txt
	Pages           : 11
	Date            : 2019-01-16

Abstract:
   This document describes GREASE (Generate Random Extensions And
   Sustain Extensibility), a mechanism to prevent extensibility failures
   in the TLS ecosystem.  It reserves a set of TLS protocol values that
   may be advertised to ensure peers correctly handle unknown values.

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

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

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

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: Hubert Kario <[email-masked]>
Date: Thu, 17 Jan 2019 18:04:57 +0100

> https://tools.ietf.org/html/draft-ietf-tls-grease-02

while record_size_limit extension sends just one value, it does specifically 
allow the client to advertise higher values than the protocol versions or 
extensions would indicate

I wonder if sending such values shouldn't be part of GREASE behaviour, even if 
it wouldn't use GREASE values...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Thu, 17 Jan 2019 14:23:37 -0600

> it wouldn't use GREASE values...

I think that should be sorted out in a separate document. This one's been
sitting around for a while as it is, and record_size_limit doesn't have an
RFC to cite yet. :-)

David

---

From: Hubert Kario <[email-masked]>
Date: Thu, 17 Jan 2019 21:31:35 +0100

> sitting around for a while as it is, and record_size_limit doesn't have an

eee? https://tools.ietf.org/html/rfc8449

---

From: David Benjamin <[email-masked]>
Date: Thu, 17 Jan 2019 14:38:00 -0600

> eee? https://tools.ietf.org/html/rfc8449

Oh, huh. It wasn't linked from
https://tools.ietf.org/html/draft-ietf-tls-record-limit-03, so I didn't see
it.

David

---

From: Sean Turner <[email-masked]>
Date: Thu, 24 Jan 2019 10:48:57 -0500

> On Jan 17, 2019, at 15:38, David Benjamin <[email-masked]> wrote:
> 
> Oh, huh. It wasn't linked from https://tools.ietf.org/html/draft-ietf-tls-record-limit-03, so I didn't see it.
> 
> David

I was minutes away from issuing the WGLC for this draft when Hubert’s message came in.  I want to make sure we address his comment, but I also want to get the WGLC going.  Since this is the only known issue, the WGLC will refer to issue specifically (and this thread) to see if we can bring it to a close.  You can comment on the WGLC thread or in this thread.  

spt

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Jan 2019 10:03:25 +1100

> sitting around for a while as it is, and record_size_limit doesn't have an

I'm in two minds about this.  On the one hand, we don't need any actual machinery here, so why do anything?  On the other hand, it's just a note that this is possible, and adding that sort of note is easy.

> The record_size_limit extension {{!RFC8449}} includes a value that can be greased by endpoints that don't place constraints on their record size.  Advertising values larger than the protocol supports is permitted and has no effect on the behavior of a compliant peer.

---

From: David Benjamin <[email-masked]>
Date: Fri, 25 Jan 2019 10:23:22 -0600

On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson <[email-masked]> wrote:

> I'm in two minds about this.  On the one hand, we don't need any actual
> machinery here, so why do anything?  On the other hand, it's just a note
> that this is possible, and adding that sort of note is easy.
>
> > The record_size_limit extension {{!RFC8449}} includes a value that can
> be greased by endpoints that don't place constraints on their record size.
> Advertising values larger than the protocol supports is permitted and has
> no effect on the behavior of a compliant peer.
>

I don't feel very strongly either way, though it is odd that it basically
contradicts the sender's rules in RFC 8449.

   Higher values are currently reserved for future
   versions of the protocol that may allow larger records; an endpoint
   MUST NOT send a value higher than the protocol-defined maximum record
   size unless explicitly allowed by such a future version or extension.
   A server MUST NOT enforce this restriction; a client might advertise
   a higher limit that is enabled by an extension or version the server

It does say "unless explicitly allowed by such a future version or
extension", so this is basically blanket overruling that sentence a few
months after publication. (But overruling it isn't entirely wrong, given
the current text imposes a future-proofing receiver rule that the sender is
forbidden from checking.)

David

---

From: Hubert Kario <[email-masked]>
Date: Fri, 25 Jan 2019 19:45:43 +0100

On Friday, 25 January 2019 17:23:22 CET David Benjamin wrote:
> > > > allow the client to advertise higher values than the protocol versions
> > 
> > or
> > 
> > > sitting around for a while as it is, and record_size_limit doesn't have
> > 
> > an
> > 
> > > RFC to cite yet. :-)
> > 

we can claim that GREASE cipher suites are signalling cipher suite value for 
this purpose ("unless explicitly allowed by (...) extension")...

but my point was that to ensure future-proofing that "MUST NOT enforce" is 
much more important to keep flexible that to be strict ("MUST NOT send")

*unless* the idea was to later create an RFC that just increases the maximum 
record sizes without introducing any additional extension to signal support 
for it – which I don't think would be safe to do
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Jan 2019 08:46:32 +1100

> months after publication. 

Yeah, it's not ideal.  Given that, I'd say that we don't need to say anything.  It's still safe to grease by setting smaller values, but the value in doing so is hopefully marginal.