Skip to content
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

Closed
wants to merge 2 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 15 additions & 9 deletions draft-ietf-tls-tls13.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Copy link
Contributor

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.


-- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

Choose a reason for hiding this comment

The 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
secrecy in combination with shared keys, or can be used alone, at the
cost of losing forward secrecy.

Copy link
Contributor

Choose a reason for hiding this comment

The 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),
Expand Down