Re: [TLS] GREASE and TLS 1.3

[Sean Turner]

> On Jan 18, 2017, at 17:49, David Benjamin  wrote:
> 
> Do people agree with this plan?

Looks like we got general agreement this is a good approach to follow.

spt

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

Re: [TLS] GREASE and TLS 1.3

[Hubert Kario]

On Thursday, 19 January 2017 13:31:31 CET Benjamin Kaduk wrote:
> On 01/18/2017 04:49 PM, David Benjamin wrote:
> > Do people agree with this plan?
> 
> Yes :)
> 
> > I've left out psk_key_exchange_modes. It would be nice to GREASE that
> > too, but it uses u8 rather than u16 values. The natural generalization
> > is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256
> > code points, rather than 16 out of 65536 code points. Do people feel
> > this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this
> > not worth bothering with?
> 
> I feel like we're unlikely to come up with enough modes that we run out
> of space, so it is probably okay to grease it.  But I would be okay if
> people wanted to not do so, too.
> 
> -Ben

+1 to greasing psk_key_exchange_modes

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, 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] GREASE and TLS 1.3

[Eric Rescorla]

Grease away.

On Thu, Jan 19, 2017 at 11:31 AM, Benjamin Kaduk  wrote:

> On 01/18/2017 04:49 PM, David Benjamin wrote:
>
>
> Do people agree with this plan?
>
>
> Yes :)
>
> I've left out psk_key_exchange_modes. It would be nice to GREASE that too,
> but it uses u8 rather than u16 values. The natural generalization is to
> reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points,
> rather than 16 out of 65536 code points. Do people feel this is an
> acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth
> bothering with?
>
>
> I feel like we're unlikely to come up with enough modes that we run out of
> space, so it is probably okay to grease it.  But I would be okay if people
> wanted to not do so, too.
>
> -Ben
>
> ___
> 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] GREASE and TLS 1.3

[Benjamin Kaduk]

On 01/18/2017 04:49 PM, David Benjamin wrote:
>
> Do people agree with this plan?
>

Yes :)

> I've left out psk_key_exchange_modes. It would be nice to GREASE that
> too, but it uses u8 rather than u16 values. The natural generalization
> is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256
> code points, rather than 16 out of 65536 code points. Do people feel
> this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this
> not worth bothering with?
>

I feel like we're unlikely to come up with enough modes that we run out
of space, so it is probably okay to grease it.  But I would be okay if
people wanted to not do so, too.

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

Re: [TLS] GREASE and TLS 1.3

[山本和彦]

> That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
> front of supported_groups and then put it in key_shares with a one-byte
> fake KeyShareEntry.
> 
> It costs five bytes total and, having already caught a bug with it, seems
> valuable. It ensures that servers are capable of skipping over an unknown
> KeyShareEntry and don't just go for the first one. But, document-wise, I
> was expecting to just use MAY for everything rather than expressing much
> opinion.

OK.

--Kazu

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

Re: [TLS] GREASE and TLS 1.3

[David Benjamin]

On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson 
wrote:

On 19 January 2017 at 14:04, Kazu Yamamoto  wrote:
> Should we also add grease values for key_share?

supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.  I guess that you *could*, but
whether the document should recommend it 


That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
front of supported_groups and then put it in key_shares with a one-byte
fake KeyShareEntry.

It costs five bytes total and, having already caught a bug with it, seems
valuable. It ensures that servers are capable of skipping over an unknown
KeyShareEntry and don't just go for the first one. But, document-wise, I
was expecting to just use MAY for everything rather than expressing much
opinion.

(Front is because presumably if we add a new NamedGroup, it'd be because we
like it more than our current ones rather than less! So it's more important
that that edge continue working.)

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

Re: [TLS] GREASE and TLS 1.3

[Martin Thomson]

On 19 January 2017 at 14:04, Kazu Yamamoto  wrote:
> Should we also add grease values for key_share?

supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.  I guess that you *could*, but
whether the document should recommend it 

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

Re: [TLS] GREASE and TLS 1.3

[山本和彦]

Hi David,

> I was thinking of making the following changes:
> 
> - Cite TLS 1.3 instead of TLS 1.2.
> 
> - Add some text to use the same code point pattern for TLS 1.3
> signature_algorithms.
> 
> - Add some text to suggest advertising GREASE values in key_shares if
> advertised in supported_groups. [This already caught a bug.]
> 
> - Add some text to use the same code point pattern for
> supported_versions. [This already caught a bug.]
> 
> - Generalize the extensions text to allow for CertificateRequest and
> NewSessionTicket extensions sent by the server. [This might have caught a
> bug had it not been caught by other means first.]
> 
> Do people agree with this plan?

I agree.

Should we also add grease values for key_share?

--Kazu

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

[TLS] GREASE and TLS 1.3

[David Benjamin]

So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite
large chunks of it. The draft is currently defined for TLS 1.2, but it
probably makes sense to order it after TLS 1.3.

TLS 1.3 also adds a many new extension points, and we can expect new TLS
1.3 implementations popping up in the near future, so having the ecosystem
primed against intolerance bugs would be great.

(As a happy anecdote, Chrome is currently GREASEing bits of its draft TLS
1.3 implementation. This worked beautifully. There was a draft TLS 1.3
server implementation that broke on unknown versions in supported_versions
and unknown groups in key_shares. Interop testing against a normal client
did not notice. When they tried interop testing against Chrome, the bugs
were caught and fixed.)

I was thinking of making the following changes:

- Cite TLS 1.3 instead of TLS 1.2.

- Add some text to use the same code point pattern for TLS 1.3
signature_algorithms.

- Add some text to suggest advertising GREASE values in key_shares if
advertised in supported_groups. [This already caught a bug.]

- Add some text to use the same code point pattern for
supported_versions. [This already caught a bug.]

- Generalize the extensions text to allow for CertificateRequest and
NewSessionTicket extensions sent by the server. [This might have caught a
bug had it not been caught by other means first.]

Do people agree with this plan?

I've left out psk_key_exchange_modes. It would be nice to GREASE that too,
but it uses u8 rather than u16 values. The natural generalization is to
reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points,
rather than 16 out of 65536 code points. Do people feel this is an
acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth
bothering with?

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