[gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Michał Górny]

Hi,

GLEP 63 originally did not include a rationale.  Given the importance
of this document, I think it would be reasonable to include one and use
the opportunity to explain the policies in detail.

--
Best regards,
Michał Górny

Michał Górny (3):
  glep-0063: Remove unused references
  glep-0063: Reorder references to match document order
  glep-0063: Include a rationale

 glep-0063.rst | 140 ++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 131 insertions(+), 9 deletions(-)

-- 
2.18.0

[gentoo-dev] [PATCH 1/3] glep-0063: Remove unused references

[Michał Górny]

---
 glep-0063.rst | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 64fb437..c783910 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -163,9 +163,6 @@ References
 .. [#DEBIANGPG] Debian GPG documentation
    (https://wiki.debian.org/Keysigning)
 
-.. [#EKAIA] Ana's blog: Creating a new GPG key
-   (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/)
-
 .. [#RISEUP] RiseUp.net OpenPGP best practices
    (https://help.riseup.net/en/security/message-security/openpgp/best-practices)
 
@@ -183,10 +180,6 @@ References
    Part 2: Best Practices for Key Management Organization
    (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)
 
-.. [#ISSUER-ANNOTATE] Including the entire fingerprint of the issuer
-  in an OpenPGP certification
-  (http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)
-
 .. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report,
    2013 recommendations, version 1.0 (October 2013)
    (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)
-- 
2.18.0

[gentoo-dev] [PATCH 2/3] glep-0063: Reorder references to match document order

[Michał Górny]

---
 glep-0063.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index c783910..e40ddd3 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -160,12 +160,6 @@ References
 .. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
    (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)
 
-.. [#DEBIANGPG] Debian GPG documentation
-   (https://wiki.debian.org/Keysigning)
-
-.. [#RISEUP] RiseUp.net OpenPGP best practices
-   (https://help.riseup.net/en/security/message-security/openpgp/best-practices)
-
 .. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
    (http://devmanual.gentoo.org/general-concepts/manifest/index.html)
 
@@ -180,6 +174,12 @@ References
    Part 2: Best Practices for Key Management Organization
    (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)
 
+.. [#DEBIANGPG] Debian GPG documentation
+   (https://wiki.debian.org/Keysigning)
+
+.. [#RISEUP] RiseUp.net OpenPGP best practices
+   (https://help.riseup.net/en/security/message-security/openpgp/best-practices)
+
 .. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report,
    2013 recommendations, version 1.0 (October 2013)
    (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)
-- 
2.18.0

[gentoo-dev] [PATCH 3/3] glep-0063: Include a rationale

[Michał Górny]

---
 glep-0063.rst | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 129 insertions(+)

diff --git a/glep-0063.rst b/glep-0063.rst
index e40ddd3..cab52b0 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -132,6 +132,122 @@ of the fingerprint field. In any place that presently displays
 the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
 be displayed instead.
 
+Rationale
+=========
+
+Foreword
+--------
+
+This policy aims to provide a good set of OpenPGP usage policies both
+to protect Gentoo resources from unauthorized access and to protect developer
+identities from being spoofed.  The former is significant since it could
+be used to deliver malicious content to Gentoo users; the latter because
+it could be used to damage the reputation of Gentoo.
+
+Separate signing subkey
+-----------------------
+
+The specification requires that a separate subkey is used for signing.  This
+is a subset of more general recommendation of using the primary key only for
+the purpose of important key operations and storing it offline, while using
+separate subkeys for day-to-day operations.
+
+The main purpose of this is to reduce the attack surface.  By reducing the use
+of primary key and keeping it offline, the risk of attacks against it is
+reduced.  If the attacker manages to compromise the developer's keyring, only
+subkeys are compromised and the developer can revoke them without having
+the whole key compromised.
+
+Furthermore, the specification requires separate subkeys for different
+purposes.  This is a generally agreed on practice (e.g. GnuPG defaults to
+using a separate encryption key) aiming to further reduce the attack surface.
+Kristian Fiskerstrand points out e.g. it is technically possible to obtain
+a valid signature over crafted data while using the subkey for purposes
+of authorization  [#COUNCIL-MEETING-20180729]_.
+
+Revocation certificate
+----------------------
+
+The specification recommends the best practice of storing a copy
+of the revocation certificate off site.  A common recommendation is to have
+the ASCII-armored version of the certificate printed on paper, to protect
+against hardware failures (but beware that print servers may store a copy
+of the data!).
+
+The goal of the revocation certificate is to provide the developer with
+ability to revoke the key in case the access to it is lost, e.g. due to
+hardware damage combined with lack of backups, major events resulting
+in backups being destroyed as well, or more importantly in the event
+of hardware being stolen or lost.
+
+Key algorithm and length
+------------------------
+
+The choice of key algorithm and length defines the resistance of the key
+against brute-force attacks.
+
+Originally, the specification permitted using DSA keys.  However, there is no
+compelling reason to continue using DSA.  According to the GnuPG FAQ, RSA has
+much wider support in smart-card solutions [#GNUPG-FAQ-11-1]_.  Furthermore,
+the RFC 4880bis draft removes the requirement of DSA support in clients favor
+of obligatory RSA (and ECDSA) support [#RFC4880bis]_.
+
+The RSA algorithm is recommended as it is considered secure at the moment
+and provides for the best interoperability.  The 2048-bit key length
+is considered sufficiently secure for all our uses.  Historically, this
+specification recommended 4096-bit keys.  However, while longer keys are still
+permitted, they are no longer recommended as they give little in regards
+to security, yet are capable of causing performance problems, especially
+when using external hardware [#GNUPG-FAQ-11-4]_.
+
+Additionally, elliptic curve algorithms using Curve 25519 are allowed.
+However, they are not recommended due to compatibility concerns
+(in particular, not being supported by GnuPG prior to 2.1).
+The remaining curves supported by GnuPG (and appropriately listed
+in RFC 4880bis draft) are not allowed since there are concerns about safety
+of those curves [#SAFECURVES]_.
+
+Key expiration
+--------------
+
+It is important to note that the expiration dates as required by this
+specification are not to be conflated with key rotation.  This specification
+does not enforce any specific key rotation scheme; expiration serves purely
+the purpose of requiring periodic prolongation.
+
+This policy serves two purposes.  Firstly, it provides a last fallback option
+in the event of access to the secret keys being lost and there being
+no possibility of revoking them.  In this case, the keys eventually expire
+and users can clearly see that they are no longer being used.  Secondly, it
+ensures that the developers periodically confirm their access to the primary
+key.
+
+The expiration period has been chosen as a matter of compromise between being
+secure and causing major trouble to developers keeping keys in secure vaults.
+The period of 900 days represents the baseline of 2 years with roughly half
+a year grace period for extending the expiration date early.  Specifying it
+in days makes it possible to automatically verify it without having to account
+for different lengths of year.
+
+Additionally, the specification requires renewing the key at least two weeks
+before expiration.  This is meant to provide the developers early notice
+of upcoming expiration and provide time for both the users and Gentoo
+Infrastructure to refresh keys.
+
+Key distribution
+----------------
+
+The specification requires that the key used by the developer includes his
+@gentoo.org e-mail address in one of the UIDs, and the key is uploaded
+to the SKS keyservers.  This ensures that the developer keys can easily
+be found by the users.  Furthermore, the latter is also necessary
+for the Gentoo Infrastructure to fetch the key and its updates.
+
+Currently the specification does not specify establishing a Web of Trust
+between Gentoo developers.  While this is generally a good recommendation, it
+is not considered possible for all developers to be actually able to meet
+other developers, and no other solution has been agreed on so far.
+
 Backwards Compatibility
 =======================
 
@@ -160,6 +276,19 @@ References
 .. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
    (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)
 
+.. [#COUNCIL-MEETING-20180729] Gentoo Council 2018-07-29 meeting log
+   (https://projects.gentoo.org/council/meeting-logs/20180729.txt)
+
+.. [#GNUPG-FAQ-11-1] GnuPG FAQ: Which ciphers are recommended, and why?
+   (https://www.gnupg.org/faq/gnupg-faq.html#recommended_ciphers)
+
+.. [#RFC4880bis] OpenPGP Message Format; draft-ietf-openpgp-rfc4880bis-05
+   (https://tools.ietf.org/id/draft-ietf-openpgp-rfc4880bis-05.txt)
+
+.. [#SAFECURVES] Daniel J. Bernstein, Tanja Lange. SafeCurves: choosing
+   safe curves for elliptic-curve cryptography (as of 2018-08-04)
+   (https://safecurves.cr.yp.to/)
+
 .. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
    (http://devmanual.gentoo.org/general-concepts/manifest/index.html)
 
-- 
2.18.0

Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Ulrich Mueller]

>>>>> On Sat, 4 Aug 2018, Michał Górny wrote:

> GLEP 63 originally did not include a rationale. Given the importance
> of this document, I think it would be reasonable to include one and
> use the opportunity to explain the policies in detail.

The council just approved the updated GLEP 63 in its July meeting.

So this should either have been submitted as part of that update, or
you should at least have given notice to the council that further
changes are pending (as you were present during the meeting). In the
latter case, we may likely have postponed the decision about the GLEP
update, which wasn't entirely uncontroversial.

Ulrich

Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 3070 bytes --]

On 2018-08-04 14:34, Ulrich Mueller wrote:
> So this should either have been submitted as part of that update, or
> you should at least have given notice to the council that further
> changes are pending (as you were present during the meeting). In the
> latter case, we may likely have postponed the decision about the GLEP
> update, which wasn't entirely uncontroversial.

I agree but nevertheless I appreciate that someone (Michał in this case)
doesn't rest and continue to improve things.


Michał Górny wrote:
> +Furthermore, the specification requires separate subkeys for different
> +purposes.  This is a generally agreed on practice (e.g. GnuPG defaults to
> +using a separate encryption key) aiming to further reduce the attack surface.
> +Kristian Fiskerstrand points out e.g. it is technically possible to obtain
> +a valid signature over crafted data while using the subkey for purposes
> +of authorization  [#COUNCIL-MEETING-20180729]_.

I challenge this one:

If an attacker is already able to trick a developer into signing
something the developer didn't want to sign, the same attacker will also
be able to trick the same developer into using the right sub key the
attacker is actually interested in.

My point is: While I don't disagree that best practice should be an own
sub key for every purpose, arguing that this has an impact on security
is wrong. And that was and still is my reason why I don't want that this
is getting enforced.


Michał Górny wrote:
> +This policy serves two purposes.  Firstly, it provides a last fallback option
> +in the event of access to the secret keys being lost and there being
> +no possibility of revoking them.  In this case, the keys eventually expire
> +and users can clearly see that they are no longer being used.  Secondly, it
> +ensures that the developers periodically confirm their access to the primary
> +key.

And I am also challenging this one:

Given that this a policy for Gentoo, we have to take Gentoo specifics
into account:

In Gentoo the primary purpose of OpenGPG is to sign commits and push
operations. A git hook ensures that each commit and push is well signed
by a known key. However, this key is coming from Gentoo's LDAP. LDAP is
accessed via SSH key. So anyone with access to a developer's SSH key is
able to add an additional (malicious) key which would be picked up by
other automated processes with the result that whoever is in control of
that additional key could now use it to commit and push to any Gentoo
repositories.

In this process, an expiration date isn't really used. Again, it is best
practice but when we don't use it, why do we care and enforce such a value?

Well, if you take the *now* proposed "Foreword" into account I *could*
arrange with such a statement because expiration date plays a role in
the web of trust and GLEP 63 seems to be more than just a OpenGPG policy
for commit/push.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

W dniu sob, 04.08.2018 o godzinie 14∶34 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 4 Aug 2018, Michał Górny wrote:
> > GLEP 63 originally did not include a rationale. Given the importance
> > of this document, I think it would be reasonable to include one and
> > use the opportunity to explain the policies in detail.
> 
> The council just approved the updated GLEP 63 in its July meeting.
> 
> So this should either have been submitted as part of that update, or
> you should at least have given notice to the council that further
> changes are pending (as you were present during the meeting). In the
> latter case, we may likely have postponed the decision about the GLEP
> update, which wasn't entirely uncontroversial.
> 

This wasn't planned.  I was writing a blog post yesterday, and it
occurred to me that I could extend it into the rationale for this GLEP.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3490 bytes --]

On Sat, 2018-08-04 at 16:57 +0200, Thomas Deutschmann wrote:
> On 2018-08-04 14:34, Ulrich Mueller wrote:
> > So this should either have been submitted as part of that update, or
> > you should at least have given notice to the council that further
> > changes are pending (as you were present during the meeting). In the
> > latter case, we may likely have postponed the decision about the GLEP
> > update, which wasn't entirely uncontroversial.
> 
> I agree but nevertheless I appreciate that someone (Michał in this case)
> doesn't rest and continue to improve things.
> 
> 
> Michał Górny wrote:
> > +Furthermore, the specification requires separate subkeys for different
> > +purposes.  This is a generally agreed on practice (e.g. GnuPG defaults to
> > +using a separate encryption key) aiming to further reduce the attack surface.
> > +Kristian Fiskerstrand points out e.g. it is technically possible to obtain
> > +a valid signature over crafted data while using the subkey for purposes
> > +of authorization  [#COUNCIL-MEETING-20180729]_.
> 
> I challenge this one:
> 
> If an attacker is already able to trick a developer into signing
> something the developer didn't want to sign, the same attacker will also
> be able to trick the same developer into using the right sub key the
> attacker is actually interested in.
> 
> My point is: While I don't disagree that best practice should be an own
> sub key for every purpose, arguing that this has an impact on security
> is wrong. And that was and still is my reason why I don't want that this
> is getting enforced.

I defer this to Kristian.  He knows the GnuPG internals much better than
I do.

> Michał Górny wrote:
> > +This policy serves two purposes.  Firstly, it provides a last fallback option
> > +in the event of access to the secret keys being lost and there being
> > +no possibility of revoking them.  In this case, the keys eventually expire
> > +and users can clearly see that they are no longer being used.  Secondly, it
> > +ensures that the developers periodically confirm their access to the primary
> > +key.
> 
> And I am also challenging this one:
> 
> Given that this a policy for Gentoo, we have to take Gentoo specifics
> into account:
> 
> In Gentoo the primary purpose of OpenGPG is to sign commits and push
> operations. A git hook ensures that each commit and push is well signed
> by a known key. However, this key is coming from Gentoo's LDAP. LDAP is
> accessed via SSH key. So anyone with access to a developer's SSH key is
> able to add an additional (malicious) key which would be picked up by
> other automated processes with the result that whoever is in control of
> that additional key could now use it to commit and push to any Gentoo
> repositories.
> 
> In this process, an expiration date isn't really used. Again, it is best
> practice but when we don't use it, why do we care and enforce such a value?
> 
> Well, if you take the *now* proposed "Foreword" into account I *could*
> arrange with such a statement because expiration date plays a role in
> the web of trust and GLEP 63 seems to be more than just a OpenGPG policy
> for commit/push.

Most of the developers are always signing their mails using their
OpenPGP keys.  In fact, mail signing preceded Manifest signing, not to
mention the migration to git.  Why would suddenly its purpose
be reduced to just commits?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]