| LURK WG | D. Migault, Ed. |
| Internet-Draft | Ericsson |
| Intended status: Informational | March 11, 2017 |
| Expires: September 12, 2017 |
LURK Protocol for TLS/DTLS1.2 version 1.0
draft-mglt-lurk-tls-01
This document describes the LURK protocol as well as its TLS extension designated as LURK/TLS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document describes the use of Limited Use of Remote Keys (LURK) in the context of TLS1.1 and TLS1.2, with the LURK TLS extension also designated as LURK/TLS. Typically, an Edge Server that terminates a TLS session without hosting the secret key performs remote secret key cryptographic operations on the Key Server using LURK/TLS as the communication protocol between these two entities. LURK/TLS communications are performed between a LURK Client hosted on the Edge Server and a LURK Server hosted on the Key Server. [I-D.mglt-lurk-tls-use-cases] describes more in depth use cases where LURK/TLS may be used.
The main advantage of LURK/TLS is that it does not require any changes on TLS Client and as such, constitutes an appropriate solution for legacy devices using TLS1.1 or TLS1.2. On the other hand, LURK/TLS introduces additional exchanges between the Edge Server and the Key Server which increases the latency when setting a TLS session. With TLS version greater than 1.2, new TLS extensions [draft-rescola-tls-subcerts] are expected to use delegated credentials to avoid sharing a given secret key in all Edge Servers while removing the latency introduced by LURK/TLS. Such extensions needs some modifications of the TLS Client.
This document limits the LURK/TLS extension to the following authentication methods: RSA [RFC5246], [RFC6347] ECDHE_RSA, ECDHE_ECDSA [RFC4279] with TLS1.2 or 1.1.
LURK/TLS exchanges are expected to be performed over an authenticated and encrypted channel such as TLS or IPsec. LURK/TLS message are composed of a LURK Header and a Payload as defined in Figure 1 .
LURK message are not limited to TLS-related cryptographic operations. As a result, the context or extension in which LURK exists is likely to evolve over time. This document is essentially focused on the use of LURK in the scope of TLS with the LURK/TLS extension. As to enable future extension, this document also describes generic use of LURK, common to any extension also designated as LURK.
The LURK Header is expected to be common to all future LURK extensions and carry sufficient information so the receiver can clearly identify the extension as well as the purpose of the message. These information will determine the appended Payload.
+----------------------------------+
| LURK Header |
+----------------------------------+
| |
| LURK Payload or LURK/TLS Payload |
| |
+----------------------------------+
Figure 1: LURK Message Description
In addition to the terminology defined in [I-D.mglt-lurk-tls-use-cases], this document introduces the following terminology:
enum {
lurk (0), (255)
} ExtensionDesignation;
struct {
ExtensionDesignation extension_designation;
int8 extension_version;
} Extension;
enum {
request (0), success (1), unsupported_extension (2),
unsupported_status (4), unsupported_type (5), temporary_failure (6),
error(7) (255)
} Status;
enum {
capabilities (0), ping (1), (255)
}LURKMessageType;
struct {
select(ExtensionDesignation){
case "lurk":
LURKMessageType;
}
}MessageType;
struct {
Extension extension;
Status status;
MessageType message_type;
unint32 length;
uint64 id;
} LURKHeader;
LURK Header Description
This section is focused on LURK, so the extension is set to "lurk". This document RECOMMENDS to set the extension_version to 1 as it is the only value defined. However, in order to enable extension discovery across different LURK versions, the message_type "capabilities" can be used with any extension version.
The LURK Client is only able to send requests and MUST set the status header field to "request".
Upon receiving a response, the LURK Client MUST check the extension, extension_version, message_type and id corresponds to a request that has been sent recently. How long the LURK Client should keep track of response is implementation dependent and depends on use cases. Message without corresponding request are ignored.
The LURK Server checks if the extension is supported. If the extension_designation or its associated extension_version is not supported, the LURK Server returns an "unsupported_extension" error. However, for interoperability with future extension versions when the extension_designation is set to "lurk", the LURK Server MUST ignore the extension_version if the message_type is set to "capabilities".
The LURK Server checks the message_type is both valid and supported by the LURK Server. Validity of a message_type is defined by this document while its support by a LURK Server depends on how the LURK Server has been configured. If the message_type is either not valid or not supported by the LURK Server, a "unsupported_message_type" error is returned.
The LURK Server checks the status is set to "request", otherwise the Key Server returns an "unsupported_status" error.
When the LURK Server has validated the LURK header, the LURK Server processes the request and provide a response payload as well as a status. When the returned status is "success" the response payload is the expected response, otherwise when the status reports an error. The extension, message_type and id fields of the response MUST have the same values as the corresponding request.
When overloaded, the LURK Server MAY send a temporary_failure error to indicate its inability to treat the request.
When another error occurs, the status is set to "error".
A LURK "capabilities" request has no payload.
The "capabilities" response payload consists in a list of the supported extensions and extension_versions.
struct {
LURKSupportedExtension lists_of_supported_extensions<2..2^16-2>;
opaque lurk_state<32>;
}LURKCapabilitiesResponsePayload;
LURK Capability Payload Description
extension is defined in Section 4.1
The LURK Client sends a "capabilities" request in a "lurk" extension to discover the various extensions and versions supported by the LURK Server.
The LURK Server lists the supported extensions and version the requester is authorized to request and sends the response.
A LURK "ping" request has no payload.
A LURK "ping" response has no payload.
The LURK Client sends a "ping" request to test the reachability of the LURK Server. The reachability is performed within a LURK relation.
The LURK Server sends the corresponding response.
The error code is indicated by the status when its value differs from "request" or "success".
Error message MAY have no Payload. Error message MAY also carry a state value that indicates a change in the configuration of the LURK Server. The state is expected to reflect any change of the configuration associated to the extension. Generation of the state is implementation dependent and out of the scope of this document. It can typically be implemented as a counter that is incremented any time the extension configuration is updated, or as the hash function of the configuration file.
Upon reception of the state, if the LURK Client has stored the previous value, it is expected to compare the two values. A mismatch indicates that extension configuration change and the LURK Client SHOULD perform a LURK extension discovery with a "capabilities" request. If the two values matches a extension discovery SHOULD NOT be performed. The absence of ErrorPayload is considered as a mismatch.
struct {
opaque lurk_state<32> ;
}ErrorPayload;
Error Payload Description
The LURK/TLS extends LURK in a TLS context. This document extends the ExtensionDesignation structure to LURK/TLS by adding a "tls" designation with an associated extension_version set to 1. Similarly it extends MessageType structure with LURKTLSMessageType.
enum {
tls(1), (255)
} ExtensionDesignation;
enum {
capabilities (0), ping (1), rsa_master (2), rsa_extended_master (3),
rsa_master_with_pfs (4), echde (5), ecdhe_with_pfs (6),
ecdhe_with_poo (7), ecdhe_with_pfs_poo (8), (255)
}LURKTLSMessageType;
struct {
select(ExtensionDesignation){
case "tls":
LURKTLSMessageType;
}
}MessageType;
LURK/TLS Message Header
When sending a request, the LURK Client MUST set extension to "tls", extension_version to "1" and status to "request".
Reception of the response is handled as described in Section 4.1.
The LURK Server proceeds as described in Section 4.1.
A LURK "capabilities" request has no payload.
The "capabilities" response payload consists in a list of LURK/TLS Capabilities. A LURK/TLS Capability groups the supported message types, certificates and Signature and hash algorithms that are compatible. A LURKTLSCapability is defines such as any combination of any list member is compatible.
struct {
MessageType list_of_message_type<2..2^16-2>;
Certificates list_of_certificates<2..2^26-2>;
// RFC5246 section 7.4.2
SignatureAndHashAlgorithm list_of_algo<2..2^16-2>;
// RFC5246 section 7.4.1.4.1
} LURKTLSCapability;
struct {
LURKTLSCapability lists_of_capability<2..2^16-2>;
opaque state<32>;
}LURKCapabilitiesResponsePayload;
LURK Capability Payload Description
extension is defined in Section 4.1
The LURK Client is expected to perform a capability request in order to determine the possible operations. Note that Capabilities are indicative.
The LURK Client is expected to keep the state value to be able to detect a change in the LURK Server configuration when an error occurs.
The capabilities are defined by the LURK Server from its configuration file.
A LURK/TLS "ping" request has no payload.
A LURK/TLS "ping" response has no payload.
The LURK Client sends a "ping" request to test the reachability of the LURK Server. The reachability is performed within a LURK/TLS relation.
The LURK Server sends the corresponding response.
enum {
sha256_32 (0), (255)
}KeyPairIdType;
struct {
KeyPairIdType type;
opaque data; // length defined by the type
} KeyPairID;
struct {
KeyPairID key_id;
Random client_random; // see RFC5246 section 7.4.1.2
Random server_random;
ProtocolVersion tls_version; // see RFC5246 section 6.2.1
}LURKTLSBase;
struct {
LURKTLSBase base;
PRFAlgorithm master_prf; // see RFC5246 section 6.1
EncryptedPreMasterSecret pre_master; // see RFC5246 section 7.4.7.1
// Length depends on the key.
} LURKTLSRSAMasterRequestPayload;
rsa_master request payload description
The Response Payload corresponds to the master secret.
struct {
opaque master[0..47];
} LURKTLSRSAMasterResponsePayload;
LURK TLS RSA Master Secret Description
rsa_master extends the Status structure with the following error codes:
enum {
unvalid_key_pair_id_format (128), unvalid_key_pair_id (129),
unvalid_encrypted_master_length (130) unvalid_prf (131),
unvalid_tls_version (131), unvalid_payload_format (132), (255)
} Status;
A rsa_master request is sent so the LURK Server can derive the master secret used by the TLS session. Upon receipt of the master_secret the Edge Server can generate the session keys and finish the TLS key exchange protocol.
Upon receipt of a rsa_master request, the LURK Server proceeds according to the following steps:
struct{
KeyPairID key_id
ProtocolVersion tls_version // see RFC5246 section 6.2.1
PRFAlgorithm master_prf // see RFC5246 section 6.1
EncryptedPreMasterSecret pre_master // see RFC5246 section 7.4.7.1
opaque session_hash<2...2^16-2>
}LURKTLSExtendedMasterRSARequestPayload;
rsa_extended_master request payload
rsa_extended_master response payload has a similar structure as the rsa_master response payload Section 5.4.2.
A rsa_extended_master request is sent so the LURK Server can derive the master secret used by the TLS session. Upon receipt of the master_secret the Edge Server can generate the session keys and finish the TLS key exchange protocol.
The LURK Server proceeds as described in Section 5.4.4 except that the generation of the extended master is processed as described in [RFC7627].
struct {
LURKTLSBase base;
ServerECDHParams ecdhe_params; // RFC4492 section 5.4
} LURKTLSECDHERequestPayload;
ecdhe request payload Description
struct {
Signature signed_params; // RFC4492 section 5.4
} LURKTLSECDHEResponsePayloads;
The LURK Client sends an ecdhe request so the LURK Server signs the ecdhe_params. The LURK Client expects to receive a signature, and upon receiving the signature, the LURK Client SHOULD validate the signature. If the signature does not match an error SHOULD be reported.
"ecdhe" extends the Status structure with the following error codes:
enum {
unsupported_ec_type (133), unsupported_ec_basistype (134),
unsupported_ec_curve (135), unsupported_ec_point_format (136), (255)
}Status;
Upon receiving an ecdhe request, the LURK Server proceeds as follows:
enum {
sha256(0), (255);
}PFSprf;
struct {
PFSprf pfs_prf;
}PFSRequest;
with_pfs request payload description
This option has no associated response Payload.
A message type with "with_pfs" indicated the Perfect Forward Secrecy payload MUST be append to the LURK/TLS request payload. This document considers that rsa_master and ecdhe can set this option.
The LURK Client set the pfs option in order to avoid that an attacker monitoring a TLS key exchange between the TLS Client and the Edge Server is able to send the appropriated request to the LURK Server. More specifically, this option builds the server_random with a hash function. An attacker monitoring the TLS key exchange will not be able to compute the input that generates the server_random, and as such will not be able to send a corresponding request to the LURK Server.
This option can be used with any request payload that carry a server_random field.
When this option is set, the value in the LURK/TLS Payload server_random MUST NOT be used as the value for the server.Hello.random. Instead the value of the server_random field is used as a seed to generate the value used for server.Hello.random to generate the (extended) master secrets or the signature of the ecdhe_params.
The seed MUST follow the Random structure defined in [RFC5246] section 7.4.1.2 which carry the gmt_unix_time in the first four bytes. The ServerHello.random value is generated from the seed as follows:
gmt_unix_time = seed[0..3];
server_random = PRF(seed + "lurk/tls pfs option"
+ PRF(lurk_tls_header));
server_random[0..3] = gmt_unix_time;
Generating ServerHello.random from seed
"with_pfs" extends the Status structure with the following error codes:
enum {
unsupported_pfs_prf (137), (255)
} Status;
When the server receives a message type set with "with_pfs", the LURK Server proceeds as follows:
enum {
sha256_128(0), sha256_256(1), (255)
}PFSprf
struct {
PooPRF poo_prf;
ECPoint rG; //RFC4492 section 5.4
ECPoint tG;
} OptionPooRequest;
Option Request Payload Description
There is no response payload associated to this option.
A message type with "with_poo" indicated the LURK Client adds a Proof of Ownership of the private part of the public ECDH key provided. This option is intended to prevent the LURK Server to sign bytes that do not correspond to a ECDHE public key.
The "with_poo" option is only valid associated to an ecdhe main payload. With the message type ecdhe_with_poo, the poo payload is directly appended to the ecdhe payload. with the message type "ecdhe_with_pfs_poo" the poo payload is appended to the ecdhe_with_pfs payload.
The LURK Client computes t = cb + r and sends rG, tG, c, bG. The values rG, tG and c are sent in the poo option while bG is sent in the ServerECDHParams structure of the LURKTLSECDHERequestPayload Section 5.6.
Note r and c may be treated as “very short-term secrets” but MUST remain non-predictable. It is RECOMMENDED to use a length equivalent to the expected level of security, that is 128 bit length (resp. 256 bit length) for a 128 (resp 256) bit security level. Given b, we RECOMMEND r and c to be at least half the size of b.
"with_poo" extends the Status structure with the following error codes:
enum {
unsupported_poo_prf (138), unvalid_poo (139), (255)
} Status;
When the server receives a message type set with "with_pfs", the LURK Server proceeds as follows:
This section provides security considerations regarding the LURK protocol as well as the trust model.
LURK defines a protocol where the Edge Server terminates the TLS session while it does not host the private key. ,As a result, the TLS Client does not authenticate the Edge Server itself but instead it authenticates the Key Server on behalf of the Edge Server. The standard TLS trust model has these two functions co-hosted into the TLS Server. As a result, in order to rely on the standard TLS trust model, the communication between the LURK Server and the LURK Client MUST be secured and trusted. This document RECOMMENDS that LURK messages are exchanged over an authenticated and encrypted channel protected with IPsec or TLS. Trust is is enforced by setting LURK sessions with trusted Edge Servers as well as by mechanisms such pfs or poo, to limit the possibilities of unlegitimate request.
As described in [I-D.mglt-lurk-tls-use-cases], the main advantage of this model is that it prevents the private keys to be hosted on multiple domains or Edge Servers, exposed on the Internet and thus presenting a consequent risks of leaking the private key. As a result, this architecture provides a higher control on the private key. In addition, it also enable to better monitor the key usage, and as such may better detect any distributed attacks
The disadvantage of this architecture is that the Key Servers represent a bottle neck and thus MUST remain available.
LURK message can be carried over UDP, and some responses can present significant larger response payloads than the request payloads. As a result when non authenticated, LURK could be used for reflection attacks. When used over UDP or any session-less transport layers, we RECOMMEND the communication to be authenticated, to prevent an attacker to use the LURK Server as a reflector.
The LURK/TLS capabilities requests can present a high ratio of payload size, however, this request is not triggered by the TLS Client but is only used for management purpose by the Edge Server. If a compromised Edge Server uses this request to perform an attack, the LURK Server SHOULD be able to delay the treatment, and SHOULD be able to respond with a "temporary_failure" error.
In order to avoid that the LURK Server operation are being used outside the extension of LURK, the LURK Server includes specific context in the pfs option.
With a LURK architecture, the RSA private key is expected to be hosted on a restricted number of Key Servers and these Key Servers are expected to be less exposed to attacks than Edge Servers. As a result, the LURK architecture reduces the leak of RSA private key. Such property is especially important as TLS session authenticated with RSA are not Perfect Forward Secured (PFS). In addition, the Key Server provides the master secret and the premaster secret remains unknown to the Edge Server. This makes recovery of the private key harder as even a compromised Edge Server will not be able to perform cryptanalysis attacks based on the encrypted and corresponding clear text.
On the other hand, the LURK architecture may present weakness against perfect forward secrecy. An attacker observing a standard TLS1.2 key exchange using an RSA authentication is not able to replay the session. In fact, the TLS server is active in the key exchange. It provides a random number that makes each session unique with a high probability. This is not anymore the case with the LURK architecture where the Edge Server provides with "rsa_master" and "rsa_extended_master" all the necessary parameters to generate the master secret. As a result, an attacker that observes a TLS key exchange and that gain access to the Key Server will be able to recompute the master secret. "rsa_master_with_pfs" address this concern and prevent an attacker to replay a request. An attacker observing the TLS key exchange will observe as the hash of a number as the secret server while the number is provided to the Key Server to generate the secret number. The attacker is unlikely to replay the request unless it can reverse the hash function.
As PFS issues are inherent to RSA we RECOMMEND the Edge Server to use other authentication methods such as ECDHE when possible. When RSA needs to be used, we RECOMMEND to use "rsa_master_pfs" and to have "rsa_master" deactivated. The current document does not provide PFS protection for rsa_extended_master".
Note that having the Key Server generating the server random on its own without any input from the Edge Server would also achieve the PFS in a similar way as standard TLS does. The pfs options achieves similar properties while enabling a LURK Client to replay a request.
The Standard TLS1.2 is robust against Bleichenbacher attack as it provides no means to detect if the error comes from a TLS version mismatch or from the premaster format. This properties remain with LURK, and so LURK does not present vulnerabilities toward Bleichenbacher attack, and cannot be used as a decryption oracle.
The LURK Server signs ECDH parameters and as such a LURK Server deploying ecdhe may appear as as a signing oracle for the specific string:
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
Note that an attacker willing to sign a specific string, needs to find the randoms values and ECDH parameters such that SHA result in a collision. Even tough this problem does not seem an easy problem, the current document address this issue by reducing the LURK Client latitude to chose the parameters values. First, the pfs option prevents the LURK Client to specify the server random. The pfs option use a safe hash function. In addition, the poo option proves the ownership of the private counter part of the public parameters. Such option limits the values provided as the ECDH parameters to effectively working parameters rather than random byte that match the ECDH format.
We would like to thank for their very useful feed backs: Yaron Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric Rescola Mat Naslung, Rich Salz. Many ideas in this document are from [I-D.erb-lurk-rsalg].
We would also like to thank those that have supported LURK or raised interesting discussions. This includes among others Robert Skog, Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin, Yaron Sheffer, Richard Brunner, Stephane Dault, Dan Kahn Gillmor, Joe Hildebrand, Kelsey Cairns.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4279] | Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005. |
| [RFC4492] | Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C. and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC6347] | Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012. |
| [RFC7627] | Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, A. and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015. |
| [I-D.mglt-lurk-tls-use-cases] | Migault, D., Ma, K., Salz, R., Mishra, S. and O. Dios, "LURK TLS/DTLS Use Cases", Internet-Draft draft-mglt-lurk-tls-use-cases-02, June 2016. |
| [I-D.erb-lurk-rsalg] | Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", Internet-Draft draft-erb-lurk-rsalg-01, May 2016. |
TLS Client Edge Server Key Server
ClientHello
server_version
client_random
cipher_suite
TLS_RSA_*, ...
-------->
ServerHello
tls_version
server_random
Cipher_suite=TLS_RSA
Certificate
RSA Public Key
ServerHelloDone
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLS Request Header
LURKTLSMasterRSARequestPayload
key_id
client_random
edge_server_random
tls_version
master_prf
EncryptedPremasterSecret
-------->
1. Computing Master Secret
master_secret = master_prf(\
pre_master_secret + "master secret" +\
client_random +\
edge_server_random)[0..47];
LURKTLS Response Header
LURKTLSMasterResponsePayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
TLS Client Edge Server Key Server
ClientHello
tls_version
cipher_suite
TLS_RSA_*, ...
Extension 0x0017
-------->
ServerHello
edge_server_version
cipher_suite=TLS_RSA
Extension 0x0017
Certificate
RSA Public Key
ServerHelloDone
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLS Request Header
LURKTLSExtendedMasterRSAInputPayload
key_id
tls_version
master_prf
session_hash
EncryptedPreMasterSecret
-------->
1. Computing Master Secret
master_secret = master_prf(
pre_master_secret +\
"extended master secret" +\
session_hash)[0..47]
LURKTLS Response Header
LURKTLSMasterPayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
TLS Client Edge Server Key Server
ClientHello
tls_version
client_random
cipher_suite
TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
Extension Supported EC, Supported Point Format
-------->
LURKTLS Request Header
LURKTLSECDHEInputPayload
key_id
client_random
edge_server_random
tls_version
ecdhe_params
-------->
1. Generating the signature
signature = ECDSA(client_random +\
edge_server_random + echde_params)
LURKTLS Response Header
LURKTLSDigitallySignedPayloads
signature
<--------
ServerHello
edge_server_version
edge_server_random
Cipher_suite=TLS_ECDHE_ECDSA
Extension Supported EC, Supported Point Format
Certificate
ECDSA Public Key
ServerKeyExchange
ecdhe_params
signature
ServerHelloDone
<--------
ClientKeyExchange
[ChangeCipherSpec]
Finished
-------->
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
TLS Client Edge Server Key Server
ClientHello
server_version
client_random
cipher_suite
TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
Extension Supported EC, Supported Point Format
-------->
LURKTLS Header (Query)
LURKTLSECDHEInputPayload
key_id
client_random
edge_server_random
version
signature_scheme
ecdhe_params
prf
-------->
1. Generates a random nonce
2. Compute modified edge_server_random
modified_server_random = \
prf(padding + context +\
zero-byte + edge_server_random +\
once)[32]
3. Generate the signature
signature = ECDSA(client_random +\
modified_server_random + echde_params)
LURKTLS Header (Response)
LURKTLSDigitallySignedPayloads
signature
mofified_edge_server_random
<--------
ServerHello
edge_server_version
modified_edge_server_random
cipher_suite=TLS_ECDHE_ECDSA
Extension Supported EC, Supported Point Format
Certificate
ECDSA Public Key
ServerKeyExchange
ecdhe_params
signature
ServerHelloDone
<--------
ClientKeyExchange
[ChangeCipherSpec]
Finished
-------->
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data