draft-thatcher-dhe-over-signaling.md~

---
title: "DHE over signaling"
abbrev: NO-DTLS
docname: draft-thatcher-dhe-over-signaling-latest
date: {DATE}
category: info

ipr: trust200902
area: General
submissionType: IETF
workgroup: Independent Submission
keyword: Internet-Draft

stand_alone: yes
smart_quotes: no
pi: [toc, sortrefs, symrefs, docmapping]

author:
  -
    ins: P. Thatcher
    name: Peter Thatcher
    organization: Microsoft
    email: pthatcher@microsoft.com

--- abstract

This document proposes how two peers can do a Diffie-Helman Exchange over signaling to avoid round trips.
For example, WebRTC peers can create DTLS and DTLS-SRTP keys without the need for doing
a Diffie-Helman Exchange via DTLS round trips.

--- middle


# Introduction

WebRTC uses DTLS for data channels and DTLS-SRTP to negotiate SRTP keys.
This requires a DTLS handshake, which requires extra round trips.
Can we have avoid these roundtrips by doing a Diffie-Helman Exchange over signaling.
We can also use these technique for other protocols that do a Diffie-Helman Exchange
after doing signaling, such as if endpoints do QUIC p2p.

# Using out-of-band signaling (no SDP)

Endpoints that implement this technique send the following pieces of information over signaling:

1. DHE algorithm
2. DHE public key
3. HKDF salt
4. HKDF info fragment
5. Which endpoint is "first"
6. SRTP profile (if needed for SRTP)

If these pieces of information are signaling from both sides,
then the endpoints use a Diffie-Helman exchange followed by an HDKF expansion
to generate the master key material for DTLS (or QUIC or other protocol).
The endpoints must agree on a single value for, the DHE algorithm, the HKDF salt,
which endpoint is "first", and the SRTP profile (if needed for SRTP).
Each endpoint will have its own value for the DHE Public Key and HKDF info fragment.

# Using SDP

In an SDP offer, an endpoint can add any number of lines in the following format:

```
a=dhe-hkdf DHE_ALGORITHM:DHE_PUBLIC_KEY:HKDF_SALT:HKDF_INFO_FRAGMENT
```

In and SDP answer, an endpoint can add one such line with a matching DHE_ALGORITHM, HKDF_SALT.
But it will use its own value for DHE_PUBLIC_KEY and HKDK_INFO_FRAGMENT.
The endpoint sending the SDP offer is considered "first".

DHE_PUBLIC_KEY, HKDF_INFO_FRAMENT, and HKDF_SALT are hex-encoded byte strings.
DHE_ALGORITHM is an ASCII string, such as "X25519",
and SRTP_PROFILE is an ASCII string such as "AEAD_AES_256_GCM".
HKDF_INFO_FRAMENT and HKDF_SALT can be empty. 

An SDP offer MUST NOT have multiple a=dhe-hkdf lines that differ only by HKDF_INFO_FRAGMENT.


# Generating keys from DHE and HKDF

Assuming that values have been signaled from each endpoint, each endpoint should have the following pieces of information:

- A shared DHE algorithm
- A local DHE secret
- A remote DHE public key
- Which endoint is "first" and which is "second"
- A "first" HKDF info fragment (the HKDF info fragment of the "first" endpoint)
- A "second" HKDF info fragment (the HKDF info fragment of the "second" endpoint)

Using these, each endpoint derives keys in the following way:

1. Derive a shared secret using the DHE algorithm with the local DHE secret and remote DHE public key.
2. Create a shared HKDF info by concatentating the first HKDF info framgent and the second HKDF info fragment.
3. Expand the shared secret by doing an HKDF expansion using the shared secret, the HKDF salt, and shared HKDF info.


# Contributors
{:numbered="false"}

- Peter Thatcher