Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[Sean Turner]

> On Jun 7, 2018, at 17:00, Benjamin Kaduk  
> wrote:
> 
> But, of course, we should actually ask instead of guessing...

If nobody has asked yet, I can do it.

spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[Hubert Kario]

On Saturday, 9 June 2018 03:13:29 CEST Christian Huitema wrote:
> On 6/8/2018 7:35 AM, David Benjamin wrote:
> > On Fri, Jun 8, 2018 at 10:07 AM R duToit  wrote:
> > > GREASE values should not make their way into code. The whole
> > 
> > point is to get code used to the fact that unknown values exist.
> > 
> > The GREASE mechanism is useful, but it will definitely make its
> > way into code and become ossified itself.  
> > Example:  https://github.com/salesforce/ja3
> > 
> > Indeed. GREASE was targeting normal sensible endpoint implementations...
> 
> ... and maybe we need a different mechanism to defeat fingerprinting
> tools like this JA3 project. Maybe applications need to somehow
> randomize their signatures, so that they are not so easy to recognize.
> For example, it should be possible to use randomize the order of
> extensions. And it should also be possible to throw some grease in these
> sets.
> 
> Of course, the first ones to develop and use these randomization
> techniques will most likely be the malware authors that the tools are
> allegedly trying to track.

you can probe implementations irrespective of enabled ciphers, just by looking 
at the way they handle errors:
https://github.com/WestpointLtd/tls_prober

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[Hubert Kario]

On Wednesday, 6 June 2018 21:08:28 CEST David Benjamin wrote:
> 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
> parse out the "ignore/" string. Instead, what do folks think about just
> using two byte strings. Perhaps the same two byte pattern we're currently
> doing?

+1, it also tests that the server will not expect an ASCII string in ALPN

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[David Benjamin]

On Fri, Jun 8, 2018 at 10:07 AM R duToit  wrote:

> > GREASE values should not make their way into code. The whole point is to
> get code used to the fact that unknown values exist.
>
> The GREASE mechanism is useful, but it will definitely make its way into
> code and become ossified itself.
> Example:  https://github.com/salesforce/ja3
>

Indeed. GREASE was targeting normal sensible endpoint implementations. The
assumption is that our interop problems are merely benign mistakes, and
that if something triggers the developer to notice early enough, they will
simply fix it. For a normal well-behaving server, there is no reason to
special-case GREASE over following the protocol. So the goal is to avoid
accidental special-cases, not folks intentionally trying to fixate on
things that will obviously not remain stable.

Of course, since we first tried this, TLS 1.3 has demonstrated that there
are other players in the ecosystem that are rampantly non-compliant in
exactly that way, notably various middlewave devices. Those are rather a
problem and will need other ideas enforce TLS's long-standing but evidently
ignored protocol invariants
.
I did not propose any new ideas in this document update, as this was just
about updating it to match the prior discussion of rebasing atop TLS 1.3.

David

 On Thu, 07 Jun 2018 17:05:47 -0400 *David Benjamin
> >* wrote 
>
> On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk  wrote:
>
> On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Apologies for the probably record time delay in actually updating this
> > thing. I like the graph... apparently -00 was expired for nearly twice as
> > long as it was valid? Oops!
> >
> > Per the discussion from a really really long while ago, I've rebased the
> > document atop TLS 1.3 and added values for the many more bits added in
> TLS
> > 1.3.
> >
> > Since TLS 1.3 has server-offered extensions, this needed a bit of
> > reorganization. For the one-bit PSK KE values, I borrowed the pattern
> from
> > draft-bishop-httpbis-grease-00.
> >
> > Let me know if folks have any comments. Additionally, I'm curious what
> > folks thoughts are on the following (not incorporated into the document):
> >
> > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks
> to
> > parse out the "ignore/" string. Instead, what do folks think about just
> > using two byte strings. Perhaps the same two byte pattern we're currently
> > doing?
> >
> > 2) This is somewhat of a "how much badly I abuse the registries" thing.
> :-)
> > I have observed one TLS implementation which just transcribed the
> registry
> > directly into their source code. This was done all the way down to
> mapping
> > "Reserved for Private Use" to some dedicated symbol. They successfully
> > ignored the private use value, but the actual unallocated values for each
> > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
> > treated as syntax errors!
> >
> > This was just a single implementation, but it suggests GREASE works
> better
> > when it's not so obviously allocated in the registry. Of course, not
> > recording the values at all is unreasonable as we must avoid allocating
> the
> > values for real. What do folks think about leaving them out of the table
> > but instead adding a note in the registry like:
> >
> > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,
> 0x7A7A,
> > 0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are
> used
> > by [[this document]] for testing implementation correctness. They should
> be
> > left permanently unassigned."
> >
> > An implementor infinitely bad at reading may well still special-case the
> > and defeat all these measures, but that was always the case. Rather, the
> > goal is to find inexpensive ways to lower the failure probability. It
> seems
> > inexpensive to me, but I don't know how much trouble it would cause for
> > IANA.
>
> Unfortunately, (my understanding is that) IANA is moving towards a proper
> database
> for codepoints, and prefer to actually have all values matched up with
> their
> corresponding metadata; I expect that they would not be happy to do
> something
>
> like this.  But, of course, we should actually ask instead of guessing
>
>
> I suppose the question is what the database is meant to be used for. I can
> imagine wanting it to be properly queryable so you can transform it into
> code. GREASE values should not make their way into code. The whole point is
> to get code used to the fact that unknown values exist.
>
> I can also imagine wanting to make it easier to allocate values
> mechnically. Then, yeah, you want the GREASE values in there. But the
> allocations need occasional human input anyway (e.g. 26 and 40), so maybe
> it's fine not to have those in there in a completely structured way?
>
> David
>
> 

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[R duToit]

 GREASE values should not make their way into code. The whole point is to 
get code used to the fact that unknown values exist.



The GREASE mechanism is useful, but it will definitely make its way into code 
and become ossified itself.  

Example:  https://github.com/salesforce/ja3



--Roelof





 On Thu, 07 Jun 2018 17:05:47 -0400 David Benjamin 
david...@chromium.org wrote 




On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk bka...@akamai.com wrote:

On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:

  Hi all,

  

  Apologies for the probably record time delay in actually updating this

  thing. I like the graph... apparently -00 was expired for nearly twice as

  long as it was valid? Oops!

  

  Per the discussion from a really really long while ago, I've rebased the

  document atop TLS 1.3 and added values for the many more bits added in TLS

  1.3.

  

  Since TLS 1.3 has server-offered extensions, this needed a bit of

  reorganization. For the one-bit PSK KE values, I borrowed the pattern from

  draft-bishop-httpbis-grease-00.

  

  Let me know if folks have any comments. Additionally, I'm curious what

  folks thoughts are on the following (not incorporated into the document):

  

  1) "ignore/" is a pretty long ALPN prefix and also might encourage folks 
to

  parse out the "ignore/" string. Instead, what do folks think about just

  using two byte strings. Perhaps the same two byte pattern we're currently

  doing?

  

  2) This is somewhat of a "how much badly I abuse the registries" thing. 
:-)

  I have observed one TLS implementation which just transcribed the registry

  directly into their source code. This was done all the way down to mapping

  "Reserved for Private Use" to some dedicated symbol. They successfully

  ignored the private use value, but the actual unallocated values for each

  of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and

  treated as syntax errors!

  

  This was just a single implementation, but it suggests GREASE works better

  when it's not so obviously allocated in the registry. Of course, not

  recording the values at all is unreasonable as we must avoid allocating 
the

  values for real. What do folks think about leaving them out of the table

  but instead adding a note in the registry like:

  

  "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 
0x7A7A,

  0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are 
used

  by [[this document]] for testing implementation correctness. They should 
be

  left permanently unassigned."

  

  An implementor infinitely bad at reading may well still special-case the

  and defeat all these measures, but that was always the case. Rather, the

  goal is to find inexpensive ways to lower the failure probability. It 
seems

  inexpensive to me, but I don't know how much trouble it would cause for

  IANA.

 

 Unfortunately, (my understanding is that) IANA is moving towards a proper 
database

 for codepoints, and prefer to actually have all values matched up with their

 corresponding metadata; I expect that they would not be happy to do something

 like this.  But, of course, we should actually ask instead of guessing



I suppose the question is what the database is meant to be used for. I can 
imagine wanting it to be properly queryable so you can transform it into code. 
GREASE values should not make their way into code. The whole point is to get 
code used to the fact that unknown values exist.



I can also imagine wanting to make it easier to allocate values mechnically. 
Then, yeah, you want the GREASE values in there. But the allocations need 
occasional human input anyway (e.g. 26 and 40), so maybe it's fine not to have 
those in there in a completely structured way?



David



___

TLS mailing list 

TLS@ietf.org 

https://www.ietf.org/mailman/listinfo/tls 






___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[David Benjamin]

On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk  wrote:

> On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Apologies for the probably record time delay in actually updating this
> > thing. I like the graph... apparently -00 was expired for nearly twice as
> > long as it was valid? Oops!
> >
> > Per the discussion from a really really long while ago, I've rebased the
> > document atop TLS 1.3 and added values for the many more bits added in
> TLS
> > 1.3.
> >
> > Since TLS 1.3 has server-offered extensions, this needed a bit of
> > reorganization. For the one-bit PSK KE values, I borrowed the pattern
> from
> > draft-bishop-httpbis-grease-00.
> >
> > Let me know if folks have any comments. Additionally, I'm curious what
> > folks thoughts are on the following (not incorporated into the document):
> >
> > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks
> to
> > parse out the "ignore/" string. Instead, what do folks think about just
> > using two byte strings. Perhaps the same two byte pattern we're currently
> > doing?
> >
> > 2) This is somewhat of a "how much badly I abuse the registries" thing.
> :-)
> > I have observed one TLS implementation which just transcribed the
> registry
> > directly into their source code. This was done all the way down to
> mapping
> > "Reserved for Private Use" to some dedicated symbol. They successfully
> > ignored the private use value, but the actual unallocated values for each
> > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
> > treated as syntax errors!
> >
> > This was just a single implementation, but it suggests GREASE works
> better
> > when it's not so obviously allocated in the registry. Of course, not
> > recording the values at all is unreasonable as we must avoid allocating
> the
> > values for real. What do folks think about leaving them out of the table
> > but instead adding a note in the registry like:
> >
> > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,
> 0x7A7A,
> > 0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are
> used
> > by [[this document]] for testing implementation correctness. They should
> be
> > left permanently unassigned."
> >
> > An implementor infinitely bad at reading may well still special-case the
> > and defeat all these measures, but that was always the case. Rather, the
> > goal is to find inexpensive ways to lower the failure probability. It
> seems
> > inexpensive to me, but I don't know how much trouble it would cause for
> > IANA.
>
> Unfortunately, (my understanding is that) IANA is moving towards a proper
> database
> for codepoints, and prefer to actually have all values matched up with
> their
> corresponding metadata; I expect that they would not be happy to do
> something
> like this.  But, of course, we should actually ask instead of guessing...
>

I suppose the question is what the database is meant to be used for. I can
imagine wanting it to be properly queryable so you can transform it into
code. GREASE values should not make their way into code. The whole point is
to get code used to the fact that unknown values exist.

I can also imagine wanting to make it easier to allocate values
mechnically. Then, yeah, you want the GREASE values in there. But the
allocations need occasional human input anyway (e.g. 26 and 40), so maybe
it's fine not to have those in there in a completely structured way?

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[Benjamin Kaduk]

On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> Hi all,
> 
> Apologies for the probably record time delay in actually updating this
> thing. I like the graph... apparently -00 was expired for nearly twice as
> long as it was valid? Oops!
> 
> Per the discussion from a really really long while ago, I've rebased the
> document atop TLS 1.3 and added values for the many more bits added in TLS
> 1.3.
> 
> Since TLS 1.3 has server-offered extensions, this needed a bit of
> reorganization. For the one-bit PSK KE values, I borrowed the pattern from
> draft-bishop-httpbis-grease-00.
> 
> Let me know if folks have any comments. Additionally, I'm curious what
> folks thoughts are on the following (not incorporated into the document):
> 
> 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
> parse out the "ignore/" string. Instead, what do folks think about just
> using two byte strings. Perhaps the same two byte pattern we're currently
> doing?
> 
> 2) This is somewhat of a "how much badly I abuse the registries" thing. :-)
> I have observed one TLS implementation which just transcribed the registry
> directly into their source code. This was done all the way down to mapping
> "Reserved for Private Use" to some dedicated symbol. They successfully
> ignored the private use value, but the actual unallocated values for each
> of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
> treated as syntax errors!
> 
> This was just a single implementation, but it suggests GREASE works better
> when it's not so obviously allocated in the registry. Of course, not
> recording the values at all is unreasonable as we must avoid allocating the
> values for real. What do folks think about leaving them out of the table
> but instead adding a note in the registry like:
> 
> "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
> 0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used
> by [[this document]] for testing implementation correctness. They should be
> left permanently unassigned."
> 
> An implementor infinitely bad at reading may well still special-case the
> and defeat all these measures, but that was always the case. Rather, the
> goal is to find inexpensive ways to lower the failure probability. It seems
> inexpensive to me, but I don't know how much trouble it would cause for
> IANA.

Unfortunately, (my understanding is that) IANA is moving towards a proper 
database
for codepoints, and prefer to actually have all values matched up with their
corresponding metadata; I expect that they would not be happy to do something
like this.  But, of course, we should actually ask instead of guessing...

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt

[David Benjamin]

Hi all,

Apologies for the probably record time delay in actually updating this
thing. I like the graph... apparently -00 was expired for nearly twice as
long as it was valid? Oops!

Per the discussion from a really really long while ago, I've rebased the
document atop TLS 1.3 and added values for the many more bits added in TLS
1.3.

Since TLS 1.3 has server-offered extensions, this needed a bit of
reorganization. For the one-bit PSK KE values, I borrowed the pattern from
draft-bishop-httpbis-grease-00.

Let me know if folks have any comments. Additionally, I'm curious what
folks thoughts are on the following (not incorporated into the document):

1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to
parse out the "ignore/" string. Instead, what do folks think about just
using two byte strings. Perhaps the same two byte pattern we're currently
doing?

2) This is somewhat of a "how much badly I abuse the registries" thing. :-)
I have observed one TLS implementation which just transcribed the registry
directly into their source code. This was done all the way down to mapping
"Reserved for Private Use" to some dedicated symbol. They successfully
ignored the private use value, but the actual unallocated values for each
of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and
treated as syntax errors!

This was just a single implementation, but it suggests GREASE works better
when it's not so obviously allocated in the registry. Of course, not
recording the values at all is unreasonable as we must avoid allocating the
values for real. What do folks think about leaving them out of the table
but instead adding a note in the registry like:

"The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
0x8A8A, 0x9A9A, 0x, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used
by [[this document]] for testing implementation correctness. They should be
left permanently unassigned."

An implementor infinitely bad at reading may well still special-case the
and defeat all these measures, but that was always the case. Rather, the
goal is to find inexpensive ways to lower the failure probability. It seems
inexpensive to me, but I don't know how much trouble it would cause for
IANA.

David

On Wed, Jun 6, 2018 at 1:32 PM  wrote:

>
> 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-01.txt
> Pages   : 10
> Date: 2018-06-06
>
> 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-01
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-01
>
>
> 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/
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls