Re: [TLS] rfc 6520 TLS heartbeat feature

[Salz, Rich]

➢ In other words, is it worth spending time?

You might find it worthwhile to look at Peter’s “LTS for TLS” draft.

 Nobody cares about heartbeats and for this issue, that’s probably good enough.

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

Re: [TLS] Exported Authenticators proposed change to incorporate authenticator request

[Nick Sullivan]

This is an uncontroversial change and nobody has responded from the list,
so unless someone has any objections I'm going to incorporate this change
(along with a change to address Benjamin Kaduk's comments) and publish a
new draft next week.

Nick

On Thu, Nov 23, 2017 at 1:18 PM Nick Sullivan 
wrote:

> Martin Thomson raised an issue Github (Issue #5
> )
> suggesting that we modify the exported authenticators draft to include the
> ability to incorporate a CertificateRequest into an authenticator. I have
> put together a set of changes to the draft to incorporate this suggestion:
> https://github.com/tlswg/tls-exported-authenticator/pull/9
>
> The advantage of this change is that it provides a more explicit binding
> between a request for an authenticator (which includes TLS extensions) and
> the authenticator itself. This change also significantly simplifies the HTTP/2
> Additional Certificates draft
> 
> that depends on exported authenticators. I presented this change at IETF
> 100 and there were no objections.
>
> Comments welcome,
> Nick
>
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Reference for justification of middlebox compat mode

[Peter Wu]

Hi,

The current draft makes the following claim:

Field measurements have found that a significant number of middleboxes
misbehave when a TLS client/server pair negotiates TLS 1.3.

Would it be possible to add a reference for this claim for the benefit
of future readers? One possible (terse) reference I could find is
https://www.ietf.org/mail-archive/web/tls/current/msg24517.html
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

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

Re: [TLS] Reference for justification of middlebox compat mode

[Eric Rescorla]

I would cite:

https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/
(the slides, which include David's data)
https://www.ietf.org/mail-archive/web/tls/current/msg25091.html (my email
from yesterday)

-Ekr




On Wed, Dec 6, 2017 at 3:35 PM, Peter Wu  wrote:

> Hi,
>
> The current draft makes the following claim:
>
> Field measurements have found that a significant number of middleboxes
> misbehave when a TLS client/server pair negotiates TLS 1.3.
>
> Would it be possible to add a reference for this claim for the benefit
> of future readers? One possible (terse) reference I could find is
> https://www.ietf.org/mail-archive/web/tls/current/msg24517.html
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
> ___
> 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] PR#1091: Changes to provide middlebox robustness

[Alex C]

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

>
>
> On Mon, Dec 4, 2017 at 1:59 AM, Alex C  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).
>>
>> 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)
>>
>>
> Yes, you can send a a PR at:
> https://github.com/tlswg/tls13-spec/
>
> -Ekr
>
>
>> On Sat, Nov 25, 2017 at 8:21 AM, Yuhong Bao 
>> wrote:
>>
>>> That only applies to the ClientHello.
>>>
>>> 
>>> From: Andrei Popov 
>>> Sent: Wednesday, November 22, 2017 11:22:23 AM
>>> To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
>>> Cc: tls@ietf.org; 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:tls-boun...@ietf.org] On Behalf Of Yuhong Bao
>>> Sent: Wednesday, November 22, 2017 11:04 AM
>>> To: Peter Saint-Andre ; Eric Rescorla 
>>> Cc: tls@ietf.org; Tapio Sokura 
>>> 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 
>>> Sent: Wednesday, November 22, 2017 11:02:39 AM
>>> To: Yuhong Bao; Eric Rescorla
>>> Cc: tls@ietf.org; 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
>>> TLS@ietf.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%
>>> 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
>>>
>>> ___
>>> 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