draft-ietf-tls-semistatic-dh-00.txt   draft-ietf-tls-semistatic-dh-01.txt 
TLS Working Group E. Rescorla TLS Working Group E. Rescorla
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track N. Sullivan Intended status: Standards Track N. Sullivan
Expires: July 20, 2020 Cloudflare Expires: 8 September 2020 Cloudflare
C. Wood C.A. Wood
Apple Inc. Apple Inc.
January 17, 2020 7 March 2020
Semi-Static Diffie-Hellman Key Establishment for TLS 1.3 Semi-Static Diffie-Hellman Key Establishment for TLS 1.3
draft-ietf-tls-semistatic-dh-00 draft-ietf-tls-semistatic-dh-01
Abstract Abstract
TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman exchange modelled
exchange modelled after SIGMA [SIGMA]. This design is suitable for after SIGMA [SIGMA]. This design is suitable for endpoints whose
endpoints whose certified credential is a signing key, which is the certified credential is a signing key, which is the common situation
common situation for current TLS servers. This document describes a for current TLS servers. This document describes a mode of TLS 1.3
mode of TLS 1.3 in which one or both endpoints have a certified DH in which one or both endpoints have a certified DH key which is used
key which is used to authenticate the exchange. to authenticate the exchange.
Note to Readers
Source for this draft and an issue tracker can be found at
https://github.com/ekr/draft-rescorla-tls13-semistatic-dh
(https://github.com/ekr/draft-rescorla-tls13-semistatic-dh).
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 20, 2020. This Internet-Draft will expire on 8 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Certificate Format . . . . . . . . . . . . . . . . . . . . . 5 4. Certificate Format . . . . . . . . . . . . . . . . . . . . . 5
5. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 5 5. Certificate Verify Computation . . . . . . . . . . . . . . . 5
5.1. Certificate Verify Computation . . . . . . . . . . . . . 5
5.2. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 6
6. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 6. Client Authentication . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
DISCLAIMER: This is a work-in-progress draft and has not yet seen DISCLAIMER: This is a work-in-progress draft and has not yet seen
significant security analysis. Thus, this draft should not be used significant security analysis. Thus, this draft should not be used
as a basis for building production systems. as a basis for building production systems.
TLS 1.3 [I-D.ietf-tls-tls13] specifies a signed Diffie-Hellman TLS 1.3 [RFC8446] specifies a signed Diffie-Hellman (DH) exchange
exchange modeled after SIGMA [SIGMA]. This design is suitable for modeled after SIGMA [SIGMA]. This design is suitable for endpoints
endpoints whose certified credential is a signing key, which is the whose certified credential is a signing key, which is the common
common situation for current TLS servers, which is why it was situation for current TLS servers, which is why it was selected for
selected for TLS 1.3. TLS 1.3.
However, it is also possible - although currently rare - for However, it is also possible - although currently rare - for
endpoints to have a credential which is an (EC)DH key. This can endpoints to have a credential which is an (EC)DH key. This can
happen in one of two ways: happen in one of two ways:
o They may be issued a certificate with an (EC)DH key, as specified * They may be issued a certificate with an (EC)DH key, as specified
for instance in [I-D.ietf-curdle-pkix] for instance in [I-D.ietf-curdle-pkix]
o They may have a signing key which they use to generate a delegated * They may have a signing key which they use to generate a delegated
credential [I-D.ietf-tls-subcerts] containing an (EC)DH key. credential [I-D.ietf-tls-subcerts] containing an (EC)DH key.
In these situations, a signed DH exchange is not appropriate, and In these situations, a signed DH exchange is not appropriate, and
instead a design in which the server authenticates via its long-term instead a design in which the endpoint authenticates via its long-
(EC)DH key is suitable. This document describes such a design term (EC)DH key is suitable. This document describes such a design
modeled on that described in OPTLS [KW16]. modeled on that described in OPTLS [KW16].
This design has a number of potential advantages over the signed This design has a number of potential advantages over the signed
exchange in TLS 1.3, specifically: exchange in TLS 1.3, specifically:
o If the end-entity certificate contains an (EC)DH key, TLS can * If the end-entity certificate contains an (EC)DH key, TLS can
operate with a single asymmetric primitive (Diffie-Hellman). The operate with a single asymmetric primitive (Diffie-Hellman). The
PKI component will still need signatures, but the TLS stack need PKI component will still need signatures, but the TLS stack need
not have one. Note that this advantage is somewhat limited if the not have one. Note that this advantage is somewhat limited if the
(EC)DH key is in a delegated credential, but that allows for a (EC)DH key is in a delegated credential, but that allows for a
clean transition to (EC)DH certificates. clean transition to (EC)DH certificates.
o It is more resistant to random number generation failures on the * If the endpoint has a comparatively slow signing cert (e.g.,
server because the attacker needs to have both the server's long- P-256) it can amortize that signature over a large number of
term (EC)DH key and the ephemeral (EC)DH key in order to compute connections by creating a delegated credential with an (EC)DH key
the traffic secrets. [Note: from a faster group (e.g., X25519).
[I-D.irtf-cfrg-randomness-improvements] describes a technique for
accomplishing this with a signed exchange.]
o If the server has a comparatively slow signing cert (e.g., P-256)
it can amortize that signature over a large number of connections
by creating a delegated credential with an (EC)DH key from a
faster group (e.g., X25519).
o Because there is no signature, the server has deniability for the * Because there is no signature, the endpoint has deniability for
existence of the communication. Note that it could always have the existence of the communication. Note that it could always
denied the contents of the communication. have denied the contents of the communication.
This exchange is not generally faster than a signed exchange if This exchange is not generally faster than a signed exchange if
comparable groups are used. In fact, if delegated credentials are comparable groups are used. In fact, if delegated credentials are
used, it may be slower on the client as it has to validate the used, it may be slower on the client as it has to validate the
delegated credential, though the result may be cached. delegated credential, though the result may be cached.
2. Protocol Overview 2. Protocol Overview
The overall protocol flow remains the same as that in ordinary TLS The overall protocol flow remains the same as that in ordinary TLS
1.3, as shown below: 1.3, as shown below:
Client Server Client Server
Key ^ ClientHello Key ^ ClientHello
Exch | + key_share* Exch | + key_share*
| + signature_algorithms* | + signature_algorithms*
| + psk_key_exchange_modes* | + psk_key_exchange_modes*
v + pre_shared_key* --------> v + pre_shared_key* -------->
ServerHello ^ Key ServerHello ^ Key
+ key_share* | Exch + key_share* | Exch
+ pre_shared_key* v + pre_shared_key* v
{EncryptedExtensions} ^ Server {EncryptedExtensions} ^ Server
{CertificateRequest*} v Params {CertificateRequest*} v Params
{Certificate*} ^ {Certificate*} ^
{CertificateVerify*} | Auth {CertificateVerify*} | Auth
{Finished} v {Finished} v
<-------- [Application Data*] <-------- [Application Data*]
^ {Certificate*} ^ {Certificate*}
Auth | {CertificateVerify*} Auth | {CertificateVerify*}
v {Finished} --------> v {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
As usual, the client and server each supply an (EC)DH share in their As usual, the client and server each supply an (EC)DH share in their
"key_share" extensions. However, in addition, the server supplies a "key_share" extensions. However, in addition, the server supplies a
(signed) static (EC)DH share in its Certificate message, either (signed) static (EC)DH share in its Certificate message, either
directly in its end-entity certificate or in a delegated credential. directly in its end-entity certificate or in a delegated credential.
The client and server then perform two (EC)DH exchanges: The client and server then perform two (EC)DH exchanges:
o Between the client and server "key_share" values to form an * Between the client and server "key_share" values to form an
ephemeral secret (ES). This is the same value as is computed in ephemeral secret (ES). This is the same value as is computed in
TLS 1.3 currently. TLS 1.3 currently.
o Between the client's "key_share" and the server's static share, to * Between the client's "key_share" and the server's static share, to
form a static secret (SS). form a static secret (SS).
Note that this means that the server's static secret MUST be in the Note that this means that the server's static secret MUST be in the
same group as selected group for the ephemeral (EC)DH exchange. same group as selected group for the ephemeral (EC)DH exchange.
The handshake then proceeds as usual, except that: The handshake then proceeds as usual, except that instead of
containing a signature, the CertificateVerify contains a MAC of the
o Instead of containing a signature, the CertificateVerify contains handshake transcript, computed based on SS.
a MAC of the handshake transcript, computed based on SS.
o SS is mixed into the key schedule at the last HKDF-Extract stage
(where currently a 0 is used as the IKM input).
3. Negotiation 3. Negotiation
In order to negotiate this mode, we treat the (EC)DH MAC as if it In order to negotiate this mode, we treat the (EC)DH MAC as if it
were a signature and negotiate it with a set of new signature scheme were a signature and negotiate it with a set of new signature scheme
values: values:
enum { enum {
sig_p256(0x0901), sig_p256(0x0901),
sig_p384(0x0902), sig_p384(0x0902),
skipping to change at page 5, line 26 skipping to change at page 5, line 20
sig_x448(0x0905), sig_x448(0x0905),
} SignatureScheme; } SignatureScheme;
When present in the "signature_algorithms" extension or When present in the "signature_algorithms" extension or
CertificateVerify.signature_scheme, these values indicate DH MAC with CertificateVerify.signature_scheme, these values indicate DH MAC with
the specified key exchange mode. These values MUST NOT appear in the specified key exchange mode. These values MUST NOT appear in
"signature_algorithms_cert". "signature_algorithms_cert".
Before sending and upon receipt, endpoints MUST ensure that the Before sending and upon receipt, endpoints MUST ensure that the
signature scheme is consistent with the ephemeral (EC)DH group in signature scheme is consistent with the ephemeral (EC)DH group in
use. use. Clients MUST NOT advertise signature scheme values that are
inconsistent with the "named_groups" extension they offer.
4. Certificate Format 4. Certificate Format
Like signing keys, static DH keys are carried in the Certificate Similar to signing keys, static DH keys are carried in the
message, either directly in the EE certificate, or in a delegated Certificate message, either directly in the EE certificate, or in a
credential. In either case, the OID for the SubjectPublicKeyInfo delegated credential. In either case, the OID for the
MUST be appropriate for use with (EC)DH key establishment. If in a SubjectPublicKeyInfo MUST be appropriate for use with (EC)DH key
certificate, the key usage and EKU MUST also be set appropriately See establishment. If in a certificate, the key usage and EKU MUST also
[I-D.ietf-curdle-pkix] and [[TBD: P-256, etc.]] for specific details be set appropriately. See [I-D.ietf-curdle-pkix] for specific
about these formats. details about these formats.
5. Cryptographic Details
5.1. Certificate Verify Computation 5. Certificate Verify Computation
Instead of a signature, the server proves knowledge of the private Instead of a signature, the server proves knowledge of the private
key associated with its static share by computing a MAC over the key associated with its static share by computing a MAC over the
handshake transcript using SS. The transcript thus far includes all handshake transcript using SS. The transcript thus far includes all
messages up to and including Certificate, i.e.: messages up to and including Certificate, i.e.:
Transcript-Hash(Handshake Context, Certificate) Transcript-Hash(Handshake Context, Certificate)
The MAC key - SS-Base-Key - is derived from SS as follows: The MAC key, xSS, is derived from SS as follows:
SS-Base-Key = HKDF-Extract(0, SS) xSS = HKDF-Extract(0, SS)
The MAC is then computed using the Finished computation described in The MAC is then computed using the Finished computation described in
[I-D.ietf-tls-tls13] Section 4.4, with SS-Base-Key as the Base Key [RFC8446] Section 4.4, with xSS as the Base Key value. Receivers
value. Receivers MUST validate the MAC and terminate the handshake MUST validate the MAC and terminate the handshake with a
with a "decrypt_error" alert upon failure. "decrypt_error" alert upon failure.
Note that this means that the server sends two MAC computations in Note that this means that the server sends two MAC computations in
the handshake, one in CertificateVerify using SS and the other in the handshake, one in CertificateVerify using SS and the other in
Finished using the Master Secret. These MACs serve different Finished using the Master Secret. These MACs serve different
purposes: the first authenticates the handshake and the second proves purposes: the first authenticates the handshake and the second proves
possession of the ephemeral secret. possession of the ephemeral secret.
5.2. Key Schedule
The final HKDF-Extract stage of the TLS 1.3 key schedule has an HKDF-
Extract with the IKM of 0. When static key exchange is negotiated,
that 0 is replaced with SS, as shown below.
...
Derive-Secret(., "derived", "")
|
v
SS -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
...
6. Client Authentication 6. Client Authentication
[[OPEN ISSUE]] In principle, we can do client authentication the same Client authentication works similar to that of server authentication
way, with the client's DH key in Certificate and a MAC in described in Section 2. In particular, servers indicate support of
CertificateVerity. However, it's less good because the client's semi-static keys by sending one of the relevant SignatureScheme
static key doesn't get mixed in at all. Also, client DH keys seem values defined in Section 3 inside the CertificateRequest
even further off. "signature_algorithms" extension. If applicable, clients reply with
a non-empty Certificate message carrying a corresponding certificate
with static DH key matching the chosen signature algorithm. Clients
then also compute the CertificateVerify message using the procedure
of Section 5, over the transcript hash Handshake Context described in
[RFC8446], Section 4.4.
If no matching certificate is available, clients send an empty
Certificate message as per [RFC8446]; Section 4.4.2.
7. Security Considerations 7. Security Considerations
[[OPEN ISSUE: This design requires formal analysis.]] [[OPEN ISSUE: This design requires formal analysis.]]
This is intended to have roughly equivalent security properties to This is intended to have roughly equivalent security properties to
current TLS 1.3, except for the points raised in the introduction. current TLS 1.3, except for the points raised in the introduction.
Open questions: Open questions:
o Should semi-static key shares be mixed into the key schedule for * Should semi-static key shares be mixed into the key schedule?
client authentication?
o Should we add support for early data encryption using a semi-
static key?
8. IANA Considerations 8. IANA Considerations
IANA [SHOULD add/has added] the new code points specified in IANA [SHOULD add/has added] the new code points specified in
Section 3 to the TLS 1.3 signature scheme registry, with a Section 3 to the TLS 1.3 signature scheme registry, with a
"recommended" value of TBD. "recommended" value of TBD.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-curdle-pkix] [I-D.ietf-curdle-pkix]
Josefsson, S. and J. Schaad, "Algorithm Identifiers for Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519 and X448 for use in the Internet Ed25519, Ed448, X25519 and X448 for use in the Internet
X.509 Public Key Infrastructure", draft-ietf-curdle- X.509 Public Key Infrastructure", Work in Progress,
pkix-10 (work in progress), May 2018. Internet-Draft, draft-ietf-curdle-pkix-10, 8 May 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-curdle-
[I-D.ietf-httpbis-http2-secondary-certs] pkix-10.txt>.
Bishop, M., Sullivan, N., and M. Thomson, "Secondary
Certificate Authentication in HTTP/2", draft-ietf-httpbis-
http2-secondary-certs-05 (work in progress), November
2019.
[I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-11 (work in progress),
December 2019.
[I-D.ietf-tls-subcerts] [I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", draft-ietf-tls- "Delegated Credentials for TLS", Work in Progress,
subcerts-05 (work in progress), November 2019. Internet-Draft, draft-ietf-tls-subcerts-06, 5 February
2020, <http://www.ietf.org/internet-drafts/draft-ietf-tls-
[I-D.ietf-tls-tls13] subcerts-06.txt>.
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Requirement Levels", BCP 14, RFC 2119, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc8446>.
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.irtf-cfrg-randomness-improvements]
Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", draft-irtf-cfrg-randomness-improvements-08
(work in progress), November 2019.
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
Proceedings of Euro S"P 2016 , 2016, Proceedings of Euro S"P 2016 , 2016,
<https://eprint.iacr.org/2015/978>. <https://eprint.iacr.org/2015/978>.
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to [SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to
authenticated Diffie-Hellman and its use in the IKE authenticated Diffie-Hellman and its use in the IKE
protocols", Proceedings of CRYPTO 2003 , 2003. protocols", Proceedings of CRYPTO 2003 , 2003.
Authors' Addresses Authors' Addresses
skipping to change at page 8, line 35 skipping to change at page 7, line 40
Email: ekr@rtfm.com Email: ekr@rtfm.com
Nick Sullivan Nick Sullivan
Cloudflare Cloudflare
Email: nick@cloudflare.com Email: nick@cloudflare.com
Christopher A. Wood Christopher A. Wood
Apple Inc. Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: cawood@apple.com Email: cawood@apple.com
 End of changes. 35 change blocks. 
157 lines changed or deleted 112 lines changed or added

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