<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-rescorla-dtls-in-sdp-01" category="info">

  <front>
    <title abbrev="DTLS in SDP">Piggybacked DTLS Handshakes in SDP</title>

    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>RTFM, Inc.</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date year="2016" month="October" day="31"/>

    <area>General</area>
    <workgroup>RTCWEB WG</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a mechanism for embedding DTLS handshake
messages in SDP descriptions. This technique allows implementations
to shave a full round-trip off of DTLS-SRTP session establishment,
while retaining compatibility with ordinary DTLS-SRTP endpoints.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>DTLS-SRTP <xref target="RFC5763"/><xref target="RFC5763"/> uses
a DTLS <xref target="RFC6347"/> handshake to establish keys which
are then used to key SRTP <xref target="RFC3711"/>. The DTLS
negotiation is tied to the offer/answer <xref target="RFC3264"/>
transaction via an “a=fingerprint” attribute
<xref target="RFC4572"/> in the SDP <xref target="RFC4566"/>. The
common message flow is shown below for DTLS 1.2.</t>

<t>This figure and the rest of this document adopt the following
assumptions about network behavior:</t>

<t><list style="symbols">
  <t>ICE <xref target="RFC5245"/> is in use but that both endpoints
implement endpoint-independent filtering <xref target="RFC5389"/> so
that STUN checks succeed immediately.</t>
  <t>Signaling messages take the same time to be delivered
as direct messages [this is generally false.]</t>
</list></t>

<t>Links to detailed diagrams with a more accurate vertical scale can
be found below each diagram.</t>

<figure title="Standard DTLS-SRTP Negotiation" anchor="ordinary-dtls"><artwork><![CDATA[
    Alice                 Signaling Service                 Bob
    -----------------------------------------------------------  
^   Offer + fingerprint  --------->
|                                 Offer + fingerprint -------->  ^  
|                                                                |
|                                 <------  Answer + fingerprint  |
|   <--------  Answer + fingerprint                              |
|   <------------------------------------------------- STUN-REQ  |
|   STUN-REQ ------------------------------------------------->  |
|   STUN-RESP------------------------------------------------->  |
|   <---------------------------------------------  ClientHello  |
|   <------------------------------------------------ STUN-RESP  |
4                                                                |
R   ServerHello                                                  |
T   ServerKeyExchange                                            |
T   Certificate                                                  3
|   CertificateRequest                                           R
|   ServerHelloDone  ----------------------------------------->  T
|                                                                T
|                                             ClientKeyExchange  |
|                                                   Certificate  |
|                                             CertificateVerify  |
|                                            [ChangeCipherSpec]  |
|   <------------------------------------------------  Finished  |
|                                                                |
|   [ChangeCipherSpec]                                           |
|   Finished ------------------------------------------------->  |
|   Media ---------------------------------------------------->  v
v   <------------------------ Media----------------------------
]]></artwork></figure>

<t><eref target="https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/normal-12.png">Better picture</eref></t>

<t>In this flow, the earliest that Alice can start sending media is
after receiving Bob’s Finished and the earliest Bob can start
sending media is upon receiving Alice’s Finished, and neither
side can send any DTLS messages until they have had a successful
STUN check. The result is that in the best case, Alice receives
media four round trips after sending the offer and Bob receives
media three round trips after receiving Alice’s offer.</t>

<t>This document describes a technique for improving call setup time by
piggybacking the first round of DTLS messages on the signaling
messages. This reduces latency by a full round trip for both DTLS 1.2
and DTLS 1.3 handshakes, and for DTLS 1.3 <xref target="I-D.ietf-tls-tls13"/>
allows the answerer to start sending media
immediately upon receiving the offer, or, if ICE is used, upon ICE
completion.</t>

</section>
<section anchor="protocol-overview" title="Protocol Overview">

<t>The basic concept, as shown in <xref target="piggybacked-dtls12"/>, is for
Alice to send her ClientHello in her Offer and Bob to send
the server’s first flight (ServerHello…ServerHelloDone for DTLS
1.2) in his Answer.</t>

<section anchor="dtls-12" title="DTLS 1.2">

<figure title="Piggybacked DTLS-SRTP Negotiation (TLS 1.2)" anchor="piggybacked-dtls12"><artwork><![CDATA[
    Alice                 Signaling Service                 Bob
    -----------------------------------------------------------
^   Offer
|    + fingerprint
|    + ClientHello      --------->
|                                 Offer
|                                  + fingerprint
|                                  + ClientHello  ------------>  ^
|                                                                |
|                                                        Answer  |
|                                                 + fingerprint  |
|                                                 + ServerHello  |
|                                           + ServerKeyExchange  |
|                                                 + Certificate  |
|                                          + CertificateRequest  |
|                                <------------  ServerHelloDone  |
3                                                                |
T                           Answer                               2
T                    + fingerprint                               R
T                    + ServerHello                               T
|              + ServerKeyExchange                               T
|                    + Certificate                               |
|             + CertificateRequest                               |
|   <------------  ServerHelloDone                               |
|   <------------------------------------------------  STUN-REQ  |
|   STUN-REQ ------------------------------------------------->  |
|   STUN-RESP------------------------------------------------->  |
|   <------------------------------------------------ STUN-RESP  |
|   ClientKeyExchange                                            |
|   Certificate                                                  |
|   CertificateVerify                                            |
|   [ChangeCipherSpec]                                           |
|   Finished ------------------------------------------------->  v
|   Media ---------------------------------------------------->
|                                            [ChangeCipherSpec]
|   <------------------------------------------------  Finished
v   <---------------------------------------------------  Media
]]></artwork></figure>

<t><eref target="https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/piggybacked-12.png">Better picture</eref></t>

<t>Note that in this flow, the active/passive (DTLS client/server) roles
are reversed and Alice becomes the client. Because this is a basically
symmetrical transaction, this is not an issue.</t>

<t>It should be immediately apparent that this exchange shaves off a full
round trip from Bob’s perspective (despite actually only shaving a
half a round trip from the number of messages). The reason is that Bob
does not need to wait for Alice’s Finished to send but can piggyback
his data on his Finished.</t>

<t>This change also shaves off a round trip from Alice’s perspective
because Alice can now safely perform TLS False Start
<xref target="I-D.ietf-tls-falsestart"/> and send traffic prior to receiving Bob’s
Finished message. When only fingerprints are carried in the handshake,
then extensions such as <xref target="RFC7301"/> indicators and DTLS-SRTP
negotiation are not protected. However, in this case because those
indicators are carried in the hello messages which are now tied to the
signaling channel, they are authenticated via the same mechanisms
that authenticate the fingerprint.</t>

<t>Note: One could argue that under some conditions Bob could do
False Start in the ordinary handshake, but it’s much harder to
analyze and even then it leaves Alice one round trip slower than
she would be with this optimization.</t>

</section>
<section anchor="dtls-13" title="DTLS 1.3">

<t>Figure <xref target="piggybacked-dtls13"/> shows the impact of this optimization
on DTLS 1.3.</t>

<figure title="Piggybacked DTLS-SRTP Negotiation (TLS 1.3)" anchor="piggybacked-dtls13"><artwork><![CDATA[
    Alice                 Signaling Service                 Bob
    -----------------------------------------------------------
^   Offer
|    + fingerprint
|    + ClientHello      --------->
|                                 Offer
|                                  + fingerprint
|                                  + ClientHello  ------------>  ^
|                                                                |
|                                                        Answer  |
|                                                 + fingerprint  |
|                                                 + ServerHello  |
|                                          + CertificateRequest  |
|                                                 + Certificate  |
|                                           + CertificateVerify  |
|                                <-------------------  Finished  |
|                           Answer                               |
3                    + fingerprint                               |
R                    + ServerHello                               2
T             + CertificateRequest                               R
T                    + Certificate                               T
|              + CertificateVerify                               T
|   <-------------------  Finished                               |
|   <------------------------------------------------  STUN-REQ  |
|   STUN-REQ ------------------------------------------------->  |
|   STUN-RESP------------------------------------------------->  |
|   <------------------------------------------------ STUN-RESP  |
|                                                                |   
|   ClientKeyExchange                                            |
|   Certificate                                                  |
|   CertificateVerify                                            |
|   [ChangeCipherSpec]                                           |
|   Finished ------------------------------------------------->  |
|   Media ---------------------------------------------------->  v
|                                            [ChangeCipherSpec]
|   <------------------------------------------------  Finished
v   <---------------------------------------------------  Media
]]></artwork></figure>

<t><eref target="https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/piggybacked-13.png">Better picture</eref></t>

<t>Alice cannot send any sooner than with DTLS 1.2
because sending at the point when she receives Bob’s first
message is already optimal. It may be possible
for Bob to shave off yet another
round trip, however. As described in <xref target="server-false-start"/>.</t>

</section>
</section>
<section anchor="attribute-definition" title="Attribute Definition">

<t>This document defines a new media-level SDP attribute, “a=dtls-message”.
This message is used to contain DTLS messages. The syntax of this attribute
is:</t>

<figure><artwork><![CDATA[
attribute               =/   dtls-message-attribute

dtls-message-attribute  =    "dtls-message" ":" role SP value

role                    =    "client" / "server"

value                   =    1*(ALPHA / DIGIT / "+" / "/" / "=" )
                             ; base64 encoded message
]]></artwork></figure>

<t>An offeror which wishes to use the optimization defined in this document
shall send his ClientHello in the “a=dtls-message” attribute of its
initial offer with the role “client” and MUST use “a=setup:actpass”. This allows the peer to
either:</t>

<t><list style="symbols">
  <t>Reject the optimization, in which case it ignores the attribute.</t>
  <t>Accept the optimization, in which case it MUST use “a=setup:passive”
and send its first flight (starting with ServerHello) and using
the role “server” in its response. These messages are simply serialized
end-to-end as they would be on the wire. It MAY also choose to 
send its first flight separately in the media channel; DTLS implementations
already handle retransmits properly.</t>
</list></t>

<t>The offerer MUST be able to detect whether an incoming DTLS message
is a ClientHello or a ServerHello and adapt accordingly.</t>

<t>In subsequent negotiations, implementations MUST maintain these
roles.</t>

</section>
<section anchor="interactions" title="Interactions">

<t>This optimization has a number of interactions with existing pieces of
protocol machinery.</t>

<section anchor="ice" title="ICE">

<t>When ICE is in use, there is a race condition between the answerer’s
ICE checks (at which point it will be able to send the first flight on
the media channel) and the answerer’s Answer, which contains the first
flight. For this reason, we allow implementations to send the first
flight on both channels. However, as a practical matter it is
reasonably likely that when ICE is in use the Answer will arrive
first, for two reasons:</t>

<t><list style="symbols">
  <t>The answerer consumes a full RTT doing a STUN check to verify
the path to the offerer (even in the best case where the
first STUN check succeeds). Thus, even if the path through
the signaling server is twice as expensive as the direct path,
there is a reasonable chance that the answer will arrive first.</t>
  <t>If the offerer is behind a NAT without endpoint-independent
filtering, the answerer’s ICE checks will be discarded until the
offerer sends its own ICE checks, which it can only do upon receiving
the answer.</t>
</list></t>

<t>In this case, although a comparison of <xref target="ordinary-dtls"/> and
<xref target="piggybacked-dtls12"/> would show the ClientHello (in ordinary DTLS)
and the ServerHello (when piggybacked) as arriving at the same time,
in fact the ServerHello may arrive up to a full RTT first, but the
offerer can SEND its second flight immediately upon its STUN check
succeeding, which happens first, thus increasing the advantage of this technique.</t>

</section>
<section anchor="forking" title="Forking">

<t>This technique does not interact very well with forking. Because each
ClientHello is only usable for one server, the system must somehow ensure
that only one of the forks takes up the piggybacked offers. The
easiest approach is for any intermediary which does a fork to strip
out the “a=dtls-message” attribute. An alternative would be to add
another attribute which could be stripped out (this might interact
better with RTCWEB Identity). Note that <xref target="RFC4474"/> protects against
any SDP modifications, but I think at this point it’s clear that that’s
not practical.</t>

</section>
<section anchor="rtcweb-identity" title="RTCWEB Identity">

<t>RTCWEB Identity assertions need to cover these DTLS messages.</t>

</section>
</section>
<section anchor="examples" title="Examples">

<t>[we need examples.]</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The security implications of this technique are described throughout
this document.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This specification defines the “dtls-message” SDP attribute per the
procedures of Section 8.2.4 of <xref target="RFC4566"/>.  The required information
for the registration is included here:</t>

<figure><artwork><![CDATA[
   Contact Name:  Eric Rescorla (ekr@rftm.com)

   Attribute Name:  dtls-message

   Long Form:  dtls-message

   Type of Attribute:  session-level

   Charset Considerations:  This attribute is not subject to the charset
      attribute.

   Purpose:  This attribute carries piggybacked DTLS message.

   Appropriate Values:  This document
]]></artwork></figure>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC5763' target='http://www.rfc-editor.org/info/rfc5763'>
<front>
<title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
<author initials='J.' surname='Fischl' fullname='J. Fischl'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake.  The key exchange travels along the media path as opposed to the signaling path.  The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5763'/>
<seriesInfo name='DOI' value='10.17487/RFC5763'/>
</reference>



<reference  anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>



<reference  anchor='RFC3711' target='http://www.rfc-editor.org/info/rfc3711'>
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials='M.' surname='Baugher' fullname='M. Baugher'><organization /></author>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='M.' surname='Naslund' fullname='M. Naslund'><organization /></author>
<author initials='E.' surname='Carrara' fullname='E. Carrara'><organization /></author>
<author initials='K.' surname='Norrman' fullname='K. Norrman'><organization /></author>
<date year='2004' month='March' />
<abstract><t>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3711'/>
<seriesInfo name='DOI' value='10.17487/RFC3711'/>
</reference>



<reference  anchor='RFC3264' target='http://www.rfc-editor.org/info/rfc3264'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>
</reference>



<reference  anchor='RFC4572' target='http://www.rfc-editor.org/info/rfc4572'>
<front>
<title>Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
<author initials='J.' surname='Lennox' fullname='J. Lennox'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP).  It defines a new SDP protocol identifier, 'TCP/TLS'.  It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session.  This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.</t><t>This document extends and updates RFC 4145.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4572'/>
<seriesInfo name='DOI' value='10.17487/RFC4572'/>
</reference>



<reference  anchor='RFC4566' target='http://www.rfc-editor.org/info/rfc4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>
</reference>



<reference  anchor='RFC5245' target='http://www.rfc-editor.org/info/rfc5245'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5245'/>
<seriesInfo name='DOI' value='10.17487/RFC5245'/>
</reference>



<reference  anchor='RFC5389' target='http://www.rfc-editor.org/info/rfc5389'>
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'><organization /></author>
<author initials='P.' surname='Matthews' fullname='P. Matthews'><organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<date year='2008' month='October' />
<abstract><t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal.  It can be used by an endpoint to determine the IP address and port allocated to it by a NAT.  It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings.  STUN works with many existing NATs, and does not require any special behavior from them.</t><t>STUN is not a NAT traversal solution by itself.  Rather, it is a tool to be used in the context of a NAT traversal solution.  This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.</t><t>This document obsoletes RFC 3489.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5389'/>
<seriesInfo name='DOI' value='10.17487/RFC5389'/>
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='July' day='11' year='2016' />

<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-14.txt' />
</reference>



<reference anchor='I-D.ietf-tls-falsestart'>
<front>
<title>Transport Layer Security (TLS) False Start</title>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
    <organization />
</author>

<author initials='B' surname='Moeller' fullname='Bodo Moeller'>
    <organization />
</author>

<date month='May' day='11' year='2016' />

<abstract><t>This document specifies an optional behavior of TLS client implementations, dubbed False Start.  It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally.  A TLS False Start reduces handshake latency to one round trip.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-falsestart-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-falsestart-02.txt' />
</reference>



<reference  anchor='RFC7301' target='http://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC4474' target='http://www.rfc-editor.org/info/rfc4474'>
<front>
<title>Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<date year='2006' month='August' />
<abstract><t>The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This document defines a mechanism for securely identifying originators of SIP messages.  It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4474'/>
<seriesInfo name='DOI' value='10.17487/RFC4474'/>
</reference>



<reference anchor='I-D.thomson-avtcore-sdp-uks'>
<front>
<title>Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP)</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='October' day='9' year='2016' />

<abstract><t>Unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP) and its use with Web Real-Time Communications (WebRTC) identity assertions are described.  Simple mitigation techniques are defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-avtcore-sdp-uks-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-avtcore-sdp-uks-00.txt' />
</reference>




    </references>


<section anchor="server-false-start" title="Speculative: Server False-Start">

<t>WARNING: THE FOLLOWING SECTION HAS NOT RECEIVED ANY REAL SECURITY
REVIEW AND MAY BE A REALLY BAD IDEA.</t>

<t>It has been observed that as if Alice uses a fresh DH ephemeral, then Bob knows (because he can
trust the signaling service) that Alice’s DH ephemeral corresponds
to Alice and can therefore encrypt under the joint DH shared
secret without waiting for Alice’s CertificateVerify, as shown
in <xref target="piggybacked-dtls13-false-start"/>.</t>

<figure title="Piggybacked DTLS-SRTP Negotiation (TLS 1.3 with false start)" anchor="piggybacked-dtls13-false-start"><artwork><![CDATA[
    Alice                 Signaling Service                 Bob
    -----------------------------------------------------------
^   Offer
|    + fingerprint
|    + ClientHello      --------->
|                                 Offer
|                                  + fingerprint
|                                  + ClientHello  ------------>  ^
|                                                                |
|                                                        Answer  |
|                                                 + fingerprint  |
|                                                 + ServerHello  |
2                                          + CertificateRequest  |
R                                                 + Certificate  |
T                                           + CertificateVerify  |
T                                <-------------------  Finished  |
|                           Answer                               |
|                    + fingerprint                               |
|                    + ServerHello                               2
|             + CertificateRequest                               R
|                    + Certificate                               T
|              + CertificateVerify                               T
|   <-------------------  Finished                               |
|   <------------------------------------------------  STUN-REQ  |
|   STUN-REQ ------------------------------------------------->  |
|   STUN-RESP------------------------------------------------->  |
v   <---------------------------------------------------  Media  |
    <------------------------------------------------ STUN-RESP  |
                                                                 |   
    ClientKeyExchange                                            |
    Certificate                                                  |
    CertificateVerify                                            |
    [ChangeCipherSpec]                                           |
    Finished ------------------------------------------------->  |
    Media ---------------------------------------------------->  v
                                             [ChangeCipherSpec]
    <------------------------------------------------  Finished
]]></artwork></figure>

<t><eref target="https://raw.githubusercontent.com/ekr/dtls-in-sdp/master/piggybacked-13-falsestart.png">Better picture</eref></t>

<t>This has demonstrably inferior security properties if Alice is
using a long-term key (for key continuity or fingerprint validation), because Bob has
not yet verified that Alice controls that key and does not even
know if Alice is using a fresh DH ephemeral, if implementations
decide to adopt this optimization, they must do something hacky like
Send data immediately but generate an error if the handshake,
including a signature, does not complete within some reasonable
period (a small number of measured round trips) [Just one reason
why this is a questionable technique.]. This technique may also
complicate dealing with the issues raised in <xref target="I-D.thomson-avtcore-sdp-uks"/>.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to Cullen Jennings, Martin Thomson, and Justin Uberti for helpful
suggestions.</t>

</section>


  </back>
</rfc>

