On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson
wrote:
> On 21 October 2015 at 15:52, Eric Rescorla wrote:
> > I don't think this will make the implementation that hard :)
>
> Yeah, you have to actually pay attention to the early_data extension.
> That might not be a bad thing in the end.
>
Yes
On 21 October 2015 at 15:52, Eric Rescorla wrote:
> I don't think this will make the implementation that hard :)
Yeah, you have to actually pay attention to the early_data extension.
That might not be a bad thing in the end.
___
TLS mailing list
TLS@ie
On Wed, Oct 21, 2015 at 3:52 PM, Martin Thomson
wrote:
> I'm not sure that I follow. Are all the records in 0RTT going to use
> a content of handshake, or just the
> Certificate/CertificateVerify/Finished? I assume that you meant just
> the handshake messages, in which case yes, this is OK.
Y
I'm not sure that I follow. Are all the records in 0RTT going to use
a content of handshake, or just the
Certificate/CertificateVerify/Finished? I assume that you meant just
the handshake messages, in which case yes, this is OK. It does make
identification of what goes into the handshake hash ma
https://github.com/tlswg/tls13-spec/issues/311
I initially added this to make it easier to determine the end of the 0-RTT
handshake if the server had forgotten the key, but with content type
encryption
this is no longer relevant. I propose we remove this and simply use
Handshake here, allowing the