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
directional
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 comp
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 SHOUL
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 expo
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)
3
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
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 are
