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

TLS-31: Minor editorial issues #4204

Closed
gloinul opened this issue Oct 14, 2020 · 2 comments · Fixed by #4205
Closed

TLS-31: Minor editorial issues #4204

gloinul opened this issue Oct 14, 2020 · 2 comments · Fixed by #4205
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus. ietf-lc An issue that was raised during IETF Last Call.

Comments

@gloinul
Copy link
Contributor

gloinul commented Oct 14, 2020

Here are some minor editorial issues:

  1. Section 2.1: "TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged." I think "observed" as used here is the wrong word. Because the encrypted form of the clear-text message will be possible to observe. Please reformulate to give actual security properties.
  2. Section 2.1: "A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action." Please do not use RFC2119 words "MUST NOT" in overview. I understand the need for emphasis on this. However, I assume this is actually specified normatively elsewhere. So simply using other words to provide the emphasis and possibly a reference to the section defining this normatively.
  3. Section 5.2: "Note: The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero-length Source Connection ID field." To my understanding the DCID is not arbitrary length, it is of any octet length between 0 and 160 bits. Does the Initial processing function need to deal with non QUIC version-1 long header packets?
@larseggert larseggert added -tls ietf-lc An issue that was raised during IETF Last Call. labels Oct 14, 2020
@larseggert larseggert added this to Triage in Late Stage Processing via automation Oct 14, 2020
@larseggert
Copy link
Member

Based on #4205, labeling this as "editorial"

@larseggert larseggert added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Oct 15, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Oct 15, 2020
@gloinul
Copy link
Contributor Author

gloinul commented Oct 15, 2020

I think the PR resolves my issues nicely.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-tls editorial An issue that does not affect the design of the protocol; does not require consensus. ietf-lc An issue that was raised during IETF Last Call.
Projects
Late Stage Processing
  
Issue Handled
Development

Successfully merging a pull request may close this issue.

2 participants