| LURK WG | D. Migault, Ed. |
| Internet-Draft | Ericsson |
| Intended status: Informational | July 8, 2016 |
| Expires: January 9, 2017 |
LURK Protocol for TLS/DTLS1.2 version 1.0
draft-mglt-lurk-tls-00
This document describes the LURK/TLS protocol between a Edge Server and a Key Server.
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 January 9, 2017.
Copyright (c) 2016 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 LURK/TLS protocol between an Edge Server and a Key Server. The LURK/TLS protocol is designed to address the use cases as well as fulfill the requirements presented in [I-D.mglt-lurk-tls-use-cases].
This document limits the scope LURK/TLS to the following authentication methods: RSA [RFC5246], [RFC6347] ECDHE_RSA, ECDHE_ECDSA [RFC4279] with TLS1.2 or prior versions. If other authentication methods are required, the LURK/TLS can be extended considering the analysis of [I-D.mglt-lurk-tls-requirements].
LURK/TLS defines the interactions between the Edge Server and the Key Server. In this document, the Edge Server interacts with the Key Server in order to perform the authentication phase of the TLS key exchange. This document only considers the case where the authentication methods are RSA, ECHDE_RSA or ECDHE_ECDSA. Additional authentication methods or different interactions are left for the future.
LURK/TLS is a query - response protocol.
The LURK/TLS Header contains the necessary elements to interpret the remaining payload as well as identifiers used to bind a query and a response. As the status of a response is only meaningful for response, this section defines a different header for query and response.
The first byte of the LURK/TLS header contains the query bit (q) set to 1 for a query and 0 for a response, 4 reserved bits set to zero, and three right bits used to indicate the LURK/TLS version (version). In this document, the version is set to 1. Follows the query type (qtype) that indicates the purpose of the query as well as how to interpret the remaining payload. Finally, the query identifier (id) is used to bind the query with the response.
For responses, the LURK/TLS header contains an additional field that indicates the status of the response (status).
When the Edge Server or the Key Server sends a query, the query bit MUST be set to one, the reserved bits MUST be set to zero, the version MUST be set to one, the query type MUST be one of the values indicated by the LURKTLSQueryType, and the query identifier SHOULD be randomly generated to avoid response spoofing attacks.
Upon receiving the query, the Key Server or the Edge Server ignores the reserved bits and checks the LURK/TLS version. If the version is not supported, then an "unvalid_lurk_version" error is returned. Then, it checks if the query type is supported. If the query type is unknown, an "unvalid_query_type" error is returned. In any other case, the message is treated accordingly to the query type indicated. The response header associated to a query header, is the exact copy of the query header with the query bit set to zero.
Upon receiving a response, the Key Server or the Edge Server checks the response is bound to a query by checking the id. If no binding is found, the response is ignored.
THESE ARE SOME OPEN QUESTIONS AND COMMENTS THAT SHOULD BE ADDRESSED AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
enum {
zero(0), one(1) (1)
} QueryBit
enum {
one (1), (8)
} LURKTLSVersion
enum {
ping (0), capabilities (1),
rsa_master (2), rsa_extended_master (3), pfs_rsa_master (4),
echde (5), pfs_non_predictable_ecdhe (6), (255)
}LURKTLSQueryType
enum {
success (0), unvalid_lurk_version (1),
unvalid_query_type (1) (255)
} LURKTLSResponseStatus
struct {
QueryBit q
Reserved reserved
LURKTLSVersion version
LURKTLSQueryType qtype
uint64 id;
} LURKTLSQueryHeader
struct {
LURKTLSQueryHeader qheader
LURKResponseStatus status
} LURKTLSResponseHeader
To check the reachability between the Edge Server and the Key Server, the Edge Server or the Key Server may send a LURK/TLS query with the query type "ping". Upon receiving such query, the receiver sends back a LURK/TLS response with a LURKStatusResponse set to "success", with no additional payloads.
To discover the capabilities of the Key Server, the Edge Server may request the list of query types served by the Key Server. The Edge Server sends a LURK/TLS query with the query type set to "capability". Upon receiving the query, the Key Server sends back a LURK/TLS response with a LURKStatus set to success and a LURK/TLS capability payload. The payload contains its length and an ordered list of the LURK/TLS query type supported.
struct {
opaque data<1..2**32-1>
} LURKTLSCapabilityPayload
THESE ARE SOME OPEN QUESTION AND COMMENTS THAT SHOULD BE ADDRESSED AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
This section describes how the Edge Server request the generation of a master secret, with RSA as an authentication method.
The Edge Server sends a LURK/TLS query to the Key Server with the necessary inputs to generate the master secret (LURKTLSMasterRSAInputPayload). This payload contains the length of the payload (length), the identifier of the RSA key pair (key_id), the Pseudo Random Function Algorithm to generate the master secret (master_prf), the ClientHello.random (client_random), the ServerHello.random (edge_server_random), the TLS version (client_version) of the TLS Client, the TLS version of the Edge Server (edge_server_version), and the encrypted pre master secret generated by the TLS Client (encrypted_premaster_secret).
Upon receipt of the LURKTLSMasterRSAInputPayload, the Key Server checks the RSA key pair is available (key_id). Different format can be used to identify the key pair. This document defines sha256_32 format which takes the 32 first bits of the hash of the public key using sha256. If the format of the key pair identifier is not understood, an "unvalid_keypair_id_format" error is returned. If the designated key pair is not available an "unvalid_keypair_id". With the key pair identified, the Key Server is able to check the length of the encrypted premaster secret and so the length of the payload. In case of length mismatch and "unvalid_payload_format" is returned. Note that the length can be derived from the public key, so the error only reveals public information. If the Key Server does not support the PRF, an "unvalid_prf" is returned. If the TLS version of client and the Edge Server are not equal or that the Key Server does not support the provided TLS version, an "unvalid_tls_version" error is returned.
When the inputs have been checked, the Key Server decrypts the encrypted premaster secret as described in [RFC5246] section 7.4.7.1. More specifically, when a PKCS1.5 format error is detected, or a mismatch between the TLS versions provided as input and the one indicated in the encrypted premaster secret, the Key Server returns a randomly generated master secret. If the pre master is appropriately decrypted, then the master secret is computed as described in [RFC5246] section 8.1 using the PRF, ClientHello.random, and ServerHello.random provided by the Edge Server. Finally, the Key Server returns a master secret to the Edge Server in a LURKTLSMasterPayload.
Upon receipt of the master_secret the Edge Server can generate the session keys and finish the TLS key exchange protocol.
// status error specifically mentioned in this exchange
enum {
unvalid_key_pair_id_format (3), unvalid_key_pair_id (4),
unvalid_encrypted_master_length (5) unvalid_prf (6),
unvalid_tls_version (7), unvalid_payload_format (8), (255)
} LURKTLSResponseStatus
enum {
sha256_32 (0), (255)
}KeyPairIdType
struct {
KeyPairIdType type
opaque data // length defined by the type
} KeyPairID;
struct {
unit16 length
KeyPairID key_id
PRFAlgorithm master_prf // see RFC5246 section 6.1
Random client_random // see RFC5246 section 7.4.1.2
Random edge_server_random
ProtocolVersion client_version // see RFC5246 section 6.2.1
ProtocolVersion edge_server_version
EncryptedPreMasterSecret // see RFC5246 section 7.4.7.1
// Length depends on the key.
} LURKTLSMasterRSAInputPayload
struct {
LURKTLSPayloadType master
opaque master[0..47]
} LURKTLSMasterPayload
key_id = sha256(rsa_public_key)[0..31];
This section describes how the Edge Server request the generation of an extended master secret, with RSA as an authentication method.
The Edge Server sends a LURK/TLS query to the Key Server with the necessary inputs to generate the master secret (LURKTLSExtendedMasterRSAInputPayload). This payload contains the length of the payload (length), the identifier of the RSA key pair (key_id), the PRF used to generate the extended master secret (master_prf), the PRF used to generate the session hash (session_prf), the TLS version of the TLS Client (client_version), the TLS version of the Edge Server (edge_server_version), the session hash (session_hash) and the encrypted pre master secret generated by the TLS Client (encrypted_premaster_secret).
[RFC5246] section 7.4.9 mentions that for TLS1.2, the hash function used to generate the session hash MUST be the one used in the PRF, but some cipher_suites may also define different Hash function to generate the session_hash. For that reason the PRF used to compute the session hash is explicitly provided. The session hash is generated by the Edge Server as defined in [RFC7627] section 3.
Upon receipt of the query, the Key Server checks the validity of key pair (key_id), the PRF used to generate the master secret (master_prf), the TLS versions of the TLS Client (client_version) and the TLS version of the Edge Server (edge_server_version) as described in Section 8. The Key Server checks the PRF to generate the session hash (session_prf) similarly to the PRF used to generate the master (master_prf). There is not a specific error for these two distinct PRF as we believe that when a PRF is available it will be available in both case. With the key pair identified (key_id) and the PRF of the session has (session_prf), the Key Server is able to check the length of the payload. If the length does not match, an "unvalid_payload_format" is returned.
The decryption of the encrypted premaster is performed as described in Section 8. Note that the TLS versions are only provided to check the format of the encrypted premaster.
The extended master secret is generated as described in [RFC7627] and a LURKTLSMasterPayload with the master secret.
Upon receipt of the master_secret the Edge Server can generate the session keys and finish the TLS key exchange protocol.
struct{
unit16 length
KeyPairID key_id
PRFAlgorithm master_prf // see RFC5246 section 6.1
PRFAlgorithm session_prf // see RFC5246 section 6.1
ProtocolVersion client_version // see RFC5246 section 6.2.1
ProtocolVersion edge_server_version
EncryptedPreMasterSecret // see RFC5246 section 7.4.7.1
opaque session_hash //length - length(keyid) -1
}LURKTLSExtendedMasterRSAInputPayload;
This section describes how the Edge Server request the generation of signature for ECDHE_RSA or ECDHE_ECDSA as an authentication method.
The EdgeServer provides the Key Server the information to be signed in a LURKTLSECDHEInputPayload. The payload contains the length of the inputs (length), the key pair identifier (key_id), the ClientHello.random (client_random), the ServerHello.random (edge_server_random), the TLS version (version), signature scheme which also includes the hash function (signature_scheme) and the ECDHE parameters of the Edge Server (ecdhe_params).
Upon receipt of a LURKTLSECDHEInputPayload, the Key Server, checks the key pair identifier (key_id) and the TLS version (version) as described in Section 8. The Key Server MAY perform some checks on the ECDHE parameters. If these parameters are not supported it may return an "unvalid_ecdhparams" error. If a format error is detected, an "unvalid_ecdhe_format" error may be returned.
[NOTE: We need to provide some additional details on how ECDHE params can be checked, so it does not appear as an opaque value.]
Then, the key server generates the signature as defined in [RFC4492] section 5.4.. The Key Server returns a LURKTLSDigitallySignedPayload.
The output of the Key Server has a similar structure as the Signature structure defined in [RFC4492] section 5.4.
Upon receiving the LURKTLSDigitallySignedPayload the Edge Server extracts the signature of the payload. It checks the length of the signature which is known from the signature scheme and the key. In case of length mismatch, the Edge Server reports an error and aborts the session. In some case, the Edge Server MAY check the signature before finalizing the key exchange.
// defined in TLS1.3 section 4.8.1
enum {
// RSASSA-PKCS-v1_5 algorithms
rsa_pkcs1_sha1 (0x0201),
rsa_pkcs1_sha256 (0x0401),
rsa_pkcs1_sha384 (0x0501),
rsa_pkcs1_sha512 (0x0601),
// ECDSA algorithms
ecdsa_secp256r1_sha256 (0x0403),
ecdsa_secp384r1_sha384 (0x0503),
ecdsa_secp521r1_sha512 (0x0603),
// RSASSA-PSS algorithms
rsa_pss_sha256 (0x0700),
rsa_pss_sha384 (0x0701),
rsa_pss_sha512 (0x0702),
// EdDSA algorithms
ed25519 (0x0703),
ed448 (0x0704),
// Reserved Code Points
private_use (0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
unit16 length
KeyPairID key_id
Random client_random // RFC5246 section 7.4.1.2
Random edge_server_random
ProtocolVersion version
SignatureScheme signature_scheme; // draft-ietf-tls-tls13 sec. 4.8.1
ServerECDHParams ecdhe_params // RFC4492 section 5.4
} LURKTLSECDHEInputPayload;
struct {
opaque signature<0..2^16-1>;
} LURKTLSDigitallySignedPayloads;
Section 11 describes how LURK enables a Edge Server to chose the 64 bits of the message to be signed. Although in practice the risks are limited, this section provides a mechanism that prevent the Edge Server to chose the server random. In addition, the proposed mechanism prevent an attacker to request the signature of a specific content. More specifically, upon receiving a content to be signed, the Key Server, will return the signature of a "modified" content as well as the necessary parameters to generate the modified content. The Edge Server is expected to interacts with the TLS Client based on the modified content.
When the Edge Server uses the unpredictable signature authentication, in addition to the inputs sent in the case of the traditional ECDHE signature described in Section 11, the Edge Server adds an Pseudo Random Function (prf), that will be used by the Key Server to modify the content to be signed.
The Key Server first starts checking the different arguments provided by the Edge Server similarly as described in Section 11. As the PRF (prf) is specific to this exchange, the Key Server checks it supports the PRF. If not an "unvalid_prf" error is sent. If the prf is supported, the Key Server generates a new ServerHello.random. The generation of the new ServerHello.random is built following the guide lines of Digital Signature section 4.8.1 of [I-D.ietf-tls-tls13] with a NULL encryption algorithm. The Key Server generates a random nonce (nonce) and concatenates padding, a 64 byte prefix of of octet 32, the string "ECDHE ServerHello.random", a zero byte "0", the nonce and the ServerHello.random provided by the Edge Server. The resulting string is hashed by the PRF indicated by the Edge Server, and the new value for the ServerHello.random is the first 32 bytes of that resulting hash.
The Key Server generates the signature as described in [RFC4492] section 5.4, with the new ServerHello.random.
Once the signature has been generated, the Key Server returns a LURKTLSDigitallySignedPayload as well as a LURKTLSNoncePayload.
Upon receipt of these two payloads, the Edge Server generates the ServerHello.random similarly to the Key Server. The new value for the ServerHello.random is returned by the Edge Server to the TLS Client, and the digital signature is returns as previously in the ServerKeyExchange.
struct {
LURKTLSECDHEInputPayload ecdhe_input
PRFAlgorithm prf // see RFC5246 section 6.1
} LURKTLSECDHEUnpredictableInputPayload;
padding = \
2020202020202020202020202020202020202020202020202020202020202020\
2020202020202020202020202020202020202020202020202020202020202020
context = 45 43 44 48 45 20 53 65 72 76 65 72 48 65 6c 6c
6f 2e 72 61 6e 64 6f 6d
zero-byte = 00
ServerHello.random = PRF(padding + context + zero-byte +
edge_server_random + nonce)[32]
struct {
opaque signature<0..2^16-1>;
opaque new_server_random[32]
} LURKTLSUnpredictableDigitallySignedPayloads;
THESE ARE SOME OPEN QUESTION AND COMMENTS THAT SHOULD BE ADDRESSED AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
THIS SECTION CONTAINS ROUGH NOTES. IT NEEDS TO BE RE-WRITTEN, SO ANY SUGGESTION IS WELCOME.
The TLS Server authentication provides a TLS Client a proof that it is setting a TLS session with the expected TLS Server. The scope of the provided authentication credentials is expected to be limited to the TLS session established between the TLS Client and the TLS Server.
In addition, motivations to perform illegitimate TLS session may be to perform a resource exhaustion attack on the TLS Server or to collect information leaked by the authentication method. As a result, the additional requirements for the TLS authentication should be:
A TLS session is entirely characterized by its key exchange messages. Among other characteristics, the TLS session is characterized by the ClientHello.random, the ServerHello.random, the TLS version and the TLS authentication.
With RSA, the premaster secret provided by the TLS Client and contains the TLS version used at least for TLS version 1.0 and greater. There is only a single authentication method based on RSA encryption. In addition, only the owner of the Private Key will be able to provide the same master secret as the one locally generated by the TLS Client. As a result, the master secret can hardly be re-used across different authentication methods or TLS versions which provides makes master secret some kind of resistant to cross protocol attacks.
On the other hand the master secret is not bound to all parameters of the key exchange such as the certificate for example. This exposes RSA to MiM and master secret may not be bound to a single TLS session. This vulnerability is addressed by the extended master secret.
The premaster secret may be used against a TLS version that present vulnerabilities. The premaster secret may be decrypted using this vulnerability. Although having different keys for different TLS version would prevent such protocol attack issue, certificates do not allow to specify the TLS version.
The following recommendations are intended to address cross protocol attack for RSA.
In order to prevent the Key Server to be used as an Bleichenbacher oracle
In any proposed method Section 8, Section 9 or in [I-D.erb-lurk-rsalg], the master secret or extended master secret is returned instead of the premaster secret. The hash function increases the difficulty for an attacker to perform chosen cipher text attack. In fact, a collision free hash function makes difficult to determine the pre-master secret even though randoms and session-hash can be provided to the Key Server. As a result:
An illegitimate access to a Key Server provides the attacker to send any request to the Key Server. The Key Server can be used as an oracle or to perform a single cryptographic operation. An illegitimate access to the Key Server can be performed via an Edge Server. If the attacker got control of the Edge Server that terminates the TLS Session of the TLS Client, then the attacker has a direct access to the data carried by the TLS Session. This section does not consider this case. Instead, it considers an attacker that access to the Key Server, but does not have access to the terminating Edge Server.
With the operations described in Section 8 and in Section 9, an attacker intercepting a TLS Session is able to derive the master or extended master secret by sending a single request to the Key Server. On the other hand, [I-D.erb-lurk-rsalg] uses a one-way hash that defines the ServerHello.random as hash(N). In order to retrieve the master secret, the attacker will need to derive n from hash(n). As result:
The generation of the signature of the Elliptic Curve Diffie Hellman parameters involves the ClientHello.random and the ServerHello.random, but for example the TLS version or the authentication method are not part of the signature. As a result, an attacker could provide some signed parameters associated to a different authentication method. This issue is addressed by TLS1.3 which considers a context associated to the generation of the signature.
In order to perform a cross protocol attack, a collision MUST occurs between ClientHello.random, ServerHello.random and the authentication credentials of two distinct communications. In addition, a given key and a given signature scheme must be shared by the different authentication credentials used in the two TLS Sessions.
Cross protocol attack is an issue due to the signature scheme adopted by TLS 1.2 and previous version. More specifically, the signature scheme does not enable the Key Server or TLS Server to bind a signature and authentication credentials to a given authentication method and TLS version. In order to address this issue, a signature scheme should be limited to a given authentication credential and TLS version. Possible ways include:
Section 5.8 of [RFC4492] defines the signed dayta as:
ClientHello.random + ServerHello.random +
ServerKeyExchange.ecdhe_params
The method described in Section 11 open the Key Server to a first chosen 64 byte, which is increases by 32 the first chosen 32 byte of the standard TLS. Section 12 on the other hand reduces it back to 32. In addition, Section 12 makes the signature unpredictable by generating the ServerHello.random, which reduces the efficiency of adaptive clear text signing attacks.
The main difference between LURK and the standard TLS is that with LURK the cryptographic operations associated to the authentication are performed by the Key Server instead of the TLS Server.
On the other hand,
Note that in order to take the full advanatge of the LURK/TLS,
A TLS Client or a corrupted Edge Server may be willing to perform a DoS attack by sending random strings, to make the Key Server generate some premaster or extended prematser. A DoS on the Key Server is likely to impact all Edge Servers connected to that Key Server. Although RSA and ECDHE signature have been designed with limited overhead, cryptographic operations are significantly assymetric in term of resource engaged.
Similarly, the Key Server may be used a reflector for Edge Server. More specifically, the TLS Client may attack the Edge Server via the communication between the Key Server and the Edge Server. However, message exchange between the Edge Server and the Key Server have responses that are not significantly larger than Edge Server queries. In addition, the exchange between the Edge Server and the Key Server and lighter than the one involved between the TLS Client and the Edge Server.
We would like to thank for their very useful feed backs: Yaron Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric Rescola.
| [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.mglt-lurk-tls-requirements] | Migault, D. and K. Ma, "Authentication Model and Security Requirements for the TLS/DTLS Content Provider Edge Server Split Use Case", Internet-Draft draft-mglt-lurk-tls-requirements-00, January 2016. |
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-13, May 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
ProtocolVersion server_version
Random client_random
Cipher_suite
TLS_RSA_*, ...
-------->
ServerHello
ProtocolVersion edge_server_version
Random server_random
Cipher_suite=TLS_RSA
Certificate
RSA Public Key
ServerHelloDone
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLSMasterRSAInputPayload
key_id
master_prf
client_random
edge_server_random
client_version
edge_server_version
EncryptedPremasterSecret
-------->
1. Computing Master Secret
master_secret = master_prf(\
pre_master_secret + "master secret" +\
client_random +\
edge_server_random)[0..47];
LURKTLSMasterPayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
TLS Client Edge Server Key Server
ClientHello
ProtocolVersion server_version
Cipher_suite
TLS_RSA_*, ...
Extension 0x0017
-------->
ServerHello
ProtocolVersion edge_server_version
Cipher_suite=TLS_RSA
Extension 0x0017
Certificate
RSA Public Key
ServerHelloDone
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLS Header (Query)
LURKTLSExtendedMasterRSAInputPayload
key_id
master_prf
session_prf
client_version
edge_server_version
EncryptedPreMasterSecret
session_hash
-------->
1. Computing Master Secret
master_secret = master_prf(
pre_master_secret +\
"extended master secret" +\
session_hash)[0..47]
LURKTLS Header (Response)
LURKTLSMasterPayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
TLS Client Edge Server Key Server
ClientHello
ProtocolVersion server_version
Random client_random
Cipher_suite
TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
Extension Supported EC, Supported Point Format
-------->
LURKTLS Header (Query)
LURKTLSECDHEInputPayload
key_id
client_random
server_random
version
signature_scheme
ecdhe_params
-------->
1. Generating the signature
signature = ECDSA(client_random +\
edge_server_random + echde_params)
LURKTLS Header (Response)
LURKTLSDigitallySignedPayloads
signature
<--------
ServerHello
ProtocolVersion edge_server_version
Random 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
ProtocolVersion server_version
Random 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
ProtocolVersion edge_server_version
Random 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