On Tue, Jul 12, 2016 at 8:34 AM, Bill Cox <waywardg...@google.com> wrote:
> IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values
> do not change.
>
In TLS 1.2, the EKM == MS but the exporter includes the randoms:
PRF(SecurityParameters.master_secret, label,
SecurityParameters.client_random +
SecurityParameters.server_random +
context_value_length + context_value
)[length]
This means that if you resume, you should get different exported values.
-Ekr
I think most applications currently using EKM will break if the EKM values
> change after a PSK resume.
>
> However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets
> by 32 bytes, and complicate the state machine. I think this could
> partially be addressed by enhancing the custom extension APIs found in
> popular TLS libraries to enable custom extensions to specify state that
> needs to be remembered on a resume. That, in combination with requiring
> extensions to be sent and processed in order of extension number, could
> enable a lot of this complexity to be taken out of the main TLS code, and
> only connections that actually need such extensions would see the increase
> in ticket size.
>
> Could something like this could work well for channel binding?
>
> Bill
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
