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

Abstract

This document describes the LURK/TLS protocol between a Edge Server and a Key Server.

Status of This Memo

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 Notice

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.


Table of Contents

1. Requirements notation

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].

2. Introduction

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].

3. Terminology and Acronyms

- item :

4. Introduction

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.

5. LURK/TLS Header

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.

OPEN QUESTIONS 1):
OPEN QUESTION: CAN WE HAVE DIFFERENT HEADERS FOR QUERY AND RESPONSE ?
OPEN QUESTIONS 2):
THE DEFINITION OF THE FIRST BYTE HEADER IS NOT PROPERLY DEFINED BY THE PSEUDO CODE.

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
        

6. Reachability / Keep Alive

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.

7. Capability Discovery

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.

OPEN QUESTIONS 3):
CURRENT CAPABILITY FORMAT IS LIMITED TO THE CAPABILITIES OF THE QUERY TYPE. IN SOME CASE, THE QUERY TYPE MAY BE ASSOCIATED TO SOME ADDITIONAL PARAMETERS SUCH AS CRYPTOGRAPHIC HASH FUNCTIONS, OR ECC PARAMETERS. SHOULD THESE SUB PARAMETERS BE EMBEDDED INTO THIS REQUEST OR SHOULD WE HAVE DEDICATED REQUEST FOR THEM?
OPEN QUESTIONS 4):
CURRENT PARAMETERS THAT NEED TO BE SPECIFIED ARE PRF / ECParameters / EC Points into Capabilities.

8. Master Secret with RSA Authentication

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];
        

9. Extended Master Secret with RSA Authentication

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;
        

10. Master Secret with RSA Authentication and PFS

[I-D.erb-lurk-rsalg]

11. Signature with ECDHE Authentication

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;
        

12. Unpredictable Signature with ECDHE Authentication

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.

OPEN QUESTIONS 5):
PRIMARY PURPOSE OF USING TLS1.3 PADDING SCHEME IS TO HAVE ONE PADDING SCHEME USED ACROSS TLS VERSIONS. IS THAT REASONABLE ?

13. Security Considerations

THIS SECTION CONTAINS ROUGH NOTES. IT NEEDS TO BE RE-WRITTEN, SO ANY SUGGESTION IS WELCOME.

13.1. Threat Analysis

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.

TLS_AUTH 1:
TLS authentication information is expected to be restrained to a single TLS session.

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:

TLS_AUTH 2:
TLS authentication should not leak information associated to the Private Keys involved.
TLS_AUTH 3:
TLS authentication should involve reasonable resource.

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.

13.2. RSA

13.2.1. TLS Session Binding

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.

RECOMMENDATION 1)
Server SHOULD limit the use of RSA to TLS1.0 and greater version that do not present vulnerabilities on the RSA authentication method.
RECOMMENDATION 2)
TLS Client SHOULD NOT re-use their premaster secret.

13.2.2. Decryption Oracle

In order to prevent the Key Server to be used as an Bleichenbacher oracle

RECOMMENDATION 1)
The Key Server MUST NOT return any information associated to the encrypted content. Instead, when the encrypted data does not meet the expected format a randomly generated premaster MUST be generated and used to generate the master secret or extended master secret returned by the Key Server to the Edge Server. Currently Section 8 and Section 9 meet this requirements.
RECOMMENDATION 2)
The Key Server MUST NOT use a Private Key shared by a TLS Server implementing a vulnerable TLS version.

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:

RECOMMENDATION 3)
The Key Server MUST only use collision free PRF.

13.2.3. Illegitimate access to Key Server and PFS

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:

RECOMMENDATION 4)
In order to provide PFS [I-D.erb-lurk-rsalg] is recommended.

13.3. ECDHE

13.3.1. Cross Protocol Attacks

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.

a)
ClientHello.random makes offline more difficult to be performed. In fact, the ClientHello.random is randomly generated by the TLS Client. As a result, an attacker willing to usurpate the identity of the TLS Server, will have to generate a signature that matches the ClientHello.random. For a given TLS Session, the probability of success for a given TLS Session is 1 / 2 ** ( 32 * 8 ) = 1 / 2 ** 256, and the probability for a random TLS Session is 1 / 2 ** 128 to have a collision. This still provides a high bar for collision during offline attacks. With on-line attack, the attacker knows the values of ClientHello.random, which raises the probability of collision to 1.
b)
ServerHello.random is provided by the TLS Server which provides the signature. As a result, an attacker usurping the TLS Server identity will have the possibility to chose the ServerHello.random.
c)
Authentication credentials from different methods needs to match and to be signed by the same key. A match between DHE and ECDHE is estimated to be 1 / 2 ** 40, which presents a higher probability of collision of several order of magnitude.

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:

RECOMMENDATION 5)
Server SHOULD limit the use of ECDSA to TLS1.2.
RECOMMENDATION 6)
RSA signature SHOULD be preferred for DHE and ECDSA SHOULD be preferred for ECDHE.
RECOMMENDATION 7)
If RSA is used to sign ECDHE parameters, ECDHE parameters that could be misinterpreted as DHE parameters SHOULD be removed.

13.3.2. Signing Oracle

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.

13.4. LURKS versus standard TLS1.2

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.

a)
A compromised Edge Server does not present risk of leakage of the Private Key.
b)
A compromised Edge Server can only have access to the Key Server, and removal of the compromised Edge Server address the issue.
c)
Access to the Private Key operations are not only cryptographic operations, and when a master secret is computed, the cryptographic output may be harder to access by a potential attacker.
d)
Centralizing provides a global view of the operations performed. This may be more efficient for monitoring attacks, than monitoring them locally on the Edge Server.

On the other hand,

a)
LURK does not address attacks that rely on the TLS protocols. In other words, an attack that can be performed by a TLS Client without the standard TLS is likely to be performed with LURK. Eventually LURK will ease the detection of such attack making it harder. In addition, the fact that the Key Server interacts with authenticated Edge Server does not prevent an TLS Client to perform the attack.
b)
The Key Server provides a lighter way to perform cryptographic operation that the standard TLS. As a result, if enabled by the Key Server, an attacker having access to the Key Server will become more efficient using it, than using a standard TLS Server.
c)
LURK provides a bottle neck architecture where the Key Server is involved for any TLS Sessions.

Note that in order to take the full advanatge of the LURK/TLS,

RECOMMENDATION 8)
LURK/TLS SHOULD be used as the only way to perform operations with the Private Key. More specifically, LURK/TLS SHOULD NOT be used in combination of other deployment where the Private Key is copied on the server.

13.5. DDoS

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.

RECOMMENDATION 9)
The Key Server SHOULD control and monitor the resource associated by the Key Server to each node. The Key Server does not have any control over the requesting TLS Client and so is not able to advertise the Edge Server of an abusive TLS Client. Instead the Key Server SHOULD be able to report any detected abuse to an orchestrator that is in charge of orchestrating the mitigation either at the Edge Server level and internally, that is before the traffic reaches the Key Server.

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.

14. IANA Considerations

15. Acknowledgments

We would like to thank for their very useful feed backs: Yaron Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric Rescola.

16. References

16.1. Normative References

[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.

16.2. Normative References

[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.

Appendix A. Example of LURK Exchanges

A.1. LURK/TLS RSA Master Secret

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
        

A.2. LURK/TLS RSA Extended Master Secret

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
        

A.3. LURK/TLS ECDHE Signature

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
        

A.4. LURK/TLS/sECDHE Unpredictable

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
        

Author's Address

Daniel Migault (editor) Ericsson 8400 boulevard Decarie Montreal, QC , H4P 2N2 Canada Phone: +1 514-452-2160 EMail: daniel.migault@ericsson.com