< draft-ietf-tls-tls13-cert-with-extern-psk-02.txt   draft-ietf-tls-tls13-cert-with-extern-psk-03.txt >
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Experimental May 31, 2019 Intended status: Experimental November 17, 2019
Expires: December 2, 2019 Expires: May 20, 2020
TLS 1.3 Extension for Certificate-based Authentication with an External TLS 1.3 Extension for Certificate-based Authentication with an External
Pre-Shared Key Pre-Shared Key
draft-ietf-tls-tls13-cert-with-extern-psk-02 draft-ietf-tls-tls13-cert-with-extern-psk-03
Abstract Abstract
This document specifies a TLS 1.3 extension that allows a server to This document specifies a TLS 1.3 extension that allows a server to
authenticate with a combination of a certificate and an external pre- authenticate with a combination of a certificate and an external pre-
shared key (PSK). shared key (PSK).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2019. This Internet-Draft will expire on May 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Motivation and Design Rationale 3. Motivation and Design Rationale
The invention of a large-scale quantum computer would pose a serious The development of a large-scale quantum computer would pose a
challenge for the cryptographic algorithms that are widely deployed serious challenge for the cryptographic algorithms that are widely
today, including the digital signature algorithms that are used to deployed today, including the digital signature algorithms that are
authenticate the server in the TLS 1.3 handshake protocol. It is an used to authenticate the server in the TLS 1.3 handshake protocol.
open question whether or not it is feasible to build a large-scale It is an open question whether or not it is feasible to build a
quantum computer, and if so, when that might happen. However, if large-scale quantum computer, and if so, when that might happen.
such a quantum computer is invented, many of the cryptographic However, if such a quantum computer is invented, many of the
algorithms and the security protocols that use them would become cryptographic algorithms and the security protocols that use them
vulnerable. would become vulnerable.
The TLS 1.3 handshake protocol employs key agreement algorithms that The TLS 1.3 handshake protocol employs key agreement algorithms and
could be broken by the invention of a large-scale quantum computer digital signature algorithms that could be broken by the development
[I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) of a large-scale quantum computer [I-D.hoffman-c2pq]. The key
[DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a agreement algorithms include Diffie-Hellman (DH) [DH1977] and
result, an adversary that stores a TLS 1.3 handshake protocol Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital
exchange today could decrypt the associated encrypted communications signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital
in the future when a large-scale quantum computer becomes available. Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary
that stores a TLS 1.3 handshake protocol exchange today could decrypt
the associated encrypted communications in the future when a large-
scale quantum computer becomes available.
In the near-term, this document describes TLS 1.3 extension to In the near-term, this document describes TLS 1.3 extension to
protect today's communications from the future invention of a large- protect today's communications from the future invention of a large-
scale quantum computer by providing a strong external PSK as an input scale quantum computer by providing a strong external PSK as an input
to the TLS 1.3 key schedule while preserving the authentication to the TLS 1.3 key schedule while preserving the authentication
provided by the existing certificate and digital signature provided by the existing certificate and digital signature
mechanisms. mechanisms.
4. Extension Overview 4. Extension Overview
This section provides a brief overview of the This section provides a brief overview of the
"tls_cert_with_extern_psk" extension. "tls_cert_with_extern_psk" extension.
The client includes the "tls_cert_with_extern_psk" extension in the The client includes the "tls_cert_with_extern_psk" extension in the
ClientHello message. The "tls_cert_with_extern_psk" extension MUST ClientHello message. The "tls_cert_with_extern_psk" extension MUST
be accompanied by the "key_share", "psk_key_exchange_modes", and be accompanied by the "key_share", "psk_key_exchange_modes", and
"pre_shared_key" extensions. The "pre_shared_key" extension MUST be "pre_shared_key" extensions. The client MAY also find it useful to
the last extension in the ClientHello message, and it provides a list include the "supported_groups" extension. Since the
of external PSK identifiers that the client is willing to use with "tls_cert_with_extern_psk" extension is intended to be used only with
this server. Since the "tls_cert_with_extern_psk" extension is initial handshakes, it MUST NOT be sent alongside the "early_data"
intended to be used only with initial handshakes, it MUST NOT be sent extension. These extensions are all described in Section 4.2 of
alongside the "early_data" extension. These extensions are all [RFC8446], which also requires the "pre_shared_key" extension to be
described in Section 4.2 of [RFC8446]. the last extension in the ClientHello message.
If the server is willing to use one of the external PSKs listed in If the server is willing to use one of the external PSKs listed in
the "pre_shared_key" extension and perform certificate-based the "pre_shared_key" extension and perform certificate-based
authentication, then the server includes the authentication, then the server includes the
"tls_cert_with_extern_psk" extension in the ServerHello message. The "tls_cert_with_extern_psk" extension in the ServerHello message. The
"tls_cert_with_extern_psk" extension MUST be accompanied by the "tls_cert_with_extern_psk" extension MUST be accompanied by the
"key_share" and "pre_shared_key" extensions. If none of the external "key_share" and "pre_shared_key" extensions. If none of the external
PSKs in the list provided by the client is acceptable to the server, PSKs in the list provided by the client is acceptable to the server,
then the "tls_cert_with_extern_psk" extension is omitted from the then the "tls_cert_with_extern_psk" extension is omitted from the
ServerHello message. ServerHello message.
The successful negotiation of the "tls_cert_with_extern_psk" When the "tls_cert_with_extern_psk" extension is successfully
extension requires the TLS 1.3 key schedule processing to include negotiated, the TLS 1.3 key schedule processing includes both the
both the selected external PSK and the (EC)DHE shared secret value. selected external PSK and the (EC)DHE shared secret value. As a
As a result, the Early Secret, Handshake Secret, and Master Secret result, the Early Secret, Handshake Secret, and Master Secret values
values all depend upon the value of the selected external PSK. all depend upon the value of the selected external PSK. Of course,
the Early Secret does not depend upon the (EC)DHE shared secret.
The authentication of the server and optional authentication of the The authentication of the server and optional authentication of the
client depend upon the ability to generate a signature that can be client depend upon the ability to generate a signature that can be
validated with the public key in their certificates. The validated with the public key in their certificates. The
authentication processing is not changed in any way by the selected authentication processing is not changed in any way by the selected
external PSK. external PSK.
Each external PSK is associated with a single hash algorithm, which Each external PSK is associated with a single hash algorithm, which
is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST
be set when the PSK is established, with a default of SHA-256 if no be set when the PSK is established, with a default of SHA-256.
hash algorithm is specified during establishment.
5. Certificate with External PSK Extension 5. Certificate with External PSK Extension
This section specifies the "tls_cert_with_extern_psk" extension, This section specifies the "tls_cert_with_extern_psk" extension,
which MAY appear in the ClientHello message and ServerHello message. which MAY appear in the ClientHello message and ServerHello message.
It MUST NOT appear in any other messages. The It MUST NOT appear in any other messages. The
"tls_cert_with_extern_psk" extension MUST NOT appear in the "tls_cert_with_extern_psk" extension MUST NOT appear in the
ServerHello message unless the "tls_cert_with_extern_psk" extension ServerHello message unless the "tls_cert_with_extern_psk" extension
appeared in the preceding ClientHello message. If an implementation appeared in the preceding ClientHello message. If an implementation
recognizes the "tls_cert_with_extern_psk" extension and receives it recognizes the "tls_cert_with_extern_psk" extension and receives it
in any other message, then the implementation MUST abort the in any other message, then the implementation MUST abort the
handshake with an "illegal_parameter" alert. handshake with an "illegal_parameter" alert.
The general extension mechanisms enable clients and servers to The general extension mechanisms enable clients and servers to
negotiate the use of specific extensions. Clients request extended negotiate the use of specific extensions. Clients request extended
functionality from servers with the extensions field in the functionality from servers with the extensions field in the
ClientHello message. If the server responds with a HelloRetryRequest ClientHello message. If the server responds with a HelloRetryRequest
message, then the client sends another ClientHello message as message, then the client sends another ClientHello message as
described in Section 4.1.2 of [RFC8446], and it MUST include the same described in Section 4.1.2 of [RFC8446], including the same
"tls_cert_with_extern_psk" extension as the original ClientHello "tls_cert_with_extern_psk" extension as the original ClientHello
message or abort the handshake. message or abort the handshake.
Many server extensions are carried in the EncryptedExtensions Many server extensions are carried in the EncryptedExtensions
message; however, the "tls_cert_with_extern_psk" extension is carried message; however, the "tls_cert_with_extern_psk" extension is carried
in the ServerHello message. It is only present in the ServerHello in the ServerHello message. Successful negotiation of the
message if the server recognizes the "tls_cert_with_extern_psk" "tls_cert_with_extern_psk" extension affects the key used for
extension and the server possesses one of the external PSKs offered encryption, so it cannot be carried in the EncryptedExtensions
by the client in the "pre_shared_key" extension in the ClientHello message. Therefore, the "tls_cert_with_extern_psk" extension is only
message. present in the ServerHello message if the server recognizes the
"tls_cert_with_extern_psk" extension and the server possesses one of
the external PSKs offered by the client in the "pre_shared_key"
extension in the ClientHello message.
The Extension structure is defined in [RFC8446]; it is repeated here The Extension structure is defined in [RFC8446]; it is repeated here
for convenience. for convenience.
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
The "extension_type" identifies the particular extension type, and The "extension_type" identifies the particular extension type, and
skipping to change at page 5, line 22 skipping to change at page 5, line 22
extension is essentially a flag to use the external PSK in the key extension is essentially a flag to use the external PSK in the key
schedule, and it has the following syntax: schedule, and it has the following syntax:
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: Empty; case client_hello: Empty;
case server_hello: Empty; case server_hello: Empty;
}; };
} CertWithExternPSK; } CertWithExternPSK;
To use an external PSK with certificates, clients MUST provide the 5.1. Companion Extensions
"tls_cert_with_extern_psk" extension, and it MUST be accompanied by
the "key_share", "psk_key_exchange_modes", and "pre_shared_key"
extensions in the ClientHello. If clients offer a
"tls_cert_with_extern_psk" extension without all of these other
extensions, servers MUST abort the handshake. The client MAY also
find it useful to include the "supported_groups" extension. Note
that Section 4.2 of [RFC8446] allows extensions to appear in any
order, with the exception of the "pre_shared_key" extension, which
MUST be the last extension in the ClientHello. Also, there MUST NOT
be more than one instance of each extension in the ClientHello
message.
The "key_share" extension is defined in Section 4.2.8 of [RFC8446]. Section 4 lists the extensions that are required to accompany the
"tls_cert_with_extern_psk" extension. Most of those extension are
not impacted in any way. This section discusses the impacts on the
other extensions.
The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
[RFC8446]. The "psk_key_exchange_modes" extension restricts both the [RFC8446]. The "psk_key_exchange_modes" extension restricts both the
use of PSKs offered in this ClientHello and those which the server use of PSKs offered in this ClientHello and those which the server
might supply via a subsequent NewSessionTicket. As a result, clients might supply via a subsequent NewSessionTicket. As a result, when
MUST include the psk_dhe_ke mode, and clients MAY also include the the "psk_key_exchange_modes" extension is included in the ClientHello
psk_ke mode to support a subsequent NewSessionTicket. Servers MUST message, clients MUST include psk_dhe_ke mode. In addition, clients
select the psk_dhe_ke mode for the initial handshake. Servers MUST MAY also include psk_ke mode to support a subsequent
select a key exchange mode that is listed by the client for NewSessionTicket. When the "psk_key_exchange_modes" extension is
subsequent handshakes that include the resumption PSK from the included in the ServerHello message, servers MUST select the
initial handshake. psk_dhe_ke mode for the initial handshake. Servers MUST select a key
exchange mode that is listed by the client for subsequent handshakes
The "supported_groups" extension is defined in Section 4.2.7 of that include the resumption PSK from the initial handshake.
[RFC8446].
The "pre_shared_key" extension is defined in Section 4.2.11 of The "pre_shared_key" extension is defined in Section 4.2.11 of
[RFC8446]. The syntax is repeated below for convenience. All of the [RFC8446]. The syntax is repeated below for convenience. All of the
listed PSKs MUST be external PSKs. listed PSKs MUST be external PSKs. If a resumption PSK is listed
along with the "tls_cert_with_extern_psk" extension, the server MUST
abort the handshake with an "illegal_parameter" alert.
struct { struct {
opaque identity<1..2^16-1>; opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
} PskIdentity; } PskIdentity;
opaque PskBinderEntry<32..255>; opaque PskBinderEntry<32..255>;
struct { struct {
PskIdentity identities<7..2^16-1>; PskIdentity identities<7..2^16-1>;
skipping to change at page 6, line 39 skipping to change at page 6, line 35
binders for the external PSKs that the client is willing to use with binders for the external PSKs that the client is willing to use with
the server. the server.
The identities are a list of external PSK identities that the client The identities are a list of external PSK identities that the client
is willing to negotiate with the server. Each external PSK has an is willing to negotiate with the server. Each external PSK has an
associated identity that is known to the client and the server; the associated identity that is known to the client and the server; the
associated identities may be know to other parties as well. In associated identities may be know to other parties as well. In
addition, the binder validation (see below) confirms that the client addition, the binder validation (see below) confirms that the client
and server have the same key associated with the identity. and server have the same key associated with the identity.
The obfuscated_ticket_age is not used for external PSKs; clients The obfuscated_ticket_age is not used for external PSKs. As stated
SHOULD set this value to 0, and servers MUST ignore the value. in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
and servers MUST ignore the value.
The binders are a series of HMAC values, one for each external PSK The binders are a series of HMAC values, one for each external PSK
offered by the client, in the same order as the identities list. The offered by the client, in the same order as the identities list. The
HMAC value is computed using the binder_key, which is derived from HMAC value is computed using the binder_key, which is derived from
the external PSK, and a partial transcript of the current handshake. the external PSK, and a partial transcript of the current handshake.
Generation of the binder_key from the external PSK is described in Generation of the binder_key from the external PSK is described in
Section 7.1 of [RFC8446]. The partial transcript of the current Section 7.1 of [RFC8446]. The partial transcript of the current
handshake includes a partial ClientHello up to and including the handshake includes a partial ClientHello up to and including the
PreSharedKeyExtension.identities field as described in PreSharedKeyExtension.identities field as described in
Section 4.2.11.2 of [RFC8446]. Section 4.2.11.2 of [RFC8446].
The selected_identity contains the external PSK identity that the The selected_identity contains the index of the external PSK identity
server selected from the list offered by the client. If none of the that the server selected from the list offered by the client. As
offered external PSKs in the list provided by the client are described in Section 4.2.11.2 of [RFC8446], the server MUST validate
acceptable to the server, then the "tls_cert_with_extern_psk" the binder value that corresponds to the selected external PSK, and
extension MUST be omitted from the ServerHello message. The server if the binder does not validate, the server MUST abort the handshake
MUST validate the binder value that corresponds to the selected with an "illegal_parameter" alert.
external PSK as described in Section 4.2.11.2 of [RFC8446]. If the
binder does not validate, the server MUST abort the handshake with an 5.2. Authentication
"illegal_parameter" alert. Servers SHOULD NOT attempt to validate
multiple binders; rather they SHOULD select one of the offered
external PSKs and validate only the binder that corresponds to that
external PSK.
When the "tls_cert_with_extern_psk" extension is successfully When the "tls_cert_with_extern_psk" extension is successfully
negotiated, authentication of the server depends upon the ability to negotiated, authentication of the server depends upon the ability to
generate a signature that can be validated with the public key in the generate a signature that can be validated with the public key in the
server's certificate. This is accomplished by the server sending the server's certificate. This is accomplished by the server sending the
Certificate and CertificateVerify messages as described in Sections Certificate and CertificateVerify messages as described in Sections
4.4.2 and 4.4.3 of [RFC8446]. 4.4.2 and 4.4.3 of [RFC8446].
TLS 1.3 does not permit the server to send a CertificateRequest TLS 1.3 does not permit the server to send a CertificateRequest
message when a PSK is being used. This restriction is removed when message when a PSK is being used. This restriction is removed when
the "tls_cert_with_extern_psk" extension is negotiated, allowing the "tls_cert_with_extern_psk" extension is negotiated, allowing
certificate-based authentication for both the client and the server. certificate-based authentication for both the client and the server.
If certificate-based client authentication is desired, this is If certificate-based client authentication is desired, this is
accomplished by the client sending the Certificate and accomplished by the client sending the Certificate and
CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
of [RFC8446]. of [RFC8446].
5.3. Keying Material
Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The
successful negotiation of the "tls_cert_with_extern_psk" extension successful negotiation of the "tls_cert_with_extern_psk" extension
requires the key schedule processing to include both the external PSK requires the key schedule processing to include both the external PSK
and the (EC)DHE shared secret value. and the (EC)DHE shared secret value.
If the client and the server have different values associated with If the client and the server have different values associated with
the selected external PSK identifier, then the client and the server the selected external PSK identifier, then the client and the server
will compute different values for every entry in the key schedule, will compute different values for every entry in the key schedule,
which will lead to the termination of the connection with a which will lead to the client aborting the handshake with a
"decrypt_error" alert. "decrypt_error" alert.
6. IANA Considerations 6. IANA Considerations
IANA is requested to update the TLS ExtensionType Registry to include IANA is requested to update the TLS ExtensionType Registry to include
"tls_cert_with_extern_psk" with a value of TBD and the list of "tls_cert_with_extern_psk" with a value of TBD and the list of
messages "CH, SH" in which the "tls_cert_with_extern_psk" extension messages "CH, SH" in which the "tls_cert_with_extern_psk" extension
may appear. may appear.
7. Security Considerations 7. Security Considerations
skipping to change at page 8, line 20 skipping to change at page 8, line 13
CertificateRequest message when a PSK is being used. This CertificateRequest message when a PSK is being used. This
restriction is removed when the "tls_cert_with_extern_psk" extension restriction is removed when the "tls_cert_with_extern_psk" extension
is offered by the client and accepted by the server. However, TLS is offered by the client and accepted by the server. However, TLS
1.3 does not permit an external PSK to be used in the same fashion as 1.3 does not permit an external PSK to be used in the same fashion as
a resumption PSK, and this extension does not alter those a resumption PSK, and this extension does not alter those
restrictions. Thus, a certificate MUST NOT be used with a resumption restrictions. Thus, a certificate MUST NOT be used with a resumption
PSK. PSK.
Implementations must protect the external pre-shared key (PSK). Implementations must protect the external pre-shared key (PSK).
Compromise of the external PSK will make the encrypted session Compromise of the external PSK will make the encrypted session
content vulnerable to the future invention of a large-scale quantum content vulnerable to the future development of a large-scale quantum
computer. computer.
Implementers should not transmit the same content on a connection Implementers should not transmit the same content on a connection
that is protected with an external PSK and a connection that is not. that is protected with an external PSK and a connection that is not.
Doing so may allow an eavesdropper to correlate the connections, Doing so may allow an eavesdropper to correlate the connections,
making the content vulnerable to the future invention of a large- making the content vulnerable to the future invention of a large-
scale quantum computer. scale quantum computer.
Implementations must generate external PSKs with a secure key Implementations must generate external PSKs with a secure key
management technique, such as pseudo-random generation of the key or management technique, such as pseudo-random generation of the key or
skipping to change at page 9, line 41 skipping to change at page 9, line 35
of other members, and then decrypt it if they ever gain access to a of other members, and then decrypt it if they ever gain access to a
large-scale quantum computer. Also, when many parties know the large-scale quantum computer. Also, when many parties know the
external PSK, there are many opportunities for theft of the external external PSK, there are many opportunities for theft of the external
PSK by an attacker. Once an attacker has the external PSK, they can PSK by an attacker. Once an attacker has the external PSK, they can
decrypt stored traffic if they ever gain access to a large-scale decrypt stored traffic if they ever gain access to a large-scale
quantum computer in the same manner as a legitimate group member. quantum computer in the same manner as a legitimate group member.
TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
bound to a specific hash function and KDF. By contrast, TLS 1.2 bound to a specific hash function and KDF. By contrast, TLS 1.2
[RFC5246] allows PSKs to be used with any hash function and the TLS [RFC5246] allows PSKs to be used with any hash function and the TLS
1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with
1.2 or TLS 1.3. However, any PSK that might be used with both TLS TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a
1.2 and TLS 1.3 must be used with only one hash function, which is PSK for exclusive use with TLS 1.2 and derive another PSK for
the one that is bound for use in TLS 1.3. This restriction is less exclusive use with TLS 1.3 using the mechanism specified in
than optimal when users want to provision a single PSK. While the [I-D.ietf-tls-external-psk-importer].
constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC
[RFC2104], the constructions are different, and there is no known way
in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would
produce related outputs.
TLS 1.3 [RFC8446] has received careful security analysis, and some TLS 1.3 [RFC8446] has received careful security analysis, and some
informal reasoning shows that the addition of this extension does not informal reasoning shows that the addition of this extension does not
introduce any security defects. This extension requires the use of introduce any security defects. This extension requires the use of
certificates for authentication, but the processing of certificates certificates for authentication, but the processing of certificates
is unchanged by this extension. This extension places an external is unchanged by this extension. This extension places an external
PSK in the key schedule as part of the computation of the Early PSK in the key schedule as part of the computation of the Early
Secret. In the initial handshake without this extension, the Early Secret. In the initial handshake without this extension, the Early
Secret is computed as: Secret is computed as:
skipping to change at page 10, line 36 skipping to change at page 10, line 26
This extension makes use of external PSKs to improve resilience This extension makes use of external PSKs to improve resilience
against attackers that gain access to a large-scale quantum computer against attackers that gain access to a large-scale quantum computer
in the future. This extension is always accompanied by the in the future. This extension is always accompanied by the
"pre_shared_key" extension to provide the PSK identities in plaintext "pre_shared_key" extension to provide the PSK identities in plaintext
in the ClientHello message. Passive observation of the these PSK in the ClientHello message. Passive observation of the these PSK
identities will aid an attacker to track users of this extension. identities will aid an attacker to track users of this extension.
9. Acknowledgments 9. Acknowledgments
Many thanks to Liliya Akhmetzyanova, Christian Huitema, Geoffrey Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk,
Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick Sullivan, Geoffrey Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick
Martin Thomson, and Peter Yee for their review and comments; their Sullivan, Martin Thomson, and Peter Yee for their review and
efforts have improved this document. comments; their efforts have improved this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 19 skipping to change at page 11, line 5
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References 10.2. Informative References
[DH1977] Diffie, W. and M. Hellman, "New Directions in [DH1977] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Cryptography", IEEE Transactions on Information
Theory V.IT-22 n.6, June 1977. Theory V.IT-22 n.6, June 1977.
[FIPS186] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing
Standards Publication (FIPS PUB) 186-4, July 2013.
[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
construct random functions", J. ACM 1986 (33), pp. construct random functions", J. ACM 1986 (33), pp.
792-807, 1986. 792-807, 1986.
[I-D.hoffman-c2pq] [I-D.hoffman-c2pq]
Hoffman, P., "The Transition from Classical to Post- Hoffman, P., "The Transition from Classical to Post-
Quantum Cryptography", draft-hoffman-c2pq-05 (work in Quantum Cryptography", draft-hoffman-c2pq-05 (work in
progress), May 2019. progress), May 2019.
[I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. Wood, "Importing External PSKs for
TLS", draft-ietf-tls-external-psk-importer-01 (work in
progress), October 2019.
[IEEE1363] [IEEE1363]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard Specifications for Public-Key Cryptography", IEEE Standard Specifications for Public-Key Cryptography", IEEE
Std 1363-2000, 2000. Std 1363-2000, 2000.
[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
Compiler for Key Exchange (with Applications to Client Compiler for Key Exchange (with Applications to Client
Authentication in TLS 1.3)", IACR ePrint 2016/711, August Authentication in TLS 1.3)", IACR ePrint 2016/711, August
2016. 2016.
skipping to change at page 12, line 5 skipping to change at page 11, line 48
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
USA USA
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 24 change blocks. 
93 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/