Skip to content

Commit

Permalink
Script updating gh-pages from 167754b. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Jan 20, 2024
1 parent 6b05b7f commit 132c1d9
Show file tree
Hide file tree
Showing 2 changed files with 35 additions and 22 deletions.
29 changes: 17 additions & 12 deletions draft-ietf-mls-architecture.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1050,7 +1050,7 @@
</tr></thead>
<tfoot><tr>
<td class="left">Beurdouche, et al.</td>
<td class="center">Expires 22 July 2024</td>
<td class="center">Expires 23 July 2024</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
Expand All @@ -1063,12 +1063,12 @@
<dd class="internet-draft">draft-ietf-mls-architecture-latest</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2024-01-19" class="published">19 January 2024</time>
<time datetime="2024-01-20" class="published">20 January 2024</time>
</dd>
<dt class="label-intended-status">Intended Status:</dt>
<dd class="intended-status">Informational</dd>
<dt class="label-expires">Expires:</dt>
<dd class="expires"><time datetime="2024-07-22">22 July 2024</time></dd>
<dd class="expires"><time datetime="2024-07-23">23 July 2024</time></dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
Expand Down Expand Up @@ -1145,7 +1145,7 @@ <h2 id="name-status-of-this-memo">
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow"></a></p>
<p id="section-boilerplate.1-4">
This Internet-Draft will expire on 22 July 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
This Internet-Draft will expire on 23 July 2024.<a href="#section-boilerplate.1-4" class="pilcrow"></a></p>
</section>
</div>
<div id="copyright">
Expand Down Expand Up @@ -1443,8 +1443,8 @@ <h3 id="name-protocol-overview">
<p id="section-2.1-5">Finally, a <em>PublicMessage</em> contains an integrity-protected MLS Handshake message,
while a <em>PrivateMessage</em> contains a confidential, integrity-protected Handshake
or application message.<a href="#section-2.1-5" class="pilcrow"></a></p>
<p id="section-2.1-6">For a more
detailed explanation of these terms, please consult the MLS protocol specification <span>[<a href="#RFC9420" class="cite xref">RFC9420</a>]</span>.<a href="#section-2.1-6" class="pilcrow"></a></p>
<p id="section-2.1-6">For a more detailed explanation of these terms, please consult the MLS protocol
specification <span>[<a href="#RFC9420" class="cite xref">RFC9420</a>]</span>.<a href="#section-2.1-6" class="pilcrow"></a></p>
</section>
</div>
<div id="abstract-services">
Expand Down Expand Up @@ -1942,10 +1942,10 @@ <h2 id="name-authentication-service">
to verify keys.<a href="#section-4-5.2.1" class="pilcrow"></a></p>
</li>
<li class="normal" id="section-4-5.3">
<p id="section-4-5.3.1">In a system based on <span>[<a href="#CONIKS" class="cite xref">CONIKS</a>]</span> end user Key Transparency (KT), the issuance
function would correspond to the insertion of a key in a KT log under a user's
identity. The verification function would correspond to verifying a key's
inclusion in the log for a claimed identity, together with the KT log's
<p id="section-4-5.3.1">In a system based on <span>[<a href="#CONIKS" class="cite xref">CONIKS</a>]</span> end user Key Transparency (KT) <span>[<a href="#KT" class="cite xref">KT</a>]</span>, the
issuance function would correspond to the insertion of a key in a KT log under
a user's identity. The verification function would correspond to verifying a
key's inclusion in the log for a claimed identity, together with the KT log's
mechanisms for a user to monitor and control which keys are associated with
their identity.<a href="#section-4-5.3.1" class="pilcrow"></a></p>
</li>
Expand Down Expand Up @@ -2933,8 +2933,9 @@ <h4 id="name-forward-and-post-compromise">
keys and all shared group keys, but Alice performs a key update at time t2, then
the attacker is unable to violate any of the MLS security properties after the
updates have been processed.<a href="#section-8.2.2-3" class="pilcrow"></a></p>
<p id="section-8.2.2-4">Both of these properties are satisfied even against compromised DSs and ASs
in the case where a Key Transparency mechanism is in use.<a href="#section-8.2.2-4" class="pilcrow"></a></p>
<p id="section-8.2.2-4">Both of these properties are satisfied even against compromised DSs and ASs in
the case where some other mechanism for verifying keys is in use, such as Key
Transparency <span>[<a href="#KT" class="cite xref">KT</a>]</span>.<a href="#section-8.2.2-4" class="pilcrow"></a></p>
<p id="section-8.2.2-5">Confidentiality is mainly ensured on the client side. Because Forward Secrecy
(FS) and Post-Compromise Security (PCS) rely on the active deletion and
replacement of keying material, any client which is persistently offline may
Expand Down Expand Up @@ -3723,6 +3724,10 @@ <h3 id="name-informative-references">
<dd>
<span class="refAuthor">Schinazi, D.</span>, <span class="refTitle">"The MASQUE Proxy"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-schinazi-masque-proxy-01</span>, <time datetime="2023-09-07" class="refDate">7 September 2023</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-schinazi-masque-proxy-01">https://datatracker.ietf.org/doc/html/draft-schinazi-masque-proxy-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="KT">[KT]</dt>
<dd>
<span class="refAuthor">McMillion, B.</span>, <span class="refTitle">"Key Transparency Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-keytrans-architecture-00</span>, <time datetime="2024-01-18" class="refDate">18 January 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-00">https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Loopix">[Loopix]</dt>
<dd>
<span class="refAuthor">Piotrowska, A. M.</span>, <span class="refAuthor">Hayes, J.</span>, <span class="refAuthor">Elahi, T.</span>, <span class="refAuthor">Meiser, S.</span>, and <span class="refAuthor">G. Danezis</span>, <span class="refTitle">"The Loopix Anonymity System"</span>, <time datetime="2017" class="refDate">2017</time>. </dd>
Expand Down
28 changes: 18 additions & 10 deletions draft-ietf-mls-architecture.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,14 @@
Network Working Group B. Beurdouche
Internet-Draft Inria & Mozilla
Intended status: Informational E. Rescorla
Expires: 22 July 2024 Mozilla
Expires: 23 July 2024 Mozilla
E. Omara
Google
S. Inguva

A. Duric
Wire
19 January 2024
20 January 2024


The Messaging Layer Security (MLS) Architecture
Expand Down Expand Up @@ -68,7 +68,7 @@ Status of This Memo
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 22 July 2024.
This Internet-Draft will expire on 23 July 2024.

Copyright Notice

Expand Down Expand Up @@ -494,12 +494,13 @@ Welcome (Charlie) -----------------------------------------> | Step 4
function is the application function that enables users to verify
keys.

* In a system based on [CONIKS] end user Key Transparency (KT), the
issuance function would correspond to the insertion of a key in a
KT log under a user's identity. The verification function would
correspond to verifying a key's inclusion in the log for a claimed
identity, together with the KT log's mechanisms for a user to
monitor and control which keys are associated with their identity.
* In a system based on [CONIKS] end user Key Transparency (KT) [KT],
the issuance function would correspond to the insertion of a key
in a KT log under a user's identity. The verification function
would correspond to verifying a key's inclusion in the log for a
claimed identity, together with the KT log's mechanisms for a user
to monitor and control which keys are associated with their
identity.

By the nature of its roles in MLS authentication, the AS is invested
with a large amount of trust and the compromise of one the AS could
Expand Down Expand Up @@ -1403,7 +1404,8 @@ Welcome (Charlie) -----------------------------------------> | Step 4
properties after the updates have been processed.

Both of these properties are satisfied even against compromised DSs
and ASs in the case where a Key Transparency mechanism is in use.
and ASs in the case where some other mechanism for verifying keys is
in use, such as Key Transparency [KT].

Confidentiality is mainly ensured on the client side. Because
Forward Secrecy (FS) and Post-Compromise Security (PCS) rely on the
Expand Down Expand Up @@ -2149,6 +2151,12 @@ Welcome (Charlie) -----------------------------------------> | Step 4
September 2023, <https://datatracker.ietf.org/doc/html/
draft-schinazi-masque-proxy-01>.

[KT] McMillion, B., "Key Transparency Architecture", Work in
Progress, Internet-Draft, draft-ietf-keytrans-
architecture-00, 18 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-
keytrans-architecture-00>.

[Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and
G. Danezis, "The Loopix Anonymity System", 2017.

Expand Down

0 comments on commit 132c1d9

Please sign in to comment.