Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

On 13/06/18 14:43, Daniel Kahn Gillmor wrote:
> the proposed revocation distribution network wouldn't allow any user IDs
> or third-party certifications, so most of the "trollwot" would not be
> relevant.

As I see it, the keyservers perform two related but distinct functions -
finding unknown keys by UID, and finding updates to known keys by
fingerprint.

All the current issues are related to the first function, but the first
function has several alternative solutions available (DNS, WKD, Keybase,
attaching pubkeys to every email...). If this first function were to
fail overnight, it would be an inconvenience but not a disaster.

But there is no known alternative to the second function, which is the
distribution of key updates, including revocations. Therefore I believe
the immediate priority should be to protect update distribution.

How to prevent abuse of a distributed, unauthenticated store of
arbitrary data remains an unsolved problem (see: usenet). If the
keyservers are to remain unauthenticated and distributed, then the only
option is to prohibit arbitrary data. That means no arbitrary data
fields (i.e. no UIDs) and no arbitrary data in structured data fields
(i.e. validity checks on self-sigs). This will shrink the size of the
database significantly, but impose some processing cost.

There are two ways forward: a new network of key-material-only servers,
or restricting the existing network to key material only. In the first
case, we would still need a means to propagate keys between the old and
new networks during the transition. And in the second case, we would
need to handle an intermediate state where only some servers have been
upgraded to the new version.

So no matter what we do, we will still need to have some method of doing
fake recon with legacy sks instances. The question is how to arrive at
this state most efficiently. I would suggest that since recon is at the
root of the problems, we should concentrate on the recon process itself.
If uploading a bad key takes down one server then fine, we can lose one
server. But the badness must not infect other servers automatically.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote:
> On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
>> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>>> thanks for this post Daniel, my primary question would be what advantage
>>> is gained by this verification being done by an arbitrary third party
>>> rather by a trusted client running locally, which is the current modus
>>> operandus. Any keyserver action doing this would just shift
>>> responsibilities to a third party for something better served (and
>>> already happens) locally.
>> 
>> the advantage is spam-abatement -- the keyservers have to keep track of
>> what is attached to each blob they transport/persist.  if all signatures
>> that they transport for a given blob are cryptographically certified,
>> then only the original uploader of that blob can make assertions about
>> it; other people can't spam the blob to make it untransportable.
>
> All the certificates used in trollwot are technically correct. You can
> still use the same mechanisms as you control the other key material, and
> can use intentionally weak key material if wanting to speed things up.

sorry for the blast from the past here, but in re-reading this thread, i
thought i'd follow up on this.

the proposed revocation distribution network wouldn't allow any user IDs
or third-party certifications, so most of the "trollwot" would not be
relevant.

if someone wants to upload their own key and make it unfetchable by
appending garbage to it, that's probably OK (at least, it's a strict
improvement than the current situation, which is that they can append
garbage to *any* key).  and if they use weak key material (or publish
the secret someplace), then sure it's a noisy blob that anyone can
append to.  But no one will care, because they aren't likely to be
relying on that key.

does that make sense as to why this proposal is potentially useful?

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers

[Daniel Kahn Gillmor]

On Wed 2018-01-17 15:51:07 +, Andrew Gallagher wrote:
> On 17/01/18 15:32, Daniel Kahn Gillmor wrote:
>> i don't think you need an extension to OpenPGP at all to do this -- you
>> just need policy.  The policy could be (for example):
>
> The main technical question is where should this policy be applied?

read in the context of the discussion in the thread (i know -- it's 90
messages long, hard to keep up!), we're talking about a parallel
keyserver network here, so the policy would be applied at upload time
(which also means it happens at "replication" time).

> 3. At search/display stage - almost as easy as 1, although more
> computationally intensive as it would need to be calculated per download
> (caching may help). Can be retrofitted to existing keyservers.

I think a better way to consider retrofitting to existing keyservers
would be if existing keyservers could maintain the idea of two
filtersets concurrently.  then, if they're gossiping with a peer who
insists on filterset A (the existing dominant filterset), they work only
with the certificate material that belongs to that particular filterset.

if they're gossiping with a peer who can do the new constrained
filterset (we'll call it B), then they work only with the certificate
material that belongs to that filterset.  but internally they know about
the union of all of that certificate material.

If we had a few keyservers capable of that kind of operation with both A
and B, then we could keep the B-only keyservers in sync during a
migration.

sadly, i don't have such an implementation and i don't know how to do
that work in the time i have available.

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers

[Andrew Gallagher]

On 17/01/18 15:32, Daniel Kahn Gillmor wrote:
> i don't think you need an extension to OpenPGP at all to do this -- you
> just need policy.  The policy could be (for example):

The main technical question is where should this policy be applied?

1. At upload stage - easy to implement, but requires all keyservers to
cooperate. It also means starting from an empty set, effectively
building a parallel keyserver network from scratch.

2. At replication stage - this would be effective, but to the best of
our knowledge would cripple the algorithm.

3. At search/display stage - almost as easy as 1, although more
computationally intensive as it would need to be calculated per download
(caching may help). Can be retrofitted to existing keyservers.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers

[Daniel Kahn Gillmor]

On Wed 2018-01-17 09:58:21 +0100, Werner Koch wrote:
> On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com
> said:
>
>>>  (c) rejected all third-party certifications -- so data attached to a
>>>  given primary key is only accepted when certified by that primary
>>>  key.
>>> 
>>
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>
> This can help to avoid DoS attacks.  I would love to see that to get my
> key down to a reasonable size. 
>
> OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag:
>
>First octet: 0x80 = No-modify the key holder requests that this key
>only be modified or updated by the key holder or an administrator of
>the key server.
>
> By default GnuPG sets this flag but unfortunately it has no effect
> because it is not defined on how the keyserver can check this condition.

please see also the thread on sks-devel from december 2016 with the
subject "nokeyserver annotation" -- if we're designing a new, parallel,
more narrowly-focused keyserver network we should make sure to include
that as well.

> A way to implement this without requiring an external protocol would be
> an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26)
> in a key signature.  With ECC this would not increase the size of a key
> signature too much.  It puts a burden on the keyservers to check this
> signature during an upload, though.

I think you're describing a way to permit such a narrowly-scoped
keyserver to be slightly more broad -- to allow third-party
certifications to be published.

i don't think you need an extension to OpenPGP at all to do this -- you
just need policy.  The policy could be (for example):

 * if a third-party certification is present, discard it unless all of
   the following are true:

   a) it has the "issuer fingerprint" subpacket in the hashed subpackets
   
   b) the issuing key is itself is known to the keyserver
   
   c) the certification is cryptographically correct

   d) there is an Embedded Signature subpacket in the unhashed
  subpackets from the primary key, over the existing signature
  *with unhashed subpackets discarded*

   e) the embedded signature is cryptographically valid

but the simplest thing would be to start without third-party
certifications at all -- making this strictly for self-certification
updates (expiry, revocation, key-rotation).

wdyt?

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers

[Teemu Likonen]

Werner Koch [2018-01-17 09:58:21+01] wrote:

>>>  (c) rejected all third-party certifications -- so data attached to
>>>  a given primary key is only accepted when certified by that primary
>>>  key.

> This can help to avoid DoS attacks. I would love to see that to get my
> key down to a reasonable size.

Not quite related but... I tend to think that on client side it would be
good idea to "clean" by default. (I like to do that.)

keyserver-options import-clean,export-clean

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers

[Werner Koch]

On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com
said:

>>  (c) rejected all third-party certifications -- so data attached to a
>>  given primary key is only accepted when certified by that primary
>>  key.
>> 
>
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party

This can help to avoid DoS attacks.  I would love to see that to get my
key down to a reasonable size. 

OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag:

   First octet: 0x80 = No-modify the key holder requests that this key
   only be modified or updated by the key holder or an administrator of
   the key server.

By default GnuPG sets this flag but unfortunately it has no effect
because it is not defined on how the keyserver can check this condition.

A way to implement this without requiring an external protocol would be
an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26)
in a key signature.  With ECC this would not increase the size of a key
signature too much.  It puts a burden on the keyservers to check this
signature during an upload, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpjMoDIr4efZ.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>> rather by a trusted client running locally, which is the current modus
>> operandus. Any keyserver action doing this would just shift
>> responsibilities to a third party for something better served (and
>> already happens) locally.
> 
> the advantage is spam-abatement -- the keyservers have to keep track of
> what is attached to each blob they transport/persist.  if all signatures
> that they transport for a given blob are cryptographically certified,
> then only the original uploader of that blob can make assertions about
> it; other people can't spam the blob to make it untransportable.

All the certificates used in trollwot are technically correct. You can
still use the same mechanisms as you control the other key material, and
can use intentionally weak key material if wanting to speed things up.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"We all die. The goal isn't to live forever, the goal is to create
something that will."
(Chuck Palahniuk)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

the advantage is spam-abatement -- the keyservers have to keep track of
what is attached to each blob they transport/persist.  if all signatures
that they transport for a given blob are cryptographically certified,
then only the original uploader of that blob can make assertions about
it; other people can't spam the blob to make it untransportable.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

> On 16 Jan 2018, at 22:26, Leo Gaspard  wrote:
> 
> It could also help limit the impact of the nightmare scenario RJH has
> described, by making sure all the data is “cryptographically valid and
> matching”, thus making it harder to just propagate arbitrary data down
> the network.

It would make it *very* slightly more computationally expensive to pull off, 
but would not limit the impact one bit. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Leo Gaspard]

On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote:
> On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:
> 
>> The keyserver network (or some future variant of it) can of course play
>> a role in parallel to any or all of these.  for example, keyservers are
>> particularly well-situated to offer key revocation, updates to expiry,
>> and subkey rotation, none of which would necessarily involve names or
>> e-mail addresses.
>>
>> It would be interesting to see a network of keyserver operators that:
>>
>>  (a) did cryptographic verification, and rejected packets that could not
>>  be verified (also: required cryptographic verifications of
>>  cross-signatures for signing-capable subkeys)
>>
>>  (b) rejected all User IDs and User Attributes and certifications over
>>  those components
>>
>>  (c) rejected all third-party certifications -- so data attached to a
>>  given primary key is only accepted when certified by that primary
>>  key.
>>
> 
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

I guess one argument could be “when lazy people use the keyserver
network, they likely get not-too-bad data”.

I seem to remember that when a keyserver returned multiple keys to
GnuPG, GnuPG imported both, even when searching for a fingerprint and
the fingerprint didn't match, at some point in the last few years? If
even GnuPG can fail at properly sanitizing the data received by
keyservers (and I hope I'm not mistaken in this memory), I guess having
such keyservers only serve curated data when used in their “nominal” use
could help a bit.

It could also help limit the impact of the nightmare scenario RJH has
described, by making sure all the data is “cryptographically valid and
matching”, thus making it harder to just propagate arbitrary data down
the network. Then I don't have the structure of an OpenPGP key in mind,
so maybe this would not work due to fields in the key that could be set
to arbitrary data anyways

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:

> The keyserver network (or some future variant of it) can of course play
> a role in parallel to any or all of these.  for example, keyservers are
> particularly well-situated to offer key revocation, updates to expiry,
> and subkey rotation, none of which would necessarily involve names or
> e-mail addresses.
> 
> It would be interesting to see a network of keyserver operators that:
> 
>  (a) did cryptographic verification, and rejected packets that could not
>  be verified (also: required cryptographic verifications of
>  cross-signatures for signing-capable subkeys)
> 
>  (b) rejected all User IDs and User Attributes and certifications over
>  those components
> 
>  (c) rejected all third-party certifications -- so data attached to a
>  given primary key is only accepted when certified by that primary
>  key.
> 

thanks for this post Daniel, my primary question would be what advantage
is gained by this verification being done by an arbitrary third party
rather by a trusted client running locally, which is the current modus
operandus. Any keyserver action doing this would just shift
responsibilities to a third party for something better served (and
already happens) locally.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Bene diagnoscitur, bene curatur
Something that is well diagnosed can be cured well



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users