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.

Sign up for GitHub

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

Jump to bottom

Automatic applicability of new TLS cipher suites #2742

Closed
ekr opened this issue May 22, 2019 · 2 comments · Fixed by #2743
Closed

Automatic applicability of new TLS cipher suites #2742

ekr opened this issue May 22, 2019 · 2 comments · Fixed by #2743
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@ekr
Copy link
Collaborator

ekr commented May 22, 2019

Suppose that we had a future TLS cipher suite such as AES_OCB_SHA256. Would that work with QUIC without a new QUIC draft? The AEAD part is already clearly defined and given that AES-OCB uses AES, the same HP mechanism as we currently use with GCM can be used here.
From my perspective, the desirable property is that if we add new TLS cipher suites with analogous cipher cores (block cipher and/or nonce-based stream cipher) to the existing spec, then no new QUIC document should be required.

An alternative design would be to just require a "QUIC applicability" paragraph in new TLS cipher suites analogous to the DTLS-OK IANA flag.

(see also #2019).
martinthomson added a commit that referenced this issue May 22, 2019
@martinthomson
Better articulate principles for ciphersuites
25104cf 
For input to discussion on the related issues.  This says that we don't
do CCM_8 and makes it clear that you don't reject an attempt to use a
ciphersuite you don't understand.

Closes #2742, #2682, #2581.
@martinthomson martinthomson mentioned this issue May 22, 2019
Merged
@martinthomson martinthomson added -tls editorial An issue that does not affect the design of the protocol; does not require consensus. labels May 22, 2019
@mikkelfj
Copy link
Contributor

How about header protection which depends on being defined for the negotiated AEAD?

@ekr
Copy link
Collaborator Author

ekr commented May 22, 2019

That's what paragraph 2 above is about.

@mnot mnot added this to Editorial Issues in Late Stage Processing May 22, 2019
Late Stage Processing automation moved this from Editorial Issues to Text Incorporated May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Better articulate principles for ciphersuites quicwg/base-drafts
3 participants
@martinthomson @mikkelfj @ekr