-
Notifications
You must be signed in to change notification settings - Fork 158
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
Using both External PSK and (EC)DH in TLS 1.3. #870
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1498,15 +1498,21 @@ If the server successfully selects parameters and does not require a | |
HelloRetryRequest, it indicates the selected parameters in the ServerHello as | ||
follows: | ||
|
||
- If PSK is being used, then the server will send a | ||
"pre_shared_key" extension indicating the selected key. | ||
- If PSK is not being used, then (EC)DHE and certificate-based | ||
authentication are always used. | ||
- When (EC)DHE is in use, the server will also provide a | ||
"key_share" extension. | ||
- When authenticating via a certificate (i.e., when a PSK is not | ||
in use), the server will send the Certificate ({{certificate}}) and | ||
CertificateVerify ({{certificate-verify}}) messages. | ||
- If PSK is not being used, then (EC)DHE and certificate-based authentication are always used, and the server will: | ||
|
||
-- provide a "key_share" extension; and | ||
|
||
-- send the Certificate (Section 4.4.1) and CertificateVerify (Section 4.4.2) messages. | ||
|
||
- If PSK (without DH or ECDH) is being used, then the server sends a "pre_shared_key" extension to indicate the selected key. | ||
|
||
- If PSK and (EC)DH are being used together, then the server will: | ||
|
||
-- send a "pre_shared_key" extension to indicate the selected key; | ||
|
||
-- provide a "key_share" extension; and | ||
|
||
-- send the Certificate (Section 4.4.1) and CertificateVerify (Section 4.4.2) messages. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In response to @kaduk, since github has eaten his response in a way that I can't respond... I think that this is a huge problem waiting to happen. Current implementations assume that using PSK means no certificate. We can't have ambiguity on this point or we won't get interoperability. If you are saying that if PSK implies that the choice of whether to send a certificate is up to the server, then we need to explicitly say that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with MT. The current draft is intended to prohibit the server sending a certificate with PSK mode. I'm happy to take PRs that consolidate that prohibition so that if/when we want to relax the requirement with some extension it's easy, but I think that the prohibition needs to remain in the draft. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Draft -18 already says this is possible at the bottom of page 17. This PR was intended to say how to do what the document says can be done. Page 17 says: PSKs can be used with (EC)DHE exchange in order to provide forward There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, PSK can be used with ECDHE. It cannot be used with server authentication via a signature. |
||
|
||
If the server is unable to negotiate a supported set of parameters | ||
(i.e., there is no overlap between the client and server parameters), | ||
|
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.
Github is doing different syntax highlighting for the toplevel bullet points, and maybe they have inconsistent whitespace for them.