Hi Eric,
Looks like Watson already gave a definitive reply on my behalf. Thanks
Watson, for being such an effective and proactive amanuensis.
For the avoidance of doubt: what Karthik suggests would avoid the problem
we've been discussing, so I'd be quite happy with it.
Cheers
Kenny
On 20/02/2
On Feb 20, 2016 12:31 PM, "Eric Rescorla" wrote:
>
> Kenny,
>
> Would you have a problem with doing as Karthik suggests and generating
> separate traffic and handshake keys but at the same time?
This solves all the problems completely, as the traffic key is fresh.
>
> -Ekr
>
>
> On Sat, Feb 20,
Kenny,
Would you have a problem with doing as Karthik suggests and generating
separate traffic and handshake keys but at the same time?
-Ekr
On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny wrote:
> Hi
>
> My 2c below...
>
> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
> wrote:
>
Hi
My 2c below...
On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
wrote:
>
>
>Besides, in our analysis of the handshake, we get precisely the same
>“fresh, never-used secret” property you are advocating, with or
> without the simplification, each time the handshake provides keys to the
>
We have rather different views of the protocol. You see the record layer as a
sample application outside TLS, whereas our model (tied to our implementation)
composes the handshake and the record-layer subprotocols to get security at the
TLS API. You also reason about “the output session key”, wh
On Fri, Feb 19, 2016 at 05:52:44PM -0800, Eric Rescorla wrote:
> I don't believe that this is going to work very well, since it is a fairly
> large burden for referring
> servers to refresh their state.
Then there is the question of authenticating the state.
-Ilari
