Re: [TLS] Key Schedule (PRs #453, #454).

Sorry, I think you lost me there. Can you rephrase? -Ekr On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara wrote: > On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote: > > On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > >

Re: [TLS] Resumption ticket/PSK

I've modified the branch to use your wording. As Viktor said, it doesn't address his objection, but it's still a more precise starting point for further discussion. Kyle On Thu, May 19, 2016 at 4:37 PM, Martin Thomson wrote: > On 19 May 2016 at 16:01, Viktor Dukhovni

Re: [TLS] Resumption ticket/PSK

On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni wrote: > It is good enough. Clients that want strong protection against > tracking by session ids can disable session caching entirely, or > set an idle timeout of ~5 seconds, Ensuring that session re-use > happens only

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

Thanks for doing the text. Russ On May 19, 2016, at 3:22 PM, David Benjamin wrote: > If the WG agrees with this change, I've put together a PR here: > https://github.com/tlswg/tls13-spec/pull/462 > > On Tue, May 17, 2016 at 4:14 PM David Benjamin

Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets

If the WG agrees with this change, I've put together a PR here: https://github.com/tlswg/tls13-spec/pull/462 On Tue, May 17, 2016 at 4:14 PM David Benjamin wrote: > Reviving this thread, I also think it would also be a good idea if 1.3 did > not stripping zeros from Z.

Re: [TLS] Resumption ticket/PSK

On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote: > On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni > wrote: > > > I think this is much too complicated. Simpler solution is for > > clients (browsers and the like for which tracking is an issue) to > > not

Re: [TLS] Key Schedule (PRs #453, #454).

On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote: > > An additional nice point about this design is that it easily > accomodates additional keys. For instance, if we had some post-quantum > key exchange method, we could easily add its key in the final > Add-Secret or add an extra

Re: [TLS] Resumption ticket/PSK

On Thu, May 19, 2016 at 11:31:53AM -0700, Eric Rescorla wrote: > Yes, I think this would be good text. PR wanted :) I think this is much too complicated. Simpler solution is for clients (browsers and the like for which tracking is an issue) to not reuse sessions when their IP address changes,

[TLS] Resumption ticket/PSK

Regarding the ability for passive observers' tracking of clients across connections (and potentially across IPs) via a session ticket used more than once, should there be any language around recommended practice here, especially for clients? An appropriately-configured server can help the client

[TLS] Key Schedule (PRs #453, #454).

PR: https://github.com/tlswg/tls13-spec/pull/454 I have uploaded a PR [technically two PRs, but one builds on the other, so easier to just read the composition] which resolves two out of the three significant remaining crypto issues (the remaining one is the long-running discussion of

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

Hi, > The first step of our attack involves attacker controlled content. So yes > (phishing, unauthenticated HTTP, selective company DPI etc.). In our example > we use a local proxy to carry out the attack. I hope I can post a full > version of the actual paper and PoC to this thread soon.

[TLS] draft-ietf-tls-falsestart rfc editor note done

Dear IESG secretariat, (bcc'd), As discussed on the telechat I've updated the intended status in the tracker, added an RFC editor note asking them to change the header and cut'n'pasted the writeup into it's proper place. So I think this one is ready for you to send the usual approval