Draft: draft-ietf-quic-tls

Commentary: These are all small , but neat improvements inspired by the feedback in . 
 Here are some minor editorial issues : 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 can not 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.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 . 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 ? 
 Based on , labeling this as " editorial " 
 I think the PR resolves my issues nicely . 
 I liked that we dropped the MUST NOT , it 's already somewhere else . I also like that we point back to quic - trans for the dcid
Paragraph (version A):
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.
Paragraph (version B):
TLS provides two endpoints with a way to establish a means of
communication over an untrusted medium (that is, the Internet).  TLS
enables authentication of peers and provides confidentiality and
integrity protection for messages that endpoints exchange.
Paragraph (version A):
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.
Paragraph (version B):
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 0-RTT is not suitable for carrying instructions that might
initiate any non-idempotent action.
Paragraph (version A):
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.  In this case, the Initial keys
provide no assurance to the client that the server received its
packet; the client has to rely on the exchange that included the
Retry packet for that property.
Paragraph (version B):
The Destination Connection ID field could be any length up to 20
bytes, including zero length if the server sends a Retry packet
with a zero-length Source Connection ID field.  After a Retry, the
Initial keys provide the client no assurance that the server
received its packet, so the client has to rely on the exchange
that included the Retry packet to validate the server address; see
Section 8.1 of QUIC-TRANSPORT.