Script updating gh-pages from 8469522. [ci skip]

auth48/draft-ietf-sframe-enc.html

@@ -4,16 +4,14 @@
 <meta charset="utf-8">
 <meta content="Common,Latin" name="scripts">
 <meta content="initial-scale=1.0" name="viewport">
-<title>Secure Frame (SFrame)</title>
+<title>Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media</title>
 <meta content="Emad Omara" name="author">
 <meta content="Justin Uberti" name="author">
 <meta content="Sergio Garcia Murillo" name="author">
-<meta content="Richard L. Barnes" name="author">
+<meta content="Richard Barnes" name="author">
 <meta content="Youenn Fablet" name="author">
 <meta content="
-       
- 
- This document describes the Secure Frame (SFrame) end-to-end encryption and
+       This document describes the Secure Frame (SFrame) end-to-end encryption and
 authentication mechanism for media frames in a multiparty conference call, in
 which central media servers (Selective Forwarding Units or SFUs) can access the
 media metadata needed to make forwarding decisions without having access to the
@@ -1078,7 +1076,7 @@
 <div class="org">CoSMo Software</div>
 </div>
 <div class="author">
-      <div class="author-name">R. L. Barnes, <span class="editor">Ed.</span>
+      <div class="author-name">R. Barnes, <span class="editor">Ed.</span>
 </div>
 <div class="org">Cisco</div>
 </div>
@@ -1089,7 +1087,7 @@
 </dd>
 </dl>
 </div>
-<h1 id="title">Secure Frame (SFrame)</h1>
+<h1 id="title">Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media</h1>
 <section id="section-abstract">
       <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
 <p id="section-abstract-1">This document describes the Secure Frame (SFrame) end-to-end encryption and
@@ -1786,12 +1784,12 @@ <h3 id="name-sframe-header">
           <dd class="break"></dd>
 <dt id="section-4.3-6.5">Extended Counter Flag (Y, 1 bit):</dt>
           <dd style="margin-left: 1.5em" id="section-4.3-6.6">
-            <p id="section-4.3-6.6.1">Indicates if the C field contains the counter or the counter length.<a href="#section-4.3-6.6.1" class="pilcrow">¶</a></p>
+            <p id="section-4.3-6.6.1">Indicates if the C field contains the Counter or the Counter length.<a href="#section-4.3-6.6.1" class="pilcrow">¶</a></p>
 </dd>
           <dd class="break"></dd>
 <dt id="section-4.3-6.7">Counter or Counter Length (C, 3 bits):</dt>
           <dd style="margin-left: 1.5em" id="section-4.3-6.8">
-            <p id="section-4.3-6.8.1">This field contains the counter (CTR) if the Y flag is set to 0, or the counter
+            <p id="section-4.3-6.8.1">This field contains the Counter (CTR) if the Y flag is set to 0, or the counter
 length, minus one, if set to 1.<a href="#section-4.3-6.8.1" class="pilcrow">¶</a></p>
 </dd>
         <dd class="break"></dd>
@@ -1954,9 +1952,9 @@ <h4 id="name-key-selection">
 be negotiated in a way that does not make them accessible to these intermediaries.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
 <p id="section-4.4.1-3">For each known KID value, the client stores the corresponding symmetric key
 <code>base_key</code>.  For keys that can be used for encryption, the client also stores
-the next counter value CTR to be used when encrypting (initially 0).<a href="#section-4.4.1-3" class="pilcrow">¶</a></p>
+the next CTR value to be used when encrypting (initially 0).<a href="#section-4.4.1-3" class="pilcrow">¶</a></p>
 <p id="section-4.4.1-4">When encrypting a plaintext, the application specifies which KID is to be used,
-and the counter is incremented after successful encryption.  When decrypting,
+and the CTR value is incremented after successful encryption.  When decrypting,
 the <code>base_key</code> for decryption is selected from the available keys using the KID
 value in the SFrame header.<a href="#section-4.4.1-4" class="pilcrow">¶</a></p>
 <p id="section-4.4.1-5">A given <code>base_key</code> <span class="bcp14">MUST NOT</span> be used for encryption by multiple senders.  Such reuse
@@ -2018,7 +2016,7 @@ <h4 id="name-encryption">
           </h4>
 <p id="section-4.4.3-1">SFrame encryption uses the AEAD encryption algorithm for the cipher suite in use.
 The key for the encryption is the <code>sframe_key</code>.  The nonce is formed by first XORing
-the <code>sframe_salt</code> with the current counter, and then encoding the result as a big-endian integer of
+the <code>sframe_salt</code> with the current CTR value, and then encoding the result as a big-endian integer of
 length <code>AEAD.Nn</code>.<a href="#section-4.4.3-1" class="pilcrow">¶</a></p>
 <p id="section-4.4.3-2">The encryptor forms an SFrame header using the CTR and KID values provided.
 The encoded header is provided as AAD to the AEAD encryption operation, together
@@ -2427,7 +2425,7 @@ <h3 id="name-sender-keys">
 <p id="section-5.1-2">In this scheme, it is assumed that receivers have a signal outside of SFrame for
 which client has sent a given frame (e.g., an RTP synchronization source (SSRC)).  SFrame KID
 values are then used to distinguish between versions of the sender's <code>base_key</code>.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
-<p id="section-5.1-3">Key IDs in this scheme have two parts: a "key generation" and a "ratchet step".
+<p id="section-5.1-3">KID values in this scheme have two parts: a "key generation" and a "ratchet step".
 Both are unsigned integers that begin at zero.  The key generation increments
 each time the sender distributes a new key to receivers.  The ratchet step is
 incremented each time the sender ratchets their key forward for forward secrecy:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
@@ -2445,7 +2443,7 @@ <h3 id="name-sender-keys">
 when they need to ratchet (vs. expecting a new key).  <code>R</code> effectively defines a
 reordering window, since no more than 2<sup><code>R</code></sup> ratchet steps can be
 active at a given time.  The key generation is sent in the remaining <code>64 - R</code>
-bits of the Key ID.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
+bits of the KID.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
 <div class="lang-pseudocode sourcecode" id="section-5.1-6">
 <pre>
 KID = (key_generation &lt;&lt; R) + (ratchet_step % (1 &lt;&lt; R))
@@ -2493,7 +2491,7 @@ <h3 id="name-sender-keys">
 from each sender (a) the current sender key for that sender and (b) the current
 KID value for the sender. Evicting a participant requires each sender to send
 a fresh sender key to all receivers.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
-<p id="section-5.1-10">It is up to the application to decide when sender keys are updated.  A sender
+<p id="section-5.1-10">It is the application's responsibility to decide when sender keys are updated.  A sender
 key may be updated by sending a new <code>base_key</code> (updating the key generation) or
 by hashing the current <code>base_key</code> (updating the ratchet step).  Ratcheting the
 key forward is useful when adding new receivers to an SFrame-based interaction,
@@ -2538,7 +2536,7 @@ <h3 id="name-mls">
 <p id="section-5.2-6">Let <code>S</code> be the number of bits required to encode a member index in the group,
 i.e., the smallest value such that <code>group_size &lt;= (1 &lt;&lt; S)</code>.  The sender index
 is encoded in the <code>S</code> bits above the epoch.  The remaining <code>64 - S - E</code> bits of
-the KID value are a <code>context</code> value chosen by the sender (context value <code>0</code> will
+the KID value are a <code>context</code> value chosen by the sender (<code>context</code> value <code>0</code> will
 produce the shortest encoded KID).<a href="#section-5.2-6" class="pilcrow">¶</a></p>
 <div class="lang-pseudocode sourcecode" id="section-5.2-7">
 <pre>
@@ -2720,11 +2718,12 @@ <h4 id="name-rtp-stream-reuse">
 even pre-allocate a predefined number of streams and choose in each moment in
 time which participant media will be sent through it.<a href="#section-6.1.1-1" class="pilcrow">¶</a></p>
 <p id="section-6.1.1-2">This means that in the same transport-level stream (e.g., an RTP stream defined
-by either SSRC or Media Identification (MID)) may carry media from different streams of different
-participants. As different keys are used by each participant for encoding their
-media, the receiver will be able to verify which is the sender of the media
-coming within the RTP stream at any given point in time, preventing the SFU
-trying to impersonate any of the participants with another participant's media.<a href="#section-6.1.1-2" class="pilcrow">¶</a></p>
+by either SSRC or Media Identification (MID)) may carry media from different
+streams of different participants. Because each participant uses a different key
+to encrypt their media, the receiver will be able to verify the sender of the
+media within the RTP stream at any given point in time. Thus the receiver will
+correctly associate the media with the sender indicated by the authenticated
+SFrame KID value, irrespective of how the SFU transmits the media to the client.<a href="#section-6.1.1-2" class="pilcrow">¶</a></p>
 <p id="section-6.1.1-3">Note that in order to prevent impersonation by a malicious participant (not the
 SFU), a mechanism based on digital signature would be required. SFrame does not
 protect against such attacks.<a href="#section-6.1.1-3" class="pilcrow">¶</a></p>
@@ -2737,7 +2736,7 @@ <h4 id="name-simulcast">
           </h4>
 <p id="section-6.1.2-1">When using simulcast, the same input image will produce N different encoded
 frames (one per simulcast layer), which would be processed independently by the
-frame encryptor and assigned an unique counter for each.<a href="#section-6.1.2-1" class="pilcrow">¶</a></p>
+frame encryptor and assigned an unique CTR value for each.<a href="#section-6.1.2-1" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="scalable-video-coding-svc">
@@ -2799,8 +2798,8 @@ <h2 id="name-security-considerations">
         <h3 id="name-no-header-confidentiality">
 <a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-no-header-confidentiality" class="section-name selfRef">No Header Confidentiality</a>
         </h3>
-<p id="section-7.1-1">SFrame provides integrity protection to the SFrame header (the Key ID and
-counter values), but it does not provide confidentiality protection.  Parties that
+<p id="section-7.1-1">SFrame provides integrity protection to the SFrame header (the KID and
+CTR values), but it does not provide confidentiality protection.  Parties that
 can observe the SFrame header may learn, for example, which parties are sending
 SFrame payloads (from KID values) and at what rates (from CTR values).  In cases
 where SFrame is used for end-to-end security on top of hop-by-hop protections
@@ -3035,7 +3034,7 @@ <h2 id="name-application-responsibilitie">
 <p id="section-9-2">In general, an application using SFrame is responsible for configuring SFrame.
 The application must first define when SFrame is applied at all.  When SFrame is
 applied, the application must define which cipher suite is to be used.  If new
-versions of SFrame are defined in the future, it will be up to the application
+versions of SFrame are defined in the future, it will be the application's responsibility
 to determine which version should be used.<a href="#section-9-2" class="pilcrow">¶</a></p>
 <p id="section-9-3">This division of responsibilities is similar to the way other media parameters
 (e.g., codecs) are typically handled in media applications, in the sense that
@@ -3069,12 +3068,12 @@ <h3 id="name-header-value-uniqueness">
         <h3 id="name-key-management-framework">
 <a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-key-management-framework" class="section-name selfRef">Key Management Framework</a>
         </h3>
-<p id="section-9.2-1">It is up to the application to provision SFrame with a mapping of KID values to
+<p id="section-9.2-1">The application is responsible for provisioning SFrame with a mapping of KID values to
 <code>base_key</code> values and the resulting keys and salts.  More importantly, the
 application specifies which KID values are used for which purposes (e.g., by
 which senders).  An application's KID assignment strategy <span class="bcp14">MUST</span> be structured to
 assure the non-reuse properties discussed in <a href="#header-value-uniqueness" class="auto internal xref">Section 9.1</a>.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
-<p id="section-9.2-2">It is also up to the application to define a rotation schedule for keys.  For
+<p id="section-9.2-2">The application is also responsible for defining a rotation schedule for keys.  For
 example, one application might have an ephemeral group for every call and keep
 rotating keys when endpoints join or leave the call, while another application
 could have a persistent group that can be used for multiple calls and simply
@@ -3108,7 +3107,7 @@ <h3 id="name-metadata">
 <a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-metadata" class="section-name selfRef">Metadata</a>
         </h3>
 <p id="section-9.4-1">The <code>metadata</code> input to SFrame operations an opaque byte string specified by the application. As
-such, it is up to the application to define what information should go in the
+such, the application needs to define what information should go in the
 <code>metadata</code> input and ensure that it is provided to the encryption and decryption
 functions at the appropriate points.  A receiver <span class="bcp14">MUST NOT</span> use SFrame-authenticated
 metadata until after the SFrame decrypt function has authenticated it, unless
@@ -3243,7 +3242,7 @@ <h2 id="name-example-api">
 </li>
         <li class="normal" id="appendix-A-5.2">
           <p id="appendix-A-5.2.1"><strong>Add a key for sending:</strong> The key and salt are derived from the base key and
-used to initialize a send context, together with a zero counter value.<a href="#appendix-A-5.2.1" class="pilcrow">¶</a></p>
+used to initialize a send context, together with a zero CTR value.<a href="#appendix-A-5.2.1" class="pilcrow">¶</a></p>
 </li>
         <li class="normal" id="appendix-A-5.3">
           <p id="appendix-A-5.3.1"><strong>Add a key for receiving:</strong> The key and salt are derived from the base key and
@@ -3397,13 +3396,13 @@ <h3 id="name-audio">
 of the Opus codec <span>[<a href="#RFC6716" class="cite xref">RFC6716</a>]</span>:<a href="#appendix-B.2-2" class="pilcrow">¶</a></p>
 <ul class="normal">
 <li class="normal" id="appendix-B.2-3.1">
-            <p id="appendix-B.2-3.1.1">Narrow-band (NB) speech: 120 ms packets, 8 kbps<a href="#appendix-B.2-3.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-B.2-3.1.1">Narrow-band (NB) speech: 120 ms packets (8 frames per second (fps)), 8 kbps<a href="#appendix-B.2-3.1.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-B.2-3.2">
-            <p id="appendix-B.2-3.2.1">Full-band (FB) speech: 20 ms packets, 32 kbps<a href="#appendix-B.2-3.2.1" class="pilcrow">¶</a></p>
+            <p id="appendix-B.2-3.2.1">Full-band (FB) speech: 20 ms packets (32 fps), 32 kbps<a href="#appendix-B.2-3.2.1" class="pilcrow">¶</a></p>
 </li>
           <li class="normal" id="appendix-B.2-3.3">
-            <p id="appendix-B.2-3.3.1">Full-band stereo music: 10 ms packets, 128 kbps<a href="#appendix-B.2-3.3.1" class="pilcrow">¶</a></p>
+            <p id="appendix-B.2-3.3.1">Full-band stereo music: 10 ms packets (100 fps), 128 kbps<a href="#appendix-B.2-3.3.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 <span id="name-sframe-overhead-for-audio-s"></span><div id="audio-overhead">
@@ -3415,7 +3414,7 @@ <h3 id="name-audio">
 <thead>
             <tr>
               <th class="text-left" rowspan="1" colspan="1">Scenario</th>
-              <th class="text-center" rowspan="1" colspan="1">Frames per Second (fps)</th>
+              <th class="text-center" rowspan="1" colspan="1">fps</th>
               <th class="text-center" rowspan="1" colspan="1">Base kbps</th>
               <th class="text-center" rowspan="1" colspan="1">Overhead kbps</th>
               <th class="text-center" rowspan="1" colspan="1">Overhead %</th>
@@ -6296,7 +6295,7 @@ <h2 id="name-authors-addresses">
 </div>
 </address>
 <address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Richard L. Barnes (<span class="role">editor</span>)</span></div>
+        <div dir="auto" class="left"><span class="fn nameRole">Richard Barnes (<span class="role">editor</span>)</span></div>
 <div dir="auto" class="left"><span class="org">Cisco</span></div>
 <div class="email">
 <span>Email:</span>