Closed Bug 1642871 Opened 4 months ago Closed 4 months ago

Enable SSL_SendSessionTicket after resumption

Categories

(NSS :: Libraries, defect)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mt, Assigned: mt)

References

Details

Attachments

(1 file)

Bug 1603042 added a check to SSLExp_SendSessionTicket so that we wouldn't try to send a ticket when the connection used a PSK. However, that seems to be a little over-zealous. It checks the status of the key exchange used for the connection (ss->ssl3.hs.kea_def->authKeyType, which says PSK) rather than the underlying authentication (ss->sec.authType, which says ECDSA or whatever the original non-resumed handshake had).

This prevents sending of extra session tickets after resumption.

The same check is used to disable the sending of a CertificateRequest. THAT is a good check.

We might need some new tests to cover these cases very carefully.

I was wrong about the CertificateRequest piece. The answer is very much unclear.

The code currently interprets the use of resumption as a reason not to permit a CertificateRequest, but it's not clear that this is unsupported.

The spec seems to be clear about external PSKs:

Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.

However, it also seems to contradict this with a more general statement:

Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6).

That reads like a contradiction to me, and I can't resolve it.

I believe that the intent of the first is to exclude the combination of an external PSK and certificate during the handshake. This text was added specifically to allow for RFC 8773 to be published.

The second is consistent with this interpretation regarding the combination during the handshake. Where it is unclear is with respect to post-handshake authentication. It basically allows post-handshake authentication, even if you have an external PSK. That's consistent with what we learned in analysis of the protocol: if you let the server ask the client for a certificate without also offering its own certificate then the attack discovered by Sam Smith et. al. applies.

But this leaves the functioning of post-handshake authentication ambiguous as it relates to the use of resumption PSKs. I think that the first quote supports the view that you can't use it with an external PSK. But the second could be read to allow it more generally. It might be time to take this to the TLS WG.

The first part of this is fairly simple: we accidentally disabled sending of
session tickets after resumption.

The second part is much less obvious, because the spec is unclear. This change
takes the interpretation that it is OK to use post-handshake authentication if
the handshake is resumed, but not OK if the handshake is based on a PSK. (This
is based on a first-principles understanding of resumption being a continuation
of a certificate-based connection rather than a reading of the spec, see the bug
for why the spec appears to be unhelpful on this point.)

This still prohibits the use of post-handshake authentication if an external PSK
was used, but that is more an abundance of caution than anything principled.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 3.54
You need to log in before you can comment on or make changes to this bug.