Git authentication reports subkey fingerprints

OpenSubmitted by Ludovic Courtès.
Details
3 participants
  • Ludovic Courtès
  • Maxime Devos
  • Tobias Geerinckx-Rice
Owner
unassigned
Severity
normal
L
L
Ludovic Courtès wrote on 9 Aug 23:07 +0200
(address . bug-guix@gnu.org)
87iln12kjc.fsf@inria.fr
Hello,

As Tobias explains at
as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
git-authenticate) machinery reports the fingerprint of subkeys on
signatures (when subkeys are used) rather than the fingerprint of
primary keys.

This should be changed to report primary keys, at least optionally.

Ludo’.
M
M
Maxime Devos wrote on 9 Aug 23:20 +0200
78149f79-5620-fae9-1ba3-4ed25c2154c5@telenet.be
On 09-08-2022 23:07, Ludovic Courtès wrote:
Toggle quote (10 lines)
> Hello,
>
> As Tobias explains at
> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html> and
> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
> git-authenticate) machinery reports the fingerprint of subkeys on
> signatures (when subkeys are used) rather than the fingerprint of
> primary keys.
>
> This should be changed to report primary keys, at least optionally.
Why should it be changed? IIUC .guix-authorizations and (guix ...) care
about the key that things were signed with, not necessarily the primary
key, so it seems to me that it needs to report the subkey fingerprint,
not the fingerprint of the primary key it belongs to, as the primary key
is irrelevant to them IIUC.
Greetings,
Maxime.
Attachment: OpenPGP_signature
L
L
Ludovic Courtès wrote on 11 Aug 12:24 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 57091@debbugs.gnu.org)
878rnvxelk.fsf@gnu.org
Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (18 lines)
> On 09-08-2022 23:07, Ludovic Courtès wrote:
>> Hello,
>>
>> As Tobias explains at
>> <https://mail.gnu.org/archive/html/help-guix/2022-08/msg00073.html> and
>> as can be seen from ‘.guix-authorizations’, the (guix openpgp) and (guix
>> git-authenticate) machinery reports the fingerprint of subkeys on
>> signatures (when subkeys are used) rather than the fingerprint of
>> primary keys.
>>
>> This should be changed to report primary keys, at least optionally.
>
> Why should it be changed? IIUC .guix-authorizations and (guix ...)
> care about the key that things were signed with, not necessarily the
> primary key, so it seems to me that it needs to report the subkey
> fingerprint, not the fingerprint of the primary key it belongs to, as
> the primary key is irrelevant to them IIUC.

Yes, I kinda agree, but… the motivation here is that OpenPGP user
interfaces don’t normally refer to subkey fingerprints; instead they
refer to primary key fingerprints, even if you use a subkey, which is
the point of subkeys AIUI. That Guix treats subkeys differently is
confusing to seasoned OpenPGP users.

Ludo’.
T
T
Tobias Geerinckx-Rice wrote on 11 Aug 13:17 +0200
(address . 57091@debbugs.gnu.org)
5330DDA4-F1AD-4F99-B6A5-5CDA2D975983@tobias.gr
This is not a mere UI issue. Basic verification is currently broke^Wdifferent, too, or the latest incident wouldn't have happened.

Hmm. I wonder...

Ludo', are you worried that, since we already handle revocations like GPG would, the 'proper' OpenPGPmodel could somehow break? That we are in effect unable to safely fix this (yes, I maintain it is a) bug?

Apologies if I'm wildly off the mark here. But then I'd like to hear some plausible threat models. Maxime?

In their absence, nasty surprises like what happened last week are argument enough to (try to! :-) implement normal OpenPGP behaviour.



Kind regards,

T G-R

Sent on the go. Excuse above-average rambliness.
T
T
Tobias Geerinckx-Rice wrote on 11 Aug 13:33 +0200
(address . 57091@debbugs.gnu.org)
9698A0FA-29C8-46F1-977A-202CBE81E90B@tobias.gr
Of all the stupid typos...

Toggle quote (2 lines)
>Ludo', are you worried that, since we already handle revocations like GPG would

...DON'T handle, of course, by design.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
M
M
Maxime Devos wrote on 11 Aug 17:07 +0200
(address . 57091@debbugs.gnu.org)
fc12e652-af4b-c107-c8cb-06730f75f084@telenet.be
On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:
Toggle quote (1 lines)
> Apologies if I'm wildly off the mark here. But then I'd like to hear some plausible threat models. Maxime?
Here's a problem with allowing subkeys, if that's what you mean:
* Expiration times and GPG-level revocation must be ignored (for
time-travel, and pulling from an old Guix), similarly to why it must
be ignored for when no subkeys are used
* Someone used to GPG-style subkeys generates a new subkey to replace
old expired subkey or revokes old subkey, without keeping in mind
that Guix doesn't take that in account.
* An attacker uses a compromised-but-revoked-or-expired subkey to
compromise the channel.
Expiration times might be solvable by taking the commit time of the
previous commit as 'current time' (not the commit that was signed,
otherwise an attacker could just lie). I don't know a solution for
GPG-level revocation of old subkeys but I haven't looked either.
Another problem:
* When replacing the key in the 'keyring' branch with an 'updated' key
that contains the new subkey, we have to be careful to never remove
old subkeys, to avoid breaking time travel or pulling from old versions.
Greetings,
Maxime.
Attachment: file
Attachment: OpenPGP_signature
T
T
Tobias Geerinckx-Rice wrote on 11 Aug 18:31 +0200
(name . Maxime Devos)(address . maximedevos@telenet.be)
c7478dba8725cc173d443cb5172f3279@tobias.gr
Hi Maxime,

Quick reply mainly to say thanks for replying :-)

On 2022-08-11 17:07, Maxime Devos wrote:
Toggle quote (7 lines)
> On 11-08-2022 13:17, Tobias Geerinckx-Rice wrote:
>
>> Apologies if I'm wildly off the mark here. But then I'd like to
>> hear some plausible threat models. Maxime?
>
> Here's a problem with allowing subkeys, if that's what you mean:

(Well, you snipped my previous paragraph where I mention what you seem
to describe below, so yes.)

Toggle quote (9 lines)
> * Expiration times and GPG-level revocation must be ignored (for
> time-travel, and pulling from an old Guix), similarly to why it must
> be ignored for when no subkeys are used
> * Someone used to GPG-style subkeys generates a new subkey to
> replace old expired subkey or revokes old subkey, without keeping in
> mind that Guix doesn't take that in account.
> * An attacker uses a compromised-but-revoked-or-expired subkey to
> compromise the channel.

Why does none of this apply to primary keys?

Toggle quote (5 lines)
> Expiration times might be solvable by taking the commit time of the
> previous commit as 'current time' (not the commit that was signed,
> otherwise an attacker could just lie). I don't know a solution for
> GPG-level revocation of old subkeys but I haven't looked either.

Git commit dates aren't reliable. Requiring that they be accurate going
forward would be imposing yet another 'artificial'/idiosyncratic
limitation. I think we should be very hesitant to build a verification
system on assumptions stacked just so.

Toggle quote (7 lines)
> Another problem:
>
> * When replacing the key in the 'keyring' branch with an 'updated'
> key that contains the new subkey, we have to be careful to never
> remove old subkeys, to avoid breaking time travel or pulling from old
> versions.

Sure. We always need to be careful when updating the keyring branch.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.
M
M
Maxime Devos wrote on 11 Aug 20:10 +0200
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
95099292-6aeb-1ef2-ce96-0f216ac9b93f@telenet.be
On 11-08-2022 18:31, Tobias Geerinckx-Rice wrote:
Toggle quote (10 lines)
>>     * Expiration times and GPG-level revocation must be ignored (for
>> time-travel, and pulling from an old Guix), similarly to why it must
>> be ignored for when no subkeys are used
>>      * Someone used to GPG-style subkeys generates a new subkey to
>> replace old expired subkey or revokes old subkey, without keeping in
>> mind that Guix doesn't take that in account.
>>      * An attacker uses a compromised-but-revoked-or-expired subkey to
>> compromise the channel.
>
> Why does none of this apply to primary keys?
For primary keys as they are currently used in Guix, to revoke a key
(from Guix' point of view), you remove it from .guix-authorizations, done.
For revoking subkeys, you trust GPG or whatever to take care of things,
but Guix-modified-to-allow-subkeys-too doesn't have a clue that the
subkey should be considered revoked, se bullet list above.
That could be solved by also adding a list of revoked subkeys to
.guix-authorization, but that seems opposite to the proposed change.
Toggle quote (9 lines)
>> Expiration times might be solvable by taking the commit time of the
>> previous commit as 'current time' (not the commit that was signed,
>> otherwise an attacker could just lie). I don't know a solution for
>> GPG-level revocation of old subkeys but I haven't looked either.
>
> Git commit dates aren't reliable.  Requiring that they be accurate
> going forward would be imposing yet another 'artificial'/idiosyncratic
> limitation.  I think we should be very hesitant to build a
> verification system on assumptions stacked just so.
Yes, forbidding setting the datetime to something way off (e.g.
1970-01-01) for privacy or such is quite a limitation.
They do not have to be accurate however, as long as the discrepancies in
commit dates / actual time (*) are small compared to the expiration times.
(*) of non-attackers -- assuming frequent commits, an attacker cannot
trick the expiration mechanism into large time difference. That might
not be good enough for branches like 'wip-foo' or channels with
infrequent commits though.
Greetings,
Maxime.
Attachment: file
Attachment: OpenPGP_signature
?