draft-connolly-tls-mlkem-key-agreement-00.txt | draft-connolly-tls-mlkem-key-agreement-01.txt | |||
---|---|---|---|---|
Transport Layer Security D. Connolly | Transport Layer Security D. Connolly | |||
Internet-Draft SandboxAQ | Internet-Draft SandboxAQ | |||
Intended status: Informational 4 March 2024 | Intended status: Informational 22 March 2024 | |||
Expires: 5 September 2024 | Expires: 23 September 2024 | |||
ML-KEM Post-Quantum Key Agreement for TLS 1.3 | ML-KEM Post-Quantum Key Agreement for TLS 1.3 | |||
draft-connolly-tls-mlkem-key-agreement-00 | draft-connolly-tls-mlkem-key-agreement-01 | |||
Abstract | Abstract | |||
This memo defines ML-KEM as a standalone NamedGroup for use in TLS | This memo defines ML-KEM-768 and ML-KEM-1024 as a standalone | |||
1.3 to achieve post-quantum key agreement. | NamedGroup for use in TLS 1.3 to achieve post-quantum key agreement. | |||
About This Document | About This Document | |||
This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
Status information for this document may be found at | Status information for this document may be found at | |||
https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key- | https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key- | |||
agreement/. | agreement/. | |||
Discussion of this document takes place on the Transport Layer | Discussion of this document takes place on the Transport Layer | |||
Security Working Group mailing list (mailto:tls@ietf.org), which is | Security Working Group mailing list (mailto:tls@ietf.org), which is | |||
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe | archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe | |||
at https://www.ietf.org/mailman/listinfo/tls/. | at https://www.ietf.org/mailman/listinfo/tls/. | |||
Source for this draft and an issue tracker can be found at | Source for this draft and an issue tracker can be found at | |||
https://github.com/dconnolly/draft-tls-mlkem-key-agreement. | https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 5 September 2024. | This Internet-Draft will expire on 23 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 | 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 | 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 | |||
3. Construction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Key encapsulation mechanisms . . . . . . . . . . . . . . . . 3 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | 4. Construction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | 4.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4.2. Transmitting encapsulation keys and ciphertexts . . . . . 4 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 4.3. Shared secret calculation . . . . . . . . . . . . . . . . 5 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . 4 | 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . 8 | ||||
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
1. Introduction | 1. Introduction | |||
1.1. Motivation | 1.1. Motivation | |||
FIPS 203 standard (ML-KEM) is a new FIPS / CNSA 2.0 standard for | FIPS 203 standard (ML-KEM) is a new FIPS standard for post-quantum | |||
post-quantum key agreement via lattice-based key establishment | key agreement via lattice-based key establishment mechanism (KEM). | |||
mechanism (KEM). Having a fully post-quantum (not hybrid) FIPS- | Having a fully post-quantum (not hybrid) key agreement option for TLS | |||
compliant key agreement option for TLS 1.3 is necessary for eventual | 1.3 is necessary for migrating beyond hybrids and for users that need | |||
movement beyond hybrids and for users that need to be fully post- | to be fully post-quantum. | |||
quantum sooner than later. | ||||
2. Conventions and Definitions | 2. Conventions and Definitions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Construction | 3. Key encapsulation mechanisms | |||
We align with [hybrid] except that instead of joining ECDH options | This document models key agreement as key encapsulation mechanisms | |||
with a KEM, we just have the KEM as a NamedGroup. | (KEMs), which consist of three algorithms: | |||
4. Security Considerations | * KeyGen() -> (pk, sk): A probabilistic key generation algorithm, | |||
which generates a public encapsulation key pk and a secret | ||||
decapsulation key sk. | ||||
TLS 1.3's key schedule commits to the the ML-KEM encapsulation key | * Encaps(pk) -> (ct, shared_secret): A probabilistic encapsulation | |||
and the encapsulated shared secret ciphertext, providing resilience | algorithm, which takes as input a public encapsulation key pk and | |||
against re-encapsulation attacks against KEMs used for key agreement. | outputs a ciphertext ct and shared secret shared_secret. | |||
* Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which | ||||
takes as input a secret decapsulation key sk and ciphertext ct and | ||||
outputs a shared secret shared_secret. | ||||
ML-KEM-768 and ML-KEM-1024 conform to this API: | ||||
* ML-KEM-768 has encapsulation keys of size 1184 bytes, | ||||
decapsulation keys of 2400 bytes, ciphertext size of 1088 bytes, | ||||
and shared secrets of size 32 bytes | ||||
* ML-KEM-1024 has encapsulation keys of size 1568 bytes, | ||||
decapsulation keys of 3168 bytes, ciphertext size of 1568 bytes, | ||||
and shared secrets of size 32 bytes | ||||
4. Construction | ||||
We define the KEMs as NamedGroups and sent in the supported_groups | ||||
extension. | ||||
4.1. Negotiation | ||||
Each method is its own solely post-quantum key agreement method, | ||||
which are assigned their own identifiers, registered by IANA in the | ||||
TLS Supported Groups registry: | ||||
enum { | ||||
..., | ||||
/* ML-KEM Key Agreement Methods */ | ||||
mlkem768(0x0768), | ||||
mlkem1024(0x1024) | ||||
..., | ||||
} NamedGroup; | ||||
4.2. Transmitting encapsulation keys and ciphertexts | ||||
The encapsulation key and ciphertext values are directly encoded with | ||||
fixed lengths as in [FIPS203]; the representation and length of | ||||
elements MUST be fixed once the algorithm is fixed. | ||||
In TLS 1.3 a KEM encapsulation key or KEM ciphertext is represented | ||||
as a KeyShareEntry: | ||||
struct { | ||||
NamedGroup group; | ||||
opaque key_exchange<1..2^16-1>; | ||||
} KeyShareEntry; | ||||
These are transmitted in the extension_data fields of | ||||
KeyShareClientHello and KeyShareServerHello extensions: | ||||
struct { | ||||
KeyShareEntry client_shares<0..2^16-1>; | ||||
} KeyShareClientHello; | ||||
struct { | ||||
KeyShareEntry server_share; | ||||
} KeyShareServerHello; | ||||
The client's shares are listed in descending order of client | ||||
preference; the server selects one algorithm and sends its | ||||
corresponding share. | ||||
For the client's share, the key_exchange value contains the pk output | ||||
of the corresponding ML-KEM NamedGroup's KeyGen algorithm. | ||||
For the server's share, the key_exchange value contains the ct output | ||||
of the corresponding ML-KEM NamedGroup's Encaps algorithm. | ||||
4.3. Shared secret calculation | ||||
The shared secret output from the ML-KEM Encaps and Decaps algorithms | ||||
over the appropriate keypair and ciphertext results in the same | ||||
shared secret shared_secret, which is inserted into the TLS 1.3 key | ||||
schedule in place of the (EC)DHE shared secret, as shown in Figure 1. | ||||
0 | ||||
| | ||||
v | ||||
PSK -> HKDF-Extract = Early Secret | ||||
| | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
| | ||||
v | ||||
Derive-Secret(., "derived", "") | ||||
| | ||||
v | ||||
shared_secret -> HKDF-Extract = Handshake Secret | ||||
^^^^^^^^^^^^^ | | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
| | ||||
v | ||||
Derive-Secret(., "derived", "") | ||||
| | ||||
v | ||||
0 -> HKDF-Extract = Master Secret | ||||
| | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
+-----> Derive-Secret(...) | ||||
Figure 1: Key schedule for key agreement | ||||
5. Discussion | ||||
*Larger encapsulation keys and/or ciphertexts* The HybridKeyExchange | ||||
struct in Section 4.2 limits public keys and ciphertexts to 2^16-1 | ||||
bytes; this is bounded by the same (2^16-1)-byte limit on the | ||||
key_exchange field in the KeyShareEntry struct. All defined | ||||
parameter sets for ML-KEM have encapsulation keys and ciphertexts | ||||
that fall within the TLS constraints. | ||||
*Failures* Some post-quantum key exchange algorithms, including ML- | ||||
KEM, have non-zero probability of failure, meaning two honest parties | ||||
may derive different shared secrets. This would cause a handshake | ||||
failure. ML-KEM has a cryptographically small failure rate; | ||||
implementers should be aware of the potential of handshake failure. | ||||
Clients can retry if a failure is encountered. | ||||
6. Security Considerations | ||||
*IND-CCA* The main security property for KEMs is indistinguishability | ||||
under adaptive chosen ciphertext attack (IND-CCA2), which means that | ||||
shared secret values should be indistinguishable from random strings | ||||
even given the ability to have other arbitrary ciphertexts | ||||
decapsulated. IND-CCA2 corresponds to security against an active | ||||
attacker, and the public key / secret key pair can be treated as a | ||||
long-term key or reused. A common design pattern for obtaining | ||||
security under key reuse is to apply the Fujisaki-Okamoto (FO) | ||||
transform [FO] or a variant thereof [HHK]. | ||||
Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key | ||||
exchange in a group. DH key exchange can be modeled as a KEM, with | ||||
KeyGen corresponding to selecting an exponent x as the secret key and | ||||
computing the public key g^x; encapsulation corresponding to | ||||
selecting an exponent y, computing the ciphertext g^y and the shared | ||||
secret g^(xy), and decapsulation as computing the shared secret | ||||
g^(xy). See [HPKE] for more details of such Diffie-Hellman-based key | ||||
encapsulation mechanisms. Diffie-Hellman key exchange, when viewed | ||||
as a KEM, does not formally satisfy IND-CCA2 security, but is still | ||||
safe to use for ephemeral key exchange in TLS 1.3, see e.g. | ||||
[DOWLING]. | ||||
TLS 1.3 does not require that ephemeral public keys be used only in a | ||||
single key exchange session; some implementations may reuse them, at | ||||
the cost of limited forward secrecy. As a result, any KEM used in | ||||
the manner described in this document MUST explicitly be designed to | ||||
be secure in the event that the public key is reused. Finite-field | ||||
and elliptic-curve Diffie-Hellman key exchange methods used in TLS | ||||
1.3 satisfy this criteria. For generic KEMs, this means satisfying | ||||
IND-CCA2 security or having a transform like the Fujisaki-Okamoto | ||||
transform [FO] [HHK] applied. While it is recommended that | ||||
implementations avoid reuse of KEM public keys, implementations that | ||||
do reuse KEM public keys MUST ensure that the number of reuses of a | ||||
KEM public key abides by any bounds in the specification of the KEM | ||||
or subsequent security analyses. Implementations MUST NOT reuse | ||||
randomness in the generation of KEM ciphertexts. | ||||
*Binding properties* TLS 1.3's key schedule commits to the the ML-KEM | ||||
encapsulation key and the encapsulated shared secret ciphertext as | ||||
the key_exchange field as part of the key_share extension are | ||||
populated with those values are included as part of the handshake | ||||
messages, providing resilience against re-encapsulation attacks | ||||
against KEMs used for key agreement. | ||||
ML-KEM is MAL-BIND-K-PK-secure but only LEAK-BIND-K-CT and LEAK-BIND- | ML-KEM is MAL-BIND-K-PK-secure but only LEAK-BIND-K-CT and LEAK-BIND- | |||
K,PK-CT-secure, but because of the inclusion of the ML-KEM ciphertext | K,PK-CT-secure, but because of the inclusion of the ML-KEM ciphertext | |||
in the TLS 1.3 key schedule there is no concern of malicious | in the TLS 1.3 key schedule there is no concern of malicious | |||
tampering (MAL) adversaries, not just honestly-generated but leaked | tampering (MAL) adversaries, not just honestly-generated but leaked | |||
key pairs (LEAK adversaries). The same is true of other KEMs with | key pairs (LEAK adversaries). The same is true of other KEMs with | |||
weaker binding properties, even if they were to have more constraints | weaker binding properties, even if they were to have more constraints | |||
for secure use in contexts outside of TLS 1.3 handshake key | for secure use in contexts outside of TLS 1.3 handshake key | |||
agreement.These computational binding properties for KEMs were | agreement.These computational binding properties for KEMs were | |||
formalized in [CDM23]. | formalized in [CDM23]. | |||
5. IANA Considerations | 7. IANA Considerations | |||
This document requests/registers two new entries to the TLS Named | This document requests/registers two new entries to the TLS Supported | |||
Group (or Supported Group) registry, according to the procedures in | Groups registry, according to the procedures in Section 6 of | |||
Section 6 of [tlsiana]. | [tlsiana]. | |||
Value: 0x0768 (please) | Value: 0x0768 (please) | |||
Description: MLKEM768 | Description: MLKEM768 | |||
DTLS-OK: Y | DTLS-OK: Y | |||
Recommended: N | Recommended: N | |||
Reference: This document | Reference: This document | |||
skipping to change at page 4, line 4 ¶ | skipping to change at page 7, line 49 ¶ | |||
Value: 0x1024 (please) | Value: 0x1024 (please) | |||
Description: MLKEM1024 | Description: MLKEM1024 | |||
DTLS-OK: Y | DTLS-OK: Y | |||
Recommended: N | Recommended: N | |||
Reference: This document | Reference: This document | |||
Comment: FIPS 203 version of ML-KEM-1024 | ||||
6. References | Comment: FIPS 203 version of ML-KEM-1024 | |||
6.1. Normative References | 8. References | |||
8.1. Normative References | ||||
[FIPS203] "*** BROKEN REFERENCE ***". | [FIPS203] "*** BROKEN REFERENCE ***". | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/rfc/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | |||
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | |||
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | |||
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. | February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. | |||
6.2. Informative References | 8.2. Informative References | |||
[CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with | [CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with | |||
the KEMs: Stronger Security Notions for KEMs and automated | the KEMs: Stronger Security Notions for KEMs and automated | |||
analysis of KEM-based protocols", 2023, | analysis of KEM-based protocols", 2023, | |||
<https://eprint.iacr.org/2023/1933.pdf>. | <https://eprint.iacr.org/2023/1933.pdf>. | |||
[DOWLING] Dowling, B., Fischlin, M., Günther, F., and D. Stebila, "A | ||||
Cryptographic Analysis of the TLS 1.3 Handshake Protocol", | ||||
Springer Science and Business Media LLC, Journal of | ||||
Cryptology vol. 34, no. 4, DOI 10.1007/s00145-021-09384-1, | ||||
July 2021, <https://doi.org/10.1007/s00145-021-09384-1>. | ||||
[FO] Fujisaki, E. and T. Okamoto, "Secure Integration of | ||||
Asymmetric and Symmetric Encryption Schemes", Springer | ||||
Science and Business Media LLC, Journal of Cryptology vol. | ||||
26, no. 1, pp. 80-101, DOI 10.1007/s00145-011-9114-1, | ||||
December 2011, | ||||
<https://doi.org/10.1007/s00145-011-9114-1>. | ||||
[HHK] Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular | ||||
Analysis of the Fujisaki-Okamoto Transformation", Springer | ||||
International Publishing, Theory of Cryptography pp. | ||||
341-371, DOI 10.1007/978-3-319-70500-2_12, | ||||
ISBN ["9783319704999", "9783319705002"], 2017, | ||||
<https://doi.org/10.1007/978-3-319-70500-2_12>. | ||||
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid | ||||
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, | ||||
February 2022, <https://www.rfc-editor.org/rfc/rfc9180>. | ||||
[hybrid] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key | [hybrid] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key | |||
exchange in TLS 1.3", Work in Progress, Internet-Draft, | exchange in TLS 1.3", Work in Progress, Internet-Draft, | |||
draft-ietf-tls-hybrid-design-09, 7 September 2023, | draft-ietf-tls-hybrid-design-09, 7 September 2023, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- | <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | |||
hybrid-design-09>. | hybrid-design-09>. | |||
[tlsiana] Salowey, J. A. and S. Turner, "IANA Registry Updates for | [tlsiana] Salowey, J. A. and S. Turner, "IANA Registry Updates for | |||
TLS and DTLS", Work in Progress, Internet-Draft, draft- | TLS and DTLS", Work in Progress, Internet-Draft, draft- | |||
ietf-tls-rfc8447bis-08, 23 January 2024, | ietf-tls-rfc8447bis-08, 23 January 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- | <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | |||
rfc8447bis-08>. | rfc8447bis-08>. | |||
Acknowledgments | Acknowledgments | |||
TODO acknowledge. | Thanks to Douglas Stebila for consultation on the draft-ietf-tls- | |||
hybrid-design design. | ||||
Author's Address | Author's Address | |||
Deirdre Connolly | Deirdre Connolly | |||
SandboxAQ | SandboxAQ | |||
Email: durumcrustulum@gmail.com | Email: durumcrustulum@gmail.com | |||
End of changes. 19 change blocks. | ||||
38 lines changed or deleted | 241 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |