Hi folks,
TL;DR.
I propose that we should not change keys between the handshake
and application traffic keys.
DETAILS
As we try to finalize the drafts and implementations are starting to
emerge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting
Hi, perhaps I'm missing various somethings, but I'm having trouble figuring
out _how_ the Static Secret (SS) and Ephemeral Secret (ES) are actually
derived...
Given this chunk of -tls13-11..
###
7.1. Key Schedule
The TLS handshake establishes secret keying material which is then
used
A few points to some of the comments:
1) Thread devices are not typically smartphones and PCs. They are class 1
constrained devices according to RFC7228, i.e. thermostats and light
switches etc.
2) Device certs. and short fingerprints are indeed used in similar systems
to Thread (e.g. ZigBee IP)
On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote:
> Hi,
>
> RFC5705 section 4 "Exporter Definition" [1] states..
>
>The exporter takes three input values:
>
>o a disambiguating label string,
>
>o a per-association context value provided by the application using
> the
On 02/17/2016 01:03 PM, =JeffH wrote:
> In -tls13-11 section 7.2 [1] there is this..
>
> 7.2. Updating Traffic Keys and IVs
>
> Once the handshake is complete, ...
>
> [...]
>
> Once traffic_secret_N+1 and its associated traffic keys have been
> computed, implementations
Hi,
RFC5705 section 4 "Exporter Definition" [1] states..
The exporter takes three input values:
o a disambiguating label string,
o a per-association context value provided by the application using
the exporter, and
o a length value.
If no context is provided, it then
In -tls13-11 section 7.2 [1] there is this..
7.2. Updating Traffic Keys and IVs
Once the handshake is complete, ...
[...]
Once traffic_secret_N+1 and its associated traffic keys have been
computed, implementations SHOULD delete traffic_secret_N. Once the
