-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tls13 add early data indication #6486
Tls13 add early data indication #6486
Conversation
9233497
to
039504b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some early feedback. At that point no need to evolve the PR by adding new commits. Please just rewrite a clean commit history.
a8eeda0
to
b29afc8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some additional comments. I haven't look at the changes in ssl-opt.sh yet.
b29afc8
to
fb91dc8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should provide a parameter to input early data. Also some improvements.
45ade6f
to
f99b5a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some improvement and reply.
02ffe41
to
d2bf636
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few final minor issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor improvement
Define the ALLOW_PSK_RESUMPTION and ALLOW_PSK_EPHEMERAL_RESUMPTION to the key exchange mode EXCHANGE_MODE_PSK and EXCHANGE_MODE_PSK_EPHEMERAL to facilate later check. Since they are 1( 1u<<0 ) and 4( 1u<<2 ), so define ALLOW_EARLY_DATA to 8( 1u<<3 ). Signed-off-by: Xiaokang Qian <[email protected]>
Signed-off-by: Xiaokang Qian <[email protected]>
Signed-off-by: Xiaokang Qian <[email protected]>
802e2c8
to
e7bab00
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The code is based PR Mbed-TLS#6486. This commit might be adapted after PR Mbed-TLS#6486 merged. Signed-off-by: Pengyu Lv <[email protected]>
The code is based PR Mbed-TLS#6486. This commit might be adapted after PR Mbed-TLS#6486 merged. Signed-off-by: Pengyu Lv <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some comments about the tests. Otherwise, this looks good to me.
tests/opt-testcases/tls13-misc.sh
Outdated
MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_PSK_ENABLED | ||
run_test "TLS 1.3 m->G: EarlyData: basic check, good" \ | ||
"$G_NEXT_SRV -d 10 --priority=NORMAL:-VERS-ALL:+VERS-TLS1.3:+CIPHER-ALL:+ECDHE-PSK:+PSK --earlydata --disable-client-cert" \ | ||
"$P_CLI debug_level=4 force_version=tls13 early_data=1 reco_mode=1 reconnect=1 reco_delay=2" \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We try usually to force the TLS 1.3 version only on the server side thus like in the following test. That way when both TLS 1.2 and TLS 1.3 are enabled in the build the "hybrid" test is run and when only TLS 1.3 is enabled the test corresponding to TLS 1.3 being forced on the client side is run. Thus, I think we should just remove this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just remember in kex exchange mode tests, we remove the force_version=tls13 in client side. To keep aligned, I prefer to remove this case. How about your opinion? @yuhaoth
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this PR, it is okay to remove it for me.
It should be added in Write APP data
https://datatracker.ietf.org/doc/html/rfc8446#appendix-A.2 shows early data can be sent after ClientHello. It is Okay for TLS1.3 only. But for hybrid mode, it might cause problem. That's why suggest add hybrid tests.
And I do not think we should postpone write app data
like prototype
, it does not match RFC. This point has been raised in GnuTLS https://gitlab.com/gnutls/gnutls/-/issues/1146.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this PR, it is okay to remove it for me. It should be added in
Write APP data
So I will remove the test case with -force_version=tls13, and only leave the test case which you said "hibrid case" as basic case.
https://datatracker.ietf.org/doc/html/rfc8446#appendix-A.2 shows early data can be sent after ClientHello. It is Okay for TLS1.3 only. But for hybrid mode, it might cause problem. That's why suggest add hybrid tests.
We will leave the "hibrid case" there. Can you eleborate the problems?
And I do not think we should postpone
write app data
likeprototype
, it does not match RFC. This point has been raised in GnuTLS https://gitlab.com/gnutls/gnutls/-/issues/1146.
Seems it's related with wrte early data, can we leave the comment to this PR #6542
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I will remove the test case with -force_version=tls13, and only leave the test case which you said "hibrid case" as basic case.
Okay.
Seems it's related with wrte early data, can we leave the comment to this PR #6542
Sure.
We will leave the "hibrid case". Can you eleborate the problems?
From RFC 8446, we should send early data after ClientHello immediately. So we must switch outbound traffic after ClientHello ASAP.
If switch in CLIENT_HELLO and send early data, it match RFC. But if the server select TLS 1.2, I am not sure what will happen.
To avoid the issue, I think we should postpone the traffic switch, just after TLS 1.3 is selected at this moment. And in ClientHello, we should only switch traffic if it is configured as tls1.3 only.
For the test side, we should have tls1.3 only
and hybrid mode test to cover the cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From RFC 8446, we should send early data after ClientHello immediately. So we must switch outbound traffic after ClientHello ASAP.
If switch in CLIENT_HELLO and send early data, it match RFC. But if the server select TLS 1.2, I am not sure what will happen.
To avoid the issue, I think we should postpone the traffic switch, just after TLS 1.3 is selected at this moment. And in ClientHello, we should only switch traffic if it is configured as tls1.3 only.
For the test side, we should have
tls1.3 only
and hybrid mode test to cover the cases.
Seems it's one issue we should trade off when and in which case to change transform key.
Currently we only support session tikets psk, which means we only send out early data in resumption with tickets, maybe weI can make use of the tls_version in seriealized session to detect whether we only send out tls13 version, and then server will only have one tls13 choice. I am not sure whether the design work or not, maybe we can solve it in some ways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that's a key point. A TLS 1.3 handshake proposing early data can only be done with a PSK (external or obtained through a ticket) which is TLS 1.3 specific. Thus in that case we are not going to propose TLS 1.2 to the server: "TLS 1.3 only ClientHello".
Signed-off-by: Xiaokang Qian <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, @yuhaoth please have another look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It seems you selected "Request changes" instead of "Approve". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The code is based PR Mbed-TLS#6486. This commit might be adapted after PR Mbed-TLS#6486 merged. Signed-off-by: Pengyu Lv <[email protected]>
Part of adding early data support in TLS 1.3. No need for a change log.