Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

From: Alex C <[email-masked]>
Date: Mon, 4 Dec 2017 22:59:13 +1300

The obvious problem with randomly adding fake versions is you have to have
a way of ensuring they won't conflict with *real* future versions - and
whatever pattern you decide upon in order to do that, middleboxes will use
that pattern to filter out fake versions, and fail as soon as you present
one with a real future version (i.e. TLS 1.4).

Can I also suggest adding a section about expected middlebox behaviour to
TLS 1.3? That way there is a reasonable chance that TLS 1.4 won't face the
same issues.
(Or can I do that myself? I'm not really familiar with the process, sorry)

On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Bao <[email-masked]>
wrote:

> That only applies to the ClientHello.
>
> ________________________________________
> From: Andrei Popov <[email-masked]>
> Sent: Wednesday, November 22, 2017 11:22:23 AM
> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
> Cc: [email-masked]; Tapio Sokura
> Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness
>
> The idea was for the client to randomly add non-existent TLS versions to
> supported_versions.
> Presumably, this will exercise the extensibility joint and prevent it from
> becoming unusable.
>
> I'm not convinced this new approach will help, but we know the old one
> required fallbacks every time a new protocol version was introduced.
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
> Sent: Wednesday, November 22, 2017 11:04 AM
> To: Peter Saint-Andre <[email-masked]>; Eric Rescorla <[email-masked]>
> Cc: [email-masked]; Tapio Sokura <[email-masked]>
> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
>
> They are basically doing a supported_versions extension with only one
> entry in the ServerHello.
> The problem with future middleboxes should be obvious.
>
> ________________________________________
> From: Peter Saint-Andre <[email-masked]>
> Sent: Wednesday, November 22, 2017 11:02:39 AM
> To: Yuhong Bao; Eric Rescorla
> Cc: [email-masked]; Tapio Sokura
> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
>
> On 11/22/17 11:16 AM, Yuhong Bao wrote:
> > The problem is not TLS 1.3, the problem is future versions of TLS.
>
> Would you mind explaining that in more detail?
>
> Peter
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&
> data=02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531db
> dbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636469742719473989&sdata=fCAZVB8XHK3IJQAoSf%
> 2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D&reserved=0
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Dec 2017 04:03:27 -0800

> (Or can I do that myself? I'm not really familiar with the process, sorry)
Yes, you can send a a PR at:
https://github.com/tlswg/tls13-spec/

-Ekr

>> Presumably, this will exercise the extensibility joint and prevent it
>> from becoming unusable.
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%
>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%
>> 7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d5
>> 31dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469
>> 742719473989&sdata=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS
>> %2BPW8%3D&reserved=0
>>

---

From: Alex C <[email-masked]>
Date: Thu, 7 Dec 2017 19:48:03 +1300

Thanks for the info. I see a pull request has just been submitted already:
https://github.com/tlswg/tls13-spec/pull/1116

On Tue, Dec 5, 2017 at 1:03 AM, Eric Rescorla <[email-masked]> wrote:

>> The obvious problem with randomly adding fake versions is you have to
>> have a way of ensuring they won't conflict with *real* future versions -
>> and whatever pattern you decide upon in order to do that, middleboxes will
>> use that pattern to filter out fake versions, and fail as soon as you
>> present one with a real future version (i.e. TLS 1.4).
>>
>>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7C
>>> Andrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531db
>>> dbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364697427
>>> 19473989&sdata=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS%
>>> 2BPW8%3D&reserved=0
>>>