You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.
Using a session ticket which has max_early_data = 16384, 6 bulks of early data messages were sent, with sizes of 4095, 4096, 4096, 4096, 4096, 4096 bytes. Only then EndOfEarlyData was sent.
It seems that after the 5th early message, the server will not accept any more early data, but it will accept the first 5. I.e., the first 5 calls to FFI_mitls_receive will return the first 5 early data messages. The 6th call to FFI_mitls_receive will return nothing. Overall , 20479 bytes were received as early data, which are 4095 bytes more than allowed by the ticket. I assume the desired behavior is accepting only the first 16384 bytes.
According to section 4.6.1 in the RFC (draft-21), max_early_data
A server receiving more than max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert.
However, no alert was emitted by the server upon receiving the 5th early data message.
On the client side, the early data messages were sent using FFI_mitls_send, which should have perhaps split the data into early data and regular app data.
To summarize: The client side behavior of FFI_mitls_send is probably wrong, and the server side behavior (accepting the early data) is potentially a violation of the security parameter max_early_data.
The text was updated successfully, but these errors were encountered:
Using a session ticket which has max_early_data = 16384, 6 bulks of early data messages were sent, with sizes of 4095, 4096, 4096, 4096, 4096, 4096 bytes. Only then EndOfEarlyData was sent.
It seems that after the 5th early message, the server will not accept any more early data, but it will accept the first 5. I.e., the first 5 calls to FFI_mitls_receive will return the first 5 early data messages. The 6th call to FFI_mitls_receive will return nothing. Overall , 20479 bytes were received as early data, which are 4095 bytes more than allowed by the ticket. I assume the desired behavior is accepting only the first 16384 bytes.
According to section 4.6.1 in the RFC (draft-21), max_early_data
To summarize: The client side behavior of FFI_mitls_send is probably wrong, and the server side behavior (accepting the early data) is potentially a violation of the security parameter max_early_data.
The text was updated successfully, but these errors were encountered: