Client-Cert HTTP Header: call out resumption risks in security considerations

[enygren]

It would also be good to add some notes to Security Considerations on the risks associated with resumption, ie for implementations that do try and use client cert information following a resumed session. While there's mention here in 3.3. TLS Session Resumption, the risks are very non-obvious and subtle. Especially if there's not an RFC that describes how to convey client cert information across session resumption safely (covering TLS 1.2 and 1.3) it seems like much stronger ("should not" / "must not") guidance may be applicable. Some risks might include:

• Anyone with access to an STEK can also create a session claiming to be authenticated by any client cert and chain they want. This is unavoidable, but may not be an obvious risks.
• Client cert and trust chain information must be fully protected and bound cryptographically into the session ticket. Are there subtle exposures in TLS 1.2 as well here?
• ... this area may be worth further analysis/guidance from TLS experts

[enygren]

See #1992 for discussion leading to the current text.

[bc-pi]

I am nowhere near competent enough in TLS or implementations thereof to write such security considerations so am going to need a lot of help. By which I mean a PR or proposed text.

[davidben]

These seem to be general TLS concerns, and not specific to this header, no?

Client cert and trust chain information must be fully protected and bound cryptographically into the session ticket. Are there subtle exposures in TLS 1.2 as well here?

That's not quite right. That is a valid implementation strategy, but there are others, particularly if you want to avoid ballooning the ticket size. See #1992 (comment)

[bc-pi]

Thinking about this a bit more and, to David's point, aren't these concerns applicable to resumption w/ client certs in TLS in general? Any discussion in this draft should probably be couched in that context. Or refer to discussion elsewhere.

[b---c]

Draft is in the RFC Editor queue https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/ so past the window for changes.