On Fri, Apr 22, 2016 at 6:49 AM, Ilari Liusvaara
wrote:
> > The list will likely grow over time much like it has in the past. My
> guess
> > is that most clients will simply reuse the existing session cache from
> TLS
> > 1.2. All state will be remembered.
>
> If I was to implement this, I woul
On Fri, Apr 22, 2016 at 06:13:25AM -0700, Bill Cox wrote:
> On Fri, Apr 22, 2016 at 5:19 AM, Ilari Liusvaara
> wrote:
>
> > Looking at the extension list, I only see the following at coupling
> > level for PSK 0-RTT data:
> >
> > - RMS (which acts as PSK key).
> > - Ciphersuites allowed.
> > - AL
On Fri, Apr 22, 2016 at 08:01:11AM +1000, Martin Thomson wrote:
>
> We agreed at the meeting that 0-RTT data would not explicitly signal
> parameters, so peers would have to remember things from the previous
> session. That means that you will need to bind everything you need
> into the stored st
On 22 April 2016 at 00:40, Ilari Liusvaara wrote:
>
> My understanding is that TLS 1.3 replaces the entiere resumption with
> what is essentially dynamic PSK provosioning. So state to be remembered
> is to be kept at minimum.
This is a point that is not clear, but here's my view on it:
Unlike p
ailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Thursday, April 21, 2016 10:55 AM
To: Bill Cox
Cc: tls@ietf.org
Subject: Re: [TLS] Extensions and state during a resume
On Thu, Apr 21, 2016 at 09:32:30AM -0700, Bill Cox wrote:
> I'm just going through an example which is relate
On Thu, Apr 21, 2016 at 09:32:30AM -0700, Bill Cox wrote:
> I'm just going through an example which is related to what I work on, which
> currently is token binding. Client certs are very similar.
>
> If client certs (or token binding) were supported by the server, as well as
> replay protection,
On Thu, Apr 21, 2016 at 08:05:53AM -0700, Bill Cox wrote:
> On Thu, Apr 21, 2016 at 7:40 AM, Ilari Liusvaara
> wrote:
>
> > My understanding is that TLS 1.3 replaces the entiere resumption with
> > what is essentially dynamic PSK provosioning. So state to be remembered
> > is to be kept at minimu
On Thu, Apr 21, 2016 at 06:12:40AM -0700, Bill Cox wrote:
> In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we
> assume the full state of the prior connection is remembered (either in the
> ticket, or in session caches)? Alternatively, do we let some extensions
> require re
In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we
assume the full state of the prior connection is remembered (either in the
ticket, or in session caches)? Alternatively, do we let some extensions
require remembered state while other extensions require renegotiation?
This
