Hello all,
I have a confusion about this specification, and I did a search of the mail
archives, it seems not mentioned before :
rfc5246
7.4.1.3. Server Hello
cipher_suite
For resumed sessions, this field is the value from the state of the session
being resumed.
There is not a 'MUST' to strict
These are good questions.
More generally, when do we care about distinguishing handshake data from
application data?
I just posted another email about using plaintext end_of_early_data alerts to
avoid trial decryption, and similar questions come into play there.
Best,
Karthik
> On 29 Mar 201
TLS 1.3 0-RTT introduces an “optimistic” mode where the client
encrypts data that the server can then accept or reject.
In the case when the server rejects 0-RTT, the server is left in a somewhat
ugly state where it will receive, in sequence:
(a) encrypted 0-RTT handshake data (that it needs to t
On 31 March 2016 at 15:52, Wan-Teh Chang wrote:
> The info is these two tables is exactly the same for DHE-based 0-RTT
> and PSK-based 0-RTT.
You are right. I remain concerned about the other factors.
___
TLS mailing list
TLS@ietf.org
https://www.iet
