Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13

[Colm MacCárthaigh]

Thanks for the abundant generosity of patience, but I didn't mean that I
wanted to add a note to the text of the I-D, there's been enough delay and
I'm excited to see this progress. I just meant "add a note" in my e-mail
;-) Though I do like your terse note, it's right to the point.

On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla  wrote:

> Hi Colm,
>
> Thanks for your note. This seems straightforward to handle before IETF-LC.
>
> Maybe something like:
> "Note: many application layer protocols implicitly assume that replays are
> handled at lower levels. Tailure to observe these precautions may exposes
> your application to serious risks which are difficult to assess without a
> thorough top-to-bottom analysis of the application stack"?
>
> -Ekr
>
>
> On Sun, Jan 14, 2018 at 12:15 PM, Colm MacCárthaigh 
> wrote:
>
>>
>> Back during the previous last call, I felt really guilty about bringing
>> up the 0-RTT stuff so late. Even though it turned out that middle boxes
>> turned out to be a bigger problem to deal with anyway, I just want to say
>> that I'm really grateful for the 0-RTT related changes in the document and
>> for the time and effort that went into all that. I think those changes are
>> sufficient to make a TLS1.3 implementation that handles 0-RTT in a
>> forward-secret, secure and safe way. The changes represent a good
>> compromise between having a secure state and supporting vendors who want to
>> be a bit more loose because their application environment can tolerate it
>> and forward secrecy is not as valuable to their users. Thanks especially to
>> ekr for inventing the fixes, for stewarding the clarifications, and for
>> being awesome about it.
>>
>> At the same time, I just want to add a small note of caution to vendors;
>> if you're going to accept 0-RTT, trying to cut corners by tolerating
>> replays - even a little, is really likely to bite you! I've found even more
>> examples of application protocols and web protocols that implement
>> transactions. Also, if the secrecy of trillions and trillions of users web
>> requests are going to rest on how well session ticket encryption keys are
>> managed, protected, rotated and revoked, we really owe it to users to come
>> up with some collective guidance for vendors on how to do that well.
>>
>>
>> On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner  wrote:
>>
>>> All,
>>>
>>> This is the 3rd working group last call (WGLC) announcement for
>>> draft-ietf-tls-tls13; it will run through January 26th.  This time the WGLC
>>> is for version -23 (https://datatracker.ietf.org/
>>> doc/draft-ietf-tls-tls13/).  This WGLC is a targeted WGLC because it
>>> only address changes introduced since the 2nd WGLC on version -21, i.e.,
>>> changes introduced in versions -22 and -23.  Note that the editor has
>>> kindly included a change log in s1.2 and the datatracker can also produce
>>> diffs (https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-tls13-21
>>> rl2=draft-ietf-tls-tls13-23).  In general, we are considering all other
>>> material to have WG consensus, so only critical issues should be raised
>>> about that material at this time.
>>>
>>> Cheers,
>>>
>>> spt
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>>
>> --
>> Colm
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>


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

Re: [TLS] The future devices that will break TLS 1.4

[Martin Thomson]

The research that this is built on isn't especially new:
https://arxiv.org/abs/1607.01639

The interesting observation in that paper is that the results are
obtained only from the subset of malware that uses its own TLS
configuration.  Those that used the Windows stack in a default
configuration were removed from consideration.  Now, it's possible
that things have improved since that paper, but it suggests the
presence of a gap that we might exploit.  So I'm not so down on
GREASE.

On Sat, Jan 13, 2018 at 10:02 AM, Hanno Böck  wrote:
> Hi,
>
> This working group just went through a painful process of realizing
> that deploying a new TLS version on the Internet is a hard task due to
> broken devices. If you're not aware David Benjamin just gave a great
> talk summarizing the issues:
> https://www.youtube.com/watch?v=_mE_JmwFi1Y
>
> Today I found this article:
> https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encrypted_traffic/
>
> tl;dr Cisco now says they can identify malware in TLS traffic by
> carefully looking at it.
> (For context: devices from Cisco were responsible for many of the
> issues that made deploying TLS 1.3 hard, e.g. version intolerance on
> load balancers and recently by not correctly terminating TLS in a
> firewall.)
>
>
> I'll dare to have a look into the future and make this imho very
> plausible claim:
> Cisco won't be the only vendor selling such things. We will see more
> products that magically can identify "bad things" in TLS traffic by
> applying everything from AI to Blockchain.
> We will almost certainly see a whole new generation of devices doing
> weirdness with TLS and who will drop or manipulate packages that contain
> things they don't know (like... a version negotiation field with TLS
> 1.4 or a large post quantum key exchange message).
>
> The question I want to ask: What can we do *now* to stop this from
> happening when TLS 1.4 will be deployed? I have the feeling GREASE
> won't be enough...
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> ___
> 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] 3rd WGLC: draft-ietf-tls-tls13

[Eric Rescorla]

Hi Colm,

Thanks for your note. This seems straightforward to handle before IETF-LC.

Maybe something like:
"Note: many application layer protocols implicitly assume that replays are
handled at lower levels. Tailure to observe these precautions may exposes
your application to serious risks which are difficult to assess without a
thorough top-to-bottom analysis of the application stack"?

-Ekr


On Sun, Jan 14, 2018 at 12:15 PM, Colm MacCárthaigh 
wrote:

>
> Back during the previous last call, I felt really guilty about bringing up
> the 0-RTT stuff so late. Even though it turned out that middle boxes turned
> out to be a bigger problem to deal with anyway, I just want to say that I'm
> really grateful for the 0-RTT related changes in the document and for the
> time and effort that went into all that. I think those changes are
> sufficient to make a TLS1.3 implementation that handles 0-RTT in a
> forward-secret, secure and safe way. The changes represent a good
> compromise between having a secure state and supporting vendors who want to
> be a bit more loose because their application environment can tolerate it
> and forward secrecy is not as valuable to their users. Thanks especially to
> ekr for inventing the fixes, for stewarding the clarifications, and for
> being awesome about it.
>
> At the same time, I just want to add a small note of caution to vendors;
> if you're going to accept 0-RTT, trying to cut corners by tolerating
> replays - even a little, is really likely to bite you! I've found even more
> examples of application protocols and web protocols that implement
> transactions. Also, if the secrecy of trillions and trillions of users web
> requests are going to rest on how well session ticket encryption keys are
> managed, protected, rotated and revoked, we really owe it to users to come
> up with some collective guidance for vendors on how to do that well.
>
>
> On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner  wrote:
>
>> All,
>>
>> This is the 3rd working group last call (WGLC) announcement for
>> draft-ietf-tls-tls13; it will run through January 26th.  This time the WGLC
>> is for version -23 (https://datatracker.ietf.org/
>> doc/draft-ietf-tls-tls13/).  This WGLC is a targeted WGLC because it
>> only address changes introduced since the 2nd WGLC on version -21, i.e.,
>> changes introduced in versions -22 and -23.  Note that the editor has
>> kindly included a change log in s1.2 and the datatracker can also produce
>> diffs (https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-tls13-21
>> rl2=draft-ietf-tls-tls13-23).  In general, we are considering all other
>> material to have WG consensus, so only critical issues should be raised
>> about that material at this time.
>>
>> Cheers,
>>
>> spt
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
> --
> Colm
>
> ___
> 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] 3rd WGLC: draft-ietf-tls-tls13

[Colm MacCárthaigh]

Back during the previous last call, I felt really guilty about bringing up
the 0-RTT stuff so late. Even though it turned out that middle boxes turned
out to be a bigger problem to deal with anyway, I just want to say that I'm
really grateful for the 0-RTT related changes in the document and for the
time and effort that went into all that. I think those changes are
sufficient to make a TLS1.3 implementation that handles 0-RTT in a
forward-secret, secure and safe way. The changes represent a good
compromise between having a secure state and supporting vendors who want to
be a bit more loose because their application environment can tolerate it
and forward secrecy is not as valuable to their users. Thanks especially to
ekr for inventing the fixes, for stewarding the clarifications, and for
being awesome about it.

At the same time, I just want to add a small note of caution to vendors; if
you're going to accept 0-RTT, trying to cut corners by tolerating replays -
even a little, is really likely to bite you! I've found even more examples
of application protocols and web protocols that implement transactions.
Also, if the secrecy of trillions and trillions of users web requests are
going to rest on how well session ticket encryption keys are managed,
protected, rotated and revoked, we really owe it to users to come up with
some collective guidance for vendors on how to do that well.


On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner  wrote:

> All,
>
> This is the 3rd working group last call (WGLC) announcement for
> draft-ietf-tls-tls13; it will run through January 26th.  This time the WGLC
> is for version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).
> This WGLC is a targeted WGLC because it only address changes introduced
> since the 2nd WGLC on version -21, i.e., changes introduced in versions -22
> and -23.  Note that the editor has kindly included a change log in s1.2 and
> the datatracker can also produce diffs (https://www.ietf.org/rfcdiff?
> url1=draft-ietf-tls-tls13-21=draft-ietf-tls-tls13-23).  In general,
> we are considering all other material to have WG consensus, so only
> critical issues should be raised about that material at this time.
>
> Cheers,
>
> spt
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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

Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13

[Tony Arcieri]

Ship it

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

Re: [TLS] The future devices that will break TLS 1.4

[Tony Arcieri]

On Sat, Jan 13, 2018 at 12:02 AM, Hanno Böck  wrote:
>
> The question I want to ask: What can we do *now* to stop this from
> happening when TLS 1.4 will be deployed? I have the feeling GREASE
> won't be enough...


Sidebar: TLS 4 ;)

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