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

crypto/tls: add DecryptSessionTicket to Config #17432

Closed
FiloSottile opened this issue Oct 13, 2016 · 4 comments
Closed

crypto/tls: add DecryptSessionTicket to Config #17432

FiloSottile opened this issue Oct 13, 2016 · 4 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@FiloSottile
Copy link
Contributor

FiloSottile commented Oct 13, 2016

There are already multiple ways to set session tickets but they all require key material. At Cloudflare we want to use a remote Keyless-style system.

I suggest the following interface.

type SessionTicketWrapper interface {
    // Wrap returns a session ticket value that can be later passed to Unwrap
    // to recover the content, usually by encrypting it. The ticket will be sent
    // to the client to be stored, and will be sent back in plaintext, so it can
    // be read and modified by an attacker.
    Wrap(cs *ConnectionState, content []byte) (ticket []byte, err error)

    // Unwrap returns a session ticket contents. The ticket can't be assumed
    // to having been generated by Wrap. 
    // If unable to unwrap the ticket, the connection will proceed with a
    // complete handshake.
    Unwrap(chi *ClientHelloInfo, ticket []byte) (content []byte, success bool)
}

crypto/tls would be responsible of serializing and deserializing the session state.

This works cleanly with TLS 1.3 PSK, too, but I wonder if we will need more stuff in the interface to allow it to do replay protection, too.

/cc @Bren2010 @agl

@FiloSottile
Copy link
Contributor Author

I wonder if we will need more stuff in the interface to allow it to do replay protection, too.

All the fields in here https://tlswg.github.io/tls13-spec/#rfc.appendix.A.3.4 can be picked by crypto/tls and embedded in the content before calling Wrap, at the expense of configurability, although max_early_data_size is pretty application-specific (but it might just go in Config). The obfuscated_ticket_age https://tlswg.github.io/tls13-spec/#rfc.section.4.2.7.2 can be acted upon by crypto/tls after the Unwrap call, with some sane buffer (possibly in Config).

Ticket reuse is allowed anyway, so it's not Unwrap's job to detect replays. So yeah, this interface makes sense for 1.3 IMHO.

@Bren2010
Copy link

What is the value in having ClientHelloInfo and ConnectionState inputs? Without them, this could just be a crypto/cipher.AEAD.

@quentinmit quentinmit added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Oct 17, 2016
@quentinmit quentinmit added this to the Go1.9 milestone Oct 17, 2016
@quentinmit
Copy link
Contributor

This is too late for a feature addition to 1.8.

@FiloSottile
Copy link
Contributor Author

Superseded by the wider #19199

@golang golang locked and limited conversation to collaborators Feb 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

4 participants