Draft: draft-ietf-quic-tls

Commentary: One possible resolution to ; all literals are zero - padded to full bytes . 
 IANA made the following observation while creating the H3 registries : While the IANA copy of the registry uses two digits throughout , the QUIC draft is similarly inconsistent about whether literal hex values have any leading zeros . Is it worth updating our hex literals to use full bytes ( , , etc . ) or synchonizing on some other format ? We probably should n't synchronize on trimming , since IANA has already skewed the other way . 
 did fix this or do we need to inform IANA also ? 
 We should probably shoot IANA an e - mail to update the registries with leading zeroes where they had n't already assumed them . 
 I 'll let you do that . The only registries that are affected are in HTTP/3 and QPACK . 
 Fixed both in the registry and the documents . 
 Yeah , this is easy to understand . The tables must have been annoying .
Paragraph (version A):
A TLS alert is converted into a QUIC connection error.  The
AlertDescription value is added to 0x100 to produce a QUIC error code
from the range reserved for CRYPTO_ERROR.  The resulting value is
sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.
Paragraph (version B):
A TLS alert is converted into a QUIC connection error.  The
AlertDescription value is added to 0x0100 to produce a QUIC error
code from the range reserved for CRYPTO_ERROR.  The resulting value
is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.
Paragraph (version A):
QUIC permits the use of a generic code in place of a specific error
code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this
includes replacing any alert with a generic alert, such as
handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error
code to avoid possibly exposing confidential information.
Paragraph (version B):
QUIC permits the use of a generic code in place of a specific error
code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this
includes replacing any alert with a generic alert, such as
handshake_failure (0x0128 in QUIC).  Endpoints MAY use a generic
error code to avoid possibly exposing confidential information.
Paragraph (version A):
This mechanism replaces the key update mechanism of TLS, which relies
on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints
MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the
receipt of a TLS KeyUpdate message as a connection error of type
0x10a, equivalent to a fatal TLS alert of unexpected_message; see
tls-errors.
Paragraph (version B):
This mechanism replaces the key update mechanism of TLS, which relies
on KeyUpdate messages sent using 1-RTT encryption keys.  Endpoints
MUST NOT send a TLS KeyUpdate message.  Endpoints MUST treat the
receipt of a TLS KeyUpdate message as a connection error of type
0x010a, equivalent to a fatal TLS alert of unexpected_message; see
tls-errors.
Paragraph (version A):
When using ALPN, endpoints MUST immediately close a connection (see
Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS
alert (QUIC error code 0x178; see tls-errors) if an application
protocol is not negotiated.  While ALPN only specifies that servers
use this alert, QUIC clients MUST use error 0x178 to terminate a
connection when ALPN negotiation fails.
Paragraph (version A):
An application protocol MAY restrict the QUIC versions that it can
operate over.  Servers MUST select an application protocol compatible
with the QUIC version that the client has selected.  The server MUST
treat the inability to select a compatible application protocol as a
connection error of type 0x178 (no_application_protocol).  Similarly,
a client MUST treat the selection of an incompatible application
protocol by a server as a connection error of type 0x178.
Paragraph (version B):
When using ALPN, endpoints MUST immediately close a connection (see
Section 10.2 of QUIC-TRANSPORT) with a no_application_protocol TLS
alert (QUIC error code 0x0178; see tls-errors) if an application
protocol is not negotiated.  While ALPN only specifies that servers
use this alert, QUIC clients MUST use error 0x0178 to terminate a
connection when ALPN negotiation fails.
Paragraph (version B):
An application protocol MAY restrict the QUIC versions that it can
operate over.  Servers MUST select an application protocol compatible
with the QUIC version that the client has selected.  The server MUST
treat the inability to select a compatible application protocol as a
connection error of type 0x0178 (no_application_protocol).
Similarly, a client MUST treat the selection of an incompatible
application protocol by a server as a connection error of type
0x0178.
Paragraph (version A):
The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake.  Endpoints
MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the
quic_transport_parameters extension MUST close the connection with an
error of type 0x16d (equivalent to a fatal TLS missing_extension
alert, see tls-errors).
Paragraph (version B):
The quic_transport_parameters extension is carried in the ClientHello
and the EncryptedExtensions messages during the handshake.  Endpoints
MUST send the quic_transport_parameters extension; endpoints that
receive ClientHello or EncryptedExtensions messages without the
quic_transport_parameters extension MUST close the connection with an
error of type 0x016d (equivalent to a fatal TLS missing_extension
alert, see tls-errors).