< draft-hallambaker-mesh-trust-01.txt   draft-hallambaker-mesh-trust-02.txt >
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft April 4, 2019 Internet-Draft July 8, 2019
Intended status: Informational Intended status: Informational
Expires: October 6, 2019 Expires: January 9, 2020
Mathematical Mesh Part VI: The Trust Mesh Mathematical Mesh Part VI: The Trust Mesh
draft-hallambaker-mesh-trust-01 draft-hallambaker-mesh-trust-02
Abstract Abstract
This paper extends Shannon's concept of a 'work factor' as applied to This paper extends Shannon's concept of a 'work factor' as applied to
evaluation of cryptographic algorithms to provide an objective evaluation of cryptographic algorithms to provide an objective
measure of the practical security offered by a protocol or measure of the practical security offered by a protocol or
infrastructure design. Considering the hypothetical work factor infrastructure design. Considering the hypothetical work factor
based on an informed estimate of the probable capabilities of an based on an informed estimate of the probable capabilities of an
attacker with unknown resources provides a better indication of the attacker with unknown resources provides a better indication of the
relative strength of protocol designs than the computational work relative strength of protocol designs than the computational work
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 October 6, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
2.1.6. A blended approach . . . . . . . . . . . . . . . . . 19 2.1.6. A blended approach . . . . . . . . . . . . . . . . . 19
3. The Mesh of Trust . . . . . . . . . . . . . . . . . . . . . . 21 3. The Mesh of Trust . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Master Profile . . . . . . . . . . . . . . . . . . . . . 21 3.1. Master Profile . . . . . . . . . . . . . . . . . . . . . 21
3.2. Uniform Data Fingerprints . . . . . . . . . . . . . . . . 21 3.2. Uniform Data Fingerprints . . . . . . . . . . . . . . . . 21
3.3. Strong Internet Names . . . . . . . . . . . . . . . . . . 22 3.3. Strong Internet Names . . . . . . . . . . . . . . . . . . 22
3.4. Trust notary . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Trust notary . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Endorsement . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Endorsement . . . . . . . . . . . . . . . . . . . . . . . 23
3.6. Evaluating trust . . . . . . . . . . . . . . . . . . . . 23 3.6. Evaluating trust . . . . . . . . . . . . . . . . . . . . 23
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Normative References . . . . . . . . . . . . . . . . . . 24 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Informative References . . . . . . . . . . . . . . . . . 24 7.1. Normative References . . . . . . . . . . . . . . . . . . 24
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . 24
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Work Factor 1. Work Factor
Recent events have highlighted both the need for open standards-based Recent events have highlighted both the need for open standards-based
security protocols and the possibility that the design of such security protocols and the possibility that the design of such
protocols may have been sabotaged [Schneier2013] . We thus face two protocols may have been sabotaged [Schneier2013] . We thus face two
important and difficult challenges, first to design an Internet important and difficult challenges, first to design an Internet
security infrastructure that offers practical security against the security infrastructure that offers practical security against the
class of attacks revealed, and secondly, to convince potential users class of attacks revealed, and secondly, to convince potential users
skipping to change at page 21, line 48 skipping to change at page 21, line 48
Unlike user keys in traditional PKIs, a Mesh master profile is Unlike user keys in traditional PKIs, a Mesh master profile is
designed to permit (but not require) life long use. A Master profile designed to permit (but not require) life long use. A Master profile
can be revoked but does not expire. It is not possible to change the can be revoked but does not expire. It is not possible to change the
signature key in a master profile. Should a compromise occur, a new signature key in a master profile. Should a compromise occur, a new
master profile must be created. master profile must be created.
3.2. Uniform Data Fingerprints 3.2. Uniform Data Fingerprints
Direct trust in the Mesh is realized through use of Uniform Data Direct trust in the Mesh is realized through use of Uniform Data
Fingerprints (UDF) [draft-hallambaker-udf] . A UDF consists of a Fingerprints (UDF) [draft-hallambaker-mesh-udf] . A UDF consists of a
cryptographic digest (e.g. SHA-2-512) over a data sequence and a cryptographic digest (e.g. SHA-2-512) over a data sequence and a
content type identifier. content type identifier.
UDFs are presented as a Base32 encoded sequence with separators every UDFs are presented as a Base32 encoded sequence with separators every
25 characters. UDFs may be presented at different precisions 25 characters. UDFs may be presented at different precisions
according to the intended use. The 25-character presentation according to the intended use. The 25-character presentation
provides a work factor of 2^117 and is short enough to put on a provides a work factor of 2^117 and is short enough to put on a
business card or present as a QR code. The 50-character presentation business card or present as a QR code. The 50-character presentation
provides a work factor of 2^242 and is compact enough to be used in a provides a work factor of 2^242 and is compact enough to be used in a
configuration file. configuration file.
skipping to change at page 22, line 28 skipping to change at page 22, line 28
The UDF of a user's master profile signature key is used as a The UDF of a user's master profile signature key is used as a
persistent, permanent identifier of the user that is unique to them persistent, permanent identifier of the user that is unique to them
and will remain constant for their entire life unless they have and will remain constant for their entire life unless they have
reason to replace their master profile with a new one. The exchange reason to replace their master profile with a new one. The exchange
of master profile UDFs is the means by which Mesh users establish of master profile UDFs is the means by which Mesh users establish
direct trust. direct trust.
3.3. Strong Internet Names 3.3. Strong Internet Names
A Strong Internet name (SIN) [draft-hallambaker-sin] is a valid A Strong Internet name (SIN) [draft-hallambaker-mesh-udf] is a valid
Internet address that contains a UDF fingerprint of a security policy Internet address that contains a UDF fingerprint of a security policy
describing interpretation of that name. describing interpretation of that name.
While a SIN creates a strong binding between an Internet address and While a SIN creates a strong binding between an Internet address and
a security policy, it does not provide a mechanism for discovery of a security policy, it does not provide a mechanism for discovery of
the security policy. Nor is it necessarily the case that this is the security policy. Nor is it necessarily the case that this is
publicly available. publicly available.
For example, Example Inc holds the domain name example.com and has For example, Example Inc holds the domain name example.com and has
deployed a private CA whose root of trust is a PKIX certificate with deployed a private CA whose root of trust is a PKIX certificate with
the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ. the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.
Alice is an employee of Example Inc., she uses three email addresses: Alice is an employee of Example Inc., she uses three email addresses:
For example, Example Inc holds the domain name example.com and has
deployed a private CA whose root of trust is a PKIX certificate with
the UDF fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.
Alice is an employee of Example Inc., she uses three email addresses:
alice@example.com A regular email address (not a SIN). alice@example.com A regular email address (not a SIN).
alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com A strong email
address that is backwards compatible. address that is backwards compatible.
alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz A strong email
address that is backwards incompatible. address that is backwards incompatible.
Use of SINs allows the use of a direct trust model to provide end-to- Use of SINs allows the use of a direct trust model to provide end-to-
end security using existing, unmodified email clients and other end security using existing, unmodified email clients and other
skipping to change at page 23, line 29 skipping to change at page 23, line 32
A Mesh trust notary is a chained notary service that accepts A Mesh trust notary is a chained notary service that accepts
notarization requests from users and enrolls them in a publicly notarization requests from users and enrolls them in a publicly
visible, tamper-evident, append-only log. visible, tamper-evident, append-only log.
The practices for operation of the trust notary are currently The practices for operation of the trust notary are currently
undefined but should be expected to follow the approach described undefined but should be expected to follow the approach described
above. above.
The trust notary protocol provides support for establishing an The trust notary protocol provides support for establishing an
internotary through cross certification. The append only log format internotary through cross certification. The append only log format
is a DARE Container [draft-hallambaker-dare-container] , the service is a DARE Container [draft-hallambaker-mesh-dare] , the service
protocol is currently in development. protocol is currently in development.
3.5. Endorsement 3.5. Endorsement
An endorsement is a document submitted to a trust notary that An endorsement is a document submitted to a trust notary that
includes a claim of the form 'public key X is held by user Y'. Mesh includes a claim of the form 'public key X is held by user Y'. Mesh
endorsements may be issued by CAs or by ordinary users. endorsements may be issued by CAs or by ordinary users.
3.6. Evaluating trust 3.6. Evaluating trust
skipping to change at page 24, line 21 skipping to change at page 24, line 23
5. Security Considerations 5. Security Considerations
This document describes the means by which interparty identification This document describes the means by which interparty identification
risk is managed and controlled in the Mathematical Mesh. risk is managed and controlled in the Mathematical Mesh.
The security considerations for use and implementation of Mesh The security considerations for use and implementation of Mesh
services and applications are described in the Mesh Security services and applications are described in the Mesh Security
Considerations guide [draft-hallambaker-mesh-security] . Considerations guide [draft-hallambaker-mesh-security] .
6. References 6. Acknowledgements
6.1. Normative References A list of people who have contributed to the design of the Mesh is
presented in [draft-hallambaker-mesh-architecture] .
7. References
7.1. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", draft-hallambaker-mesh-
architecture-08 (work in progress), July 2019.
[draft-hallambaker-mesh-security] [draft-hallambaker-mesh-security]
"[Reference Not Found!]". Hallam-Baker, P., "Mathematical Mesh Part VII: Security
Considerations", draft-hallambaker-mesh-security-00 (work
in progress), April 2019.
6.2. Informative References 7.2. Informative References
[Adrian2015] [Adrian2015]
Adrian, D., "Weak Diffie-Hellman and the Logjam Attack", Adrian, D., "Weak Diffie-Hellman and the Logjam Attack",
October 2015. October 2015.
[Bitcoin] Finley, K., "After 10 Years, Bitcoin Has Changed [Bitcoin] Finley, K., "After 10 Years, Bitcoin Has Changed
Everything?And Nothing", November 2018. Everything?And Nothing", November 2018.
[Diffie76] [Diffie76]
Diffie, W. and M. Hellman, "New Directions in Diffie, W. and M. Hellman, "New Directions in
Cryptography", November 1976. Cryptography", November 1976.
[draft-hallambaker-dare-container] [draft-hallambaker-mesh-dare]
Hallam-Baker, P., "Data At Rest Encryption Part 2: DARE Hallam-Baker, P., "Mathematical Mesh 3.0 Part III : Data
Container", draft-hallambaker-dare-container-02 (work in At Rest Encryption (DARE)", draft-hallambaker-mesh-dare-02
progress), August 2018. (work in progress), July 2019.
[draft-hallambaker-sin]
Hallam-Baker, P., "Strong Internet Names (SIN)", draft-
hallambaker-sin-03 (work in progress), April 2018.
[draft-hallambaker-udf] [draft-hallambaker-mesh-udf]
Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- Hallam-Baker, P., "Mathematical Mesh 3.0 Part II: Uniform
hallambaker-udf-12 (work in progress), January 2019. Data Fingerprint.", draft-hallambaker-mesh-udf-03 (work in
progress), July 2019.
[Haber91] Haber, S. and W. Stornetta, "How to Time-Stamp a Digital [Haber91] Haber, S. and W. Stornetta, "How to Time-Stamp a Digital
Document", 1991. Document", 1991.
[Intel2018] [Intel2018]
Bell, L., "Intel delays 10nm Cannon Lake processors, Bell, L., "Intel delays 10nm Cannon Lake processors,
again, until late 2019", July 2018. again, until late 2019", July 2018.
[Kohnfelder78] [Kohnfelder78]
Kohnfelder, L., "Towards a Practical Public-Key Kohnfelder, L., "Towards a Practical Public-Key
skipping to change at page 25, line 45 skipping to change at page 26, line 13
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.
[Schneier2013] [Schneier2013]
Schneier, B., "Defending Against Crypto Backdoors", Schneier, B., "Defending Against Crypto Backdoors",
October 2013. October 2013.
[Shannon1949] [Shannon1949]
Shannon, C., "Communication Theory of Secrecy Systems", Shannon, C., "Communication Theory of Secrecy Systems",
1949. 1949.
6.3. URIs 7.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html
Author's Address Author's Address
Phillip Hallam-Baker Phillip Hallam-Baker
Email: phill@hallambaker.com Email: phill@hallambaker.com
 End of changes. 16 change blocks. 
27 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/