On Thu, May 19, 2016 at 02:38:35PM -0700, Eric Rescorla wrote:
> On Thu, May 19, 2016 at 12:35 PM, Ilari Liusvaara
> wrote:
> >
> > In very quick'n'dirty security analysis the other thing I noticed was
> > that if server handshake needs something to be nonce w.r.t. "SS", (e.g.
> > happens in GDHE-
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>
> > wrote:
> >
> > > On Thu, Ma
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 wrote:
>> Nevertheless, som
On Thu, May 19, 2016 at 04:37:30PM -0400, Martin Thomson wrote:
> On 19 May 2016 at 16:01, Viktor Dukhovni wrote:
> > Nevertheless, some clients may want to attempt to gain fine-grained
> > protection against correlating back to back or parallel resumption
> > requests. For this they'd have to e
On 19 May 2016 at 16:01, Viktor Dukhovni wrote:
> Nevertheless, some clients may want to attempt to gain fine-grained
> protection against correlating back to back or parallel resumption
> requests. For this they'd have to ensure that all session tickets
> are single use, and either perform new h
On Thu, May 19, 2016 at 03:45:26PM -0400, Kyle Rose wrote:
> > This is only relevant to a particular type of client, and should
> > not be default protocol behaviour.
>
> I suspect the root of arguments for/against this proposal are
> philosophical more than technical. I disagree with your conten
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 for a quick burst of connec
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 wrote:
> Reviving this thread, I also think i
On Thu, May 19, 2016 at 12:13:45PM -0700, Eric Rescorla wrote:
> On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara
> wrote:
>
> > On Thu, May 19, 2016 at 10:41:16AM -0700, Eric Rescorla wrote:
> >
> > Just one thing to be careful of: If one has off-handshake counter-
> > keys[1] (like the now-rem
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. Having this logic is rathe
On Thu, May 19, 2016 at 12:11 PM, Ilari Liusvaara
wrote:
> 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 cou
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 reuse sessions when their IP
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 Add-
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, an
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 reuse sessions when their IP address changes
I don't think this is sufficient. Reusing session ticket
https://github.com/tlswg/tls13-spec/pull/461
It could probably use some cleaning up ("PSK/session ticket"). Do we
also want a sentence explaining the issue?
Kyle
On Thu, May 19, 2016 at 2:31 PM, Eric Rescorla wrote:
> Yes, I think this would be good text. PR wanted :)
>
> -Ekr
>
> On Thu, May 1
Yes, I think this would be good text. PR wanted :)
-Ekr
On Thu, May 19, 2016 at 11:19 AM, Kyle Rose wrote:
> 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 languag
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 a
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 post-handsha
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.
htt
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 announcemen
Stephen Farrell :
> In support of Kathleen's comment and based on the shepherd's write-up,
> > why is this experimental and what is
> > the experiment?
>
> There's no good answer, sorry. I knew folks would ask, so I asked
> the WG and it seems to me to be a case that nobody cares really so
> the
22 matches
Mail list logo
