Strategy for the upgrade of weak PGP keys?

Dear Julien,

Post by Julien ÃLIE
Is there a current strategy to deal with weak PGP keys that are
currently used to sign control articles and no longer accepted by recent
GnuPG versions?
Shouldn't news administrators still sending control articles with such
weak PGP keys generate a new key as soon as possible and begin to send
control articles in double during a few years? (one control article
signed with the old key for legacy systems, and one with the new secure key)
Most hierarchies are concerned, according to an article from
Bowling). Only 15 successfully imported keys out of 104 with GnuPG 2.1 !
One has to switch to old GnuPG 1.x versions, which one day won't be
supported any longer...

Thanks for bringing this up. The issue is something that the recently
reconstituted Big-8 Management Board has been discussing, at least
insofar as it relates to the control messages that the Board itself
needs to sign. But you're right that this is a more general problem.
We're working on a solution.

Regards,
Tristan

--
Usenet Big-8 Management Board
***@big-8.org

Matthew Vernon

2020-05-20 13:21:04 UTC

Post by Tristan Miller
Dear Julien,

My uk.* Control hat is worried about this too - I could make a new key
and (probably!) adjust the perl lashup that runs uk.* to sign with both
keys, but the real problem is getting "enough" admins to start trusting
the new key (and not the old one any more).

My feeling is that a co-ordinated effort to get "active" heirarchies to
produce new keys and have them rolled out in an easy-to-consume way for
news admins so admins don't have to do more than one or two simple
actions is probably the only chance we have of getting a critical mass
of servers using the new keys. B-8MB are perhaps the right people to do
that co-ordination?

Matthew

--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life

Tristan Miller

2020-05-20 14:45:33 UTC

Dear Matthew,

Post by Tristan Miller

My uk.* Control hat is worried about this too - I could make a new key
and (probably!) adjust the perl lashup that runs uk.* to sign with both
keys, but the real problem is getting "enough" admins to start trusting
the new key (and not the old one any more).
My feeling is that a co-ordinated effort to get "active" heirarchies to
produce new keys and have them rolled out in an easy-to-consume way for
news admins so admins don't have to do more than one or two simple
actions is probably the only chance we have of getting a critical mass
of servers using the new keys. B-8MB are perhaps the right people to do
that co-ordination?

We'e only recently reconstituted the Board after a long period of
dormancy and are currently busy trying to get all the technical and
administrative infrastructure back up and running. But part of this
process has involved (and will continue to involve) getting in touch
with news admins to verify that they're following the correct
instructions for fetching group lists, verifying control messages, etc.
We can't promise that we'll be able to do this on behalf of other
hierarchies, but at the very least we can report on our experiences for
the hierarchies that we manage.

Regards,
Tristan

--
Usenet Big-8 Management Board
***@big-8.org

Russ Allbery

2020-05-20 18:31:26 UTC

Post by Matthew Vernon
My feeling is that a co-ordinated effort to get "active" heirarchies to
produce new keys and have them rolled out in an easy-to-consume way for
news admins so admins don't have to do more than one or two simple
actions is probably the only chance we have of getting a critical mass
of servers using the new keys. B-8MB are perhaps the right people to do
that co-ordination?

It would also be nice if someone with time could do a bit of a survey of
supported software and key strengths and whatnot and recommend what to
use. My guess is that everyone could just use 2048-bit RSA keys generated
with GnuPG v2 (to pick up the current ancillary settings) and it would
probably be fine, but is there anything in there that's going to break on
some old system that only has GnuPG v1? (Do we even care?)

Is anyone worried that 2048-bit RSA is not strong enough given how much of
a pain it is to replace keys and thus how long of an expected lifetime we
would like them to have? They're probably not quantum-safe (not that I
really expect anyone to waste quantum computing cycles on breaking Usenet
control messages). (Is there even a quantum-resistant public key
algorithm? ed25519 isn't quantum-resistant either, I believe.)

It would probably also be a good idea to provide a simpler mechanism to
quickly construct a keyring of known hierarchies. I have all the
machinery available to build such a thing, but the instructions for a news
admin are a bit awkward.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Richard Kettlewell

2020-05-21 08:16:19 UTC

Post by Matthew Vernon
My feeling is that a co-ordinated effort to get "active" heirarchies
to produce new keys and have them rolled out in an easy-to-consume
way for news admins so admins don't have to do more than one or two
simple actions is probably the only chance we have of getting a
critical mass of servers using the new keys. B-8MB are perhaps the
right people to do that co-ordination?

We normally target a minimum of 128-bit security which in RSA terms is a
3072-bit key. It’s probably overkill for Usenet.

Post by Russ Allbery
Is anyone worried that 2048-bit RSA is not strong enough given how much of
a pain it is to replace keys and thus how long of an expected lifetime we
would like them to have? They're probably not quantum-safe (not that I
really expect anyone to waste quantum computing cycles on breaking Usenet
control messages).

AFAICS signed control messages include the date header. Provided news
servers reject date headers that are distant in time, and provided
header parsing is unambiguous, you only need to upgrade to quantum-safe
signatures when you think a quantum computer actually exists, since
stale control messages will be rejected anyway.

Post by Russ Allbery
(Is there even a quantum-resistant public key algorithm? ed25519
isn't quantum-resistant either, I believe.)

It isn’t.

There are many candidates. Personally I would wait until the NIST PQC
standardization effort completes before making a final selection (unless
my hand was forced) but as the field narrows it would be worth keeping
an eye on what the compromises will be, e.g. due to larger signature
sizes than we’re used to.

--
https://www.greenend.org.uk/rjk/

Julien ÉLIE

2020-05-21 10:46:06 UTC

Hi Richard,

That's indeed a good point. Date and Injection-Date header fields are
expected to be signed.

Incidentally, though it would be a huger gap, there's also the NAS
protocol (RFC 4707) that could be used to provide information and
updates to the list of newsgroups.
It also gives PGP public keys, so updates are easily done through this way.
The only PGP keys to maintain are the one of the NAS servers you trust
to give you information.

An experimental version is here:

% telnet nas.trigofacile.com 991
HELP
HIER uk
LSTR uk

DATA uk.net.news.announce
612 Information follows for newsgroups
Name: uk.net.news.announce
Status: Moderated
Description: For RFDs, CFVs, FAQs, etc. within the UK Hierarchy. (Moderated)
Mod-Sub-Adr: uk-net-news-***@moderators.isc.org

.

HIER uk
611 Information follows for hierarchies
Name: uk
Status: Complete
Description: United Kingdom of Great Britain and Northern Ireland
Ctl-Send-Adr: ***@usenet.org.uk
Ctl-Newsgroup: uk.net.news.announce
Language: en
Name-Length: 40
Comp-Length: 19
Source: http://www.usenet.org.uk/
Ctl-PGP-Key:
U uk.net.news.announce
L http://www.usenet.org.uk/newsadmins.html
V PGPfreeware 5.0i for non-commercial use
K------BEGIN PGP PUBLIC KEY BLOCK-----
K-Version: PGPfreeware 5.0i for non-commercial use
K-
K-mQCNAjGL0cgAAAEEAJ6p7fQHn139U9zQawLixrExOUrkFhi1yLb8m8fLxmKTprKn
K-ZNM1nnxMSbRyO8vXohXKKs4G1U2jTpaCkSRrbCiJ5VxWB/B31E/p/vrBXqqQ2amq
K-3gb4Df9DZub0ZtOhHTF/pPjQmXvAv08umjZWpYlXRmUHBlBhMmOfGXkh8vHZAAUR
K-tBR1ay5uZXQubmV3cy5hbm5vdW5jZYkAlQMFEDhCcUxjnxl5IfLx2QEB6e8EAJDt
K-gIkNXdLiyL07lgDBr+Wq/Zckgm70JhNaHWxLPqckMLOJZGPFKlOlKA6W62UrwDWI
K-yktEosLHd8whbPCaMOSbIOX7mmTrIySOKf+rBxhFLlRY+fAQ4h2oEyEWYhJ80wiN
K-GgKgMJC+UqQD/ylMB1VcCsTYuZWEQ18ldKgtTsOZtBc8Y29udHJvbEB1c2VuZXQu
K-b3JnLnVrPokAlQIFEDGL1R1jnxl5IfLx2QEBF/gD/ikHjpmJuG10X3PXA/yciZ0r
K-qqVo01/4q5yy8vHBGGfopfxpqrjGnNtUV4kWluNo0/1uYZm1o7TeqHI6Siv/yWQp
K-+QldN4nED3RPauqCtj5cubmMgryXg2pcCBiY+brHWEr0tBV7cSSOHFipwM55FA22
K-ctQzQ5nIPZQ+KPC3WjdZiQB8AwUQMvCcUq1e6k0sFfGpAQE6nwMzBdaFclXiv48C
K-aMXBUG8S3bLUtx3u2OBajzpe8G2nJlCKYkCY482p2MjtfCDi7+eYDfqgKMDoGrUM
K-zSfMraDRyoXjNC/nIKf1+R2EFMyaLoC9FWggCKTov/I/2BE2+grvQ7ewQSWEUokA
K-lQIFEDGL1FGemw5PLx059QEBje0EAKx99yOZ0zQ9FjibuEBStP8t0BCsRNqkrVjx
K-O513RBXecgcdXdv9hWn+8LNRZx6JLHv/ZpWsdGXqP3oiqj+LRt7WpHnZ55He/njx
K-5DAoPAM/TjgTk7arazSjsJuFhcTP7gHitLDoHxVkUfdLX8h4HH9LWhEnrWEx82EY
K-/29z/xQ6iQCVAgUQMYvTeKSiIc7jUXyJAQHLNwP/Qz+g2RRsuSZrJ9L0HAVPLcml
K-oAEGOMFfYJDM/mvxegAYzL8i0HGFbwTH/+E94WSmsWAx1KZ/Z2DYKdI7BUaS8c09
K-a2OtqOEbCd7QBI37seyxG0rTWNpuE0ZXBo0eiQBg37oIW+Faf/tqJQZnALVsV5LD
K-Kcf+6+MhgS47HWJ6ZjQ=
K-=iInx
K -----END PGP PUBLIC KEY BLOCK-----

.

--
Julien ÉLIE

« Quand je raconterai mon odyssée, personne ne me croira ! »
(Astérix)

Richard Kettlewell

2020-05-21 13:37:33 UTC

Post by Julien ÃLIE
Incidentally, though it would be a huger gap, there's also the NAS
protocol (RFC 4707) that could be used to provide information and
updates to the list of newsgroups.
It also gives PGP public keys, so updates are easily done through this way.
The only PGP keys to maintain are the one of the NAS servers you trust
to give you information.

Does it offer more than adding a signature PGPKEYS.asc alongside (say)
ftp.isc.org/pub/pgpcontrol/PGPKEYS and verifying that as part of
buildinnkeyring? I’m not convinced that introducing an entire new
protocol into the mix is a good approach if much simpler alternatives
are available; one of the things that’s become very clear as I bring my
collection of peers back up to a sensible number is that server
operators have very little spare time for Usenet today.

--
https://www.greenend.org.uk/rjk/

Julien ÉLIE

2020-05-22 08:20:41 UTC

Hi Richard,

Does it offer more than adding a signature PGPKEYS.asc alongside (say)
ftp.isc.org/pub/pgpcontrol/PGPKEYS and verifying that as part of
buildinnkeyring?

For just an update of PGP keys, yes, using PGPKEYS would be enough.

To update PGP keys of Big-8 and uk.* only (for instance if one only
trusts these two hierarchy administrators):

wget
'http://usenet.trigofacile.com/hierarchies/index.py?see=COMP,UK&only=pgpkeys'
-O downloaded-keys

The "downloaded-keys" file will contain the substract of PGPKEYS the
news admin is interested in.

Properly signing and checking the result, like the whole PGPKEYS file
(with PGPKEYS.asc like you suggest), is of course needed for security.
Put that into for instance a weekly crontab, and that's it.

With GPG 2.1.8, only 15 keys out of 103 in PGPKEYS are imported.
Anyway, there are far less than 103 active hierarchies nowadays.

@Paolo, it seems that the PGP key of aioe.* has expired:

pub dsa1024 2007-09-17 [SC] [expirée : 2010-09-16]
22031AAC51E7C7FD664F1D8090DF6C712322A7F8
uid [ expirée ] ***@aioe.org (Aioe.org Steering Group)
<***@aioe.org>

--
Julien ÉLIE

« Give laugh to all but smile to one,
Give cheeks to all but lips to one,
Give love to all but Heart to one,
Let everybody love you
But you love one. »

Aioe

2020-05-22 20:09:24 UTC

yes, i know.

Many years ago, around 2005, i bought a dedicated server and a backup
service from an (italian) provider who had just started the business that
offered very affordable prices to its first customers. The contract
stipulated that the price would remain the same forever.

Four years later, my server and backup service were suddenly shut down for
no reason and without warning.

In everyday life, i am a lawyer and so i sued them and i got a lavish
compensation from them on condition that the terms of the agreement
remained confidential. At the same time they refused to give me back the
disk images of the server and the contents of the backup. They preferred
to pay a great deal of compensation than to give me the data back.

I suppose they did this to prevent me from realizing that i had been
cheated by them. The price was too cheap to be true, the characteristics
of the service did not seem those foreseen by the contract even if i
didn't care about this because the price was so cheap that i was fine.
Criminal law is the largest part of my job, if they had been convicted of
fraud they would have closed their firm.

At that time, i kept the private key of the aioe.* hierarchy only on the
server disks and in the backup and i lost both.
I was very stupid to do this but i did not imagine that the provider
could behave in bad faith against me.

So at this point i can't renew the key because i can't sign the new one
with the old one.

I have never asked for an exception to the rule because i am ashamed of
being such an idiot. But i was a kid, i'm a hobbyist, i never needed to
create other groups after that time.

If there's a workaround, i'm happy to renew my key.

Julien ÉLIE

2020-05-24 06:51:54 UTC

Hi Paolo,

Post by Aioe

Post by Julien ÃLIE
@Paolo, it seems that the PGP key of aioe.* has expired

[...]

Post by Aioe
At that time, i kept the private key of the aioe.* hierarchy only on the
server disks and in the backup and i lost both.
So at this point i can't renew the key because i can't sign the new one
with the old one.

Thanks for the long explanation, that's pretty clear!
As the old key is no longer available, it is not useful to keep it. Why
not just ask for an update to a new key? May be worthwhile to do that
in case you have a change in your hierarchy in a few months or weeks.
At least people may get a chance to have your new key already installed.
Same thing for NoCeM.

Incidentally:
https://news.aioe.org/documentation/aioe-technical-data/
Links in that page lead to 404 errors (checkgroup.txt, aioe.txt,
control.ctl).

--
Julien ÉLIE

« Give laugh to all but smile to one,
Give cheeks to all but lips to one,
Give love to all but Heart to one,
Let everybody love you
But you love one. »

Julien ÉLIE

2021-09-20 10:54:42 UTC

Hi Paolo,

Post by Aioe

Post by Julien ÃLIE
@Paolo, it seems that the PGP key of aioe.* has expired

yes, i know.

[...]

I'm currently migrating my news server to a VPS and reinstalling all the
associated tooling.
It is with that sort of migration that I understand well how long it may
be for new users to set up a whole news server from scratch!
Impressive to see all the stuff needed :-)

Well, I'm writing here because I've just seen that the NoCeM PGP key has
been renewed for Aioe.org:

pub rsa4096 2021-07-20 [SC] [expire : 2024-07-19]
8A3C3C2515D0775C85CE765F8D4BD91D2643B3A6
uid [ inconnue] Aioe.org (Key for NoCEM bags) <***@aioe.org>
sub rsa4096 2021-07-20 [E] [expire : 2024-07-19]

Well, still expiring in 3 years but good to see that the old one, long
expired since 2010 is no longer in use.

I may have missed the announcement of the change though... Was it said
somewhere? (I may not be the only one in that case...)

--
Julien ÉLIE

« On appelle ça une insula. C'est une maison où les gens habitent les
uns au-dessus des autres… » (Astérix)

Russ Allbery

2020-05-21 17:29:37 UTC

Post by Richard Kettlewell
We normally target a minimum of 128-bit security which in RSA terms is a
3072-bit key. It’s probably overkill for Usenet.

We could just go to 4096 bits. It's not like the speed difference matters
for Usenet. The signature length is a bit longer, but meh.

I'd rather use ed25519, but I think that has more backwards compatibility
challenges.

Post by Russ Allbery
Is anyone worried that 2048-bit RSA is not strong enough given how much
of a pain it is to replace keys and thus how long of an expected
lifetime we would like them to have? They're probably not quantum-safe
(not that I really expect anyone to waste quantum computing cycles on
breaking Usenet control messages).

Right, but my point is that this forces another key upgrade. There's a
reason why it's been 24 years since we changed the key. :) But it
doesn't sound like there's a good way to anticipate that, so we're stuck
with it anyway.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Julien ÉLIE

2020-05-21 18:09:21 UTC

Hi Russ,

Post by Richard Kettlewell
AFAICS signed control messages include the date header. Provided news
servers reject date headers that are distant in time, and provided
header parsing is unambiguous, you only need to upgrade to quantum-safe
signatures when you think a quantum computer actually exists, since
stale control messages will be rejected anyway.

What about a new control message type that serves to update the public
PGP key?
Still maintained news servers could implement that new feature for their
next release.

As far as I see, if a private key is compromised, it does not change
much between modifying the key and issuing control messages with that
new key, and directly issuing control messages with the compromised key.
Am I missing something?

--
Julien ÉLIE

« Quand je raconterai mon odyssée, personne ne me croira ! »
(Astérix)

Adam H. Kerman

2020-05-21 18:37:46 UTC

Post by Julien ÃLIE

. . .

What about a new control message type that serves to update the public
PGP key?

Good heavens.

I don't see how you can safely get around manual intervention.

Post by Julien ÃLIE
. . .

Julien ÉLIE

2020-05-22 06:02:07 UTC

Hi Adam,

Post by Julien ÃLIE
What about a new control message type that serves to update the public
PGP key?

Good heavens.
I don't see how you can safely get around manual intervention.

Well, I was under the assumption that once you trusted once uk.* for
instance (manually adding its public PGP key), renewals of the same UID
used for control messages could be automated as long as the news user
can update the list of PGP keys it trusts.

If that idea is bad, OK, that was just an idea to share for an in-band
update.

--
Julien ÉLIE

« C'est une souricière, ils sont faits comme des rats ! »
(Astérix)

Richard Kettlewell

2020-05-21 08:20:12 UTC

Post by Matthew Vernon
My uk.* Control hat is worried about this too - I could make a new key
and (probably!) adjust the perl lashup that runs uk.* to sign with both
keys, but the real problem is getting "enough" admins to start trusting
the new key (and not the old one any more).

I’d suggest getting started quickly on dual-running for a single
hierarchy, to discover if there are any problems with it, what the
upgrade process looks like (given the end goal of trusting only the new
key), etc.

--
https://www.greenend.org.uk/rjk/

Julien ÉLIE

2020-12-08 19:55:06 UTC

Hi Richard,

Post by Richard Kettlewell
I’d suggest getting started quickly on dual-running for a single
hierarchy, to discover if there are any problems with it, what the
upgrade process looks like (given the end goal of trusting only the new
key), etc.

Well, then let's go for the international French-speaking hierarchy
(fr.*). Starting from January 2021, we'll be issuing control messages
signed with a brand new PGP key.
No dual-running, unfortunately, because we no longer have the previous
key (but if by any chance it is found later, I'll of course be happy to
also send control articles signed with it).

As for the upgrade process:

% su news
% wget http://www.usenet-fr.net/pgp-fr-2020.txt
% gpg --import pgp-fr-2020.txt

works fine :-)
At least, with INN.

Both the old and the new key can co-exist. I've tested to verify an old
control article, and a new one with the new key; both of them are
correctly recognized.

It's now up to news administrators to take a bit of their time to do that...

--
Julien ÉLIE

« J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
(Astérix)

Matthew Vernon

2020-12-14 16:32:18 UTC

Post by Julien ÃLIE
% wget http://www.usenet-fr.net/pgp-fr-2020.txt

Not https? :(

Matthew

--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life

Adam H. Kerman

2020-12-14 17:48:46 UTC

Post by Julien ÃLIE
% wget http://www.usenet-fr.net/pgp-fr-2020.txt

Not https? :(

As you're not logging on, why would you care? There is no security
implication.

A friend of mine explained why Google pushed for https, when I was,
well, intimidated into using https for each of my domains. My Web pages
are ugly text-only informational pages. There's nothing to log in for.

ISPs had begun substituting advertising from their own clients for that
of Google's advertising clients. https on non-interactive Web sites is
an attempt to thwart that.

There are no security implications for either the Webmaster nor user at
issue here.

Russ Allbery

2020-12-14 17:59:14 UTC

Post by Julien ÃLIE
% wget http://www.usenet-fr.net/pgp-fr-2020.txt

Not https? :(

As you're not logging on, why would you care? There is no security
implication.

If the network between the request and www.usenet-fr.net is insecure in
some way (DNS, network interception, etc.), an adversary can substitute
their own key in the response and then issue control messages with the
adversary's key that would be effective for fr.* at that site.

I don't think anyone is likely to bother to go to this effort for Usenet
control messages, but it does weaken the chain of trust for the key that
you retrieve from that web request to not use TLS.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Julien ÉLIE

2020-12-15 18:41:59 UTC

Hi Matthew,

Post by Julien ÃLIE
% wget http://www.usenet-fr.net/pgp-fr-2020.txt

Not https? :(

I think it's on the webmaster's to-do list. Thanks to recall it!

--
Julien ÉLIE

« Il est idiot de monter une côte à bicyclette quand il suffit de se
retourner pour la descendre. »

Julien ÉLIE

2020-12-17 16:14:52 UTC

Hi all,

Post by Julien ÃLIE
% wget http://www.usenet-fr.net/pgp-fr-2020.txt

Not https? :(

I think it's on the webmaster's to-do list. Thanks to recall it!

Done by the webmaster.
Thanks for having pointed out the issue!

=> https://www.usenet-fr.net/pgp-fr-2020.txt

--
Julien ÉLIE

« Mais écoutez ce qu'on vous dit, au lieu de taper comme un sourd ! »
(Astérix)

Julien ÉLIE

2021-02-15 21:04:27 UTC

Hi Richard, Matthew & all,

Last month, we created 2 newsgroups on the fr.* hierarchy with the new
4096-bit RSA key. We did not find any problem.
I would have thought adoption of the new PGP key would have taken far
more time. It appears that major news servers used by active posters to
fr.* quickly upgraded the key and created both
fr.misc.automobile.electrique and fr.misc.actualite.covid19.

As the previous PGP key is no longer usable, we do not dual-send control
articles. Changing the key on news server is the only option for fr.*
and anyway it is a good thing because actively maintained news server,
as often as not, couldn't process the previous key any longer (they had
a too recent GnuPG version for that).

I think you would be interested in this feedback.

Next upgrade in 2035 :-)

--
Julien ÉLIE

« Les amis de la vérité sont ceux qui la cherchent, et non ceux qui se
vantent de l'avoir trouvée. » (Condorcet)

D. Stussy

2021-10-07 02:00:36 UTC

What key servers should one periodically check for revisions? The "sks-servers.net" domain stopped service. "pgp.mit.edu" doesn't
seem to have Usenet keys.

If there isn't one, should we start one?

Matija Nalis

2021-10-16 15:50:23 UTC

["Followup-To:" header set to news.admin.hierarchies.]

Post by D. Stussy
What key servers should one periodically check for revisions? The "sks-servers.net" domain stopped service. "pgp.mit.edu" doesn't
seem to have Usenet keys.
If there isn't one, should we start one?

Maybe https://keys.openpgp.org/ ?

--
Opinions above are GNU-copylefted.

Adam H. Kerman

2020-05-20 20:09:00 UTC

Post by Tristan Miller
Thanks for bringing this up. The issue is something that the recently
reconstituted Big-8 Management Board has been discussing, at least
insofar as it relates to the control messages that the Board itself
needs to sign. But you're right that this is a more general problem.
We're working on a solution.

Skirv won't be issuing control messages any longer? All that's issued is
a cron job doing the checkgroups. I sure don't see why Skirv can't
continue to maintain that. You really don't want to be in a position in
which you must convince all the world's News administrators to implement
new keys. Unless I'm missing something and Skirv isn't using stronger
encryption.

Also, you're hierarchy administrators. It's long past time to retire the
pompous title that at no point described the genuine duties. Hierarchy
administration isn't any kind of management function, certainly not on
Usenet with its distributed server model and lack of central management
authority.

Russ Allbery

2020-05-20 20:46:33 UTC

Skirv won't be issuing control messages any longer?

Tim Skirvin has never issued control messages for the Big Eight. I have
been issuing all of the control messages since I took over from tale, and
continue to do so.

The current control messages are still being issued with the same key that
David Lawrence created in 1996. At this point, that key is old enough
that modern versions of GnuPG cannot use it. I've been meaning to deal
with this for a long time but have had very little time (and still have
very little time) to make many changes to the software and process.

The most likely approach will be to generate a new key and issue control
messages with both the old and new keys for some (extended) transition
period.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Adam H. Kerman

2020-05-20 20:54:30 UTC

Skirv won't be issuing control messages any longer?

Tim Skirvin has never issued control messages for the Big Eight. I have
been issuing all of the control messages since I took over from tale, and
continue to do so. . . .

My apologies

Thomas Hochstein

2020-05-31 21:05:27 UTC

Yes, we've got the same problem (with a key from the same year :)).

Post by Russ Allbery
The most likely approach will be to generate a new key and issue control
messages with both the old and new keys for some (extended) transition
period.

That was my first idea, too. AFAIS it's not possible to sign one
message with different keys.

I was hoping someone else would have time to go ahead, choose a
sensible new key format and try it ...

-thh

Russ Allbery

2020-08-23 00:23:25 UTC

Post by Russ Allbery
The current control messages are still being issued with the same key
that David Lawrence created in 1996. At this point, that key is old
enough that modern versions of GnuPG cannot use it. I've been meaning
to deal with this for a long time but have had very little time (and
still have very little time) to make many changes to the software and
process.
The most likely approach will be to generate a new key and issue control
messages with both the old and new keys for some (extended) transition
period.

As a quick update on this, I've been working on wrangling PGP::Sign into
shape, since all the rest of my machinery depends on it. That's mostly
done, although I have to sort out some more test failures. It now
supports using GnuPG v2 to create and validate signatures.

Once I get the rest of the test issues sorted out, the next step is to
create a new test key for the Big Eight and start dual-issuing control
messages. I'll do that for a while and let people test (and find any
problems with the key that might require recreating it) before officially
changing the key.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Jason Evans

2020-08-23 15:37:41 UTC

Post by Russ Allbery
Once I get the rest of the test issues sorted out, the next step is to
create a new test key for the Big Eight and start dual-issuing control
messages. I'll do that for a while and let people test (and find any
problems with the key that might require recreating it) before
officially changing the key.

Thanks for working on this, Russ. We really appreciate it!

Jason

Matthew Vernon

2020-08-26 16:35:57 UTC

Do you have a plan for getting news server operators to deploy the new
key? If so, could we potentially piggy-back other heirarchies into that
process?

Matthew
[one of my hats is uk.* Control]

--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life

Russ Allbery

2020-08-26 17:26:52 UTC

Do you have a plan for getting news server operators to deploy the new
key? If so, could we potentially piggy-back other heirarchies into that
process?

I don't, other than updating the key on ftp.isc.org and making an
announcement to news.admin.announce (and presumably the Big Eight Board
will want to make an announcement to news.announce.newgroups).

I expect to have to keep issuing the control messages with the old key for
years. I'll probably keep doing it until Debian drops GnuPG v1 from the
archive.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Julien ÉLIE

2020-10-10 10:45:46 UTC

Hi Russ,

Post by Russ Allbery
The most likely approach will be to generate a new key and issue control
messages with both the old and new keys for some (extended) transition
period.

As a quick update on this, I've been working on wrangling PGP::Sign into
shape, since all the rest of my machinery depends on it. That's mostly
done, although I have to sort out some more test failures. It now
supports using GnuPG v2 to create and validate signatures.
Once I get the rest of the test issues sorted out, the next step is to
create a new test key for the Big Eight and start dual-issuing control
messages. I'll do that for a while and let people test (and find any
problems with the key that might require recreating it) before officially
changing the key.

We plan on doing a similar move for the PGP key used to sign control
messages for the fr.* hierarchy. Maybe we could synch our efforts and
choose a similar algorithm for the Big-Eight and fr.* hierarchies?

An EdDSA algorithm like ed25519 [RFC8032]?
Debian has been shipped with an OpenSSH version implementing ed25519
since Jessie (2015). Jessie was also the last version to come with
GnuPG 1.4; Strech has 2.1.

So it seems to be a good choice for the transition between old and new
keys for interoperability.

--
Julien ÉLIE

« Je suis adroit de la main gauche et je suis gauche de la main
droite. » (Raymond Devos)

Julien ÉLIE

2020-11-14 12:53:20 UTC

Hi all,

Post by Julien ÃLIE

Post by Russ Allbery
The most likely approach will be to generate a new key and issue control
messages with both the old and new keys for some (extended) transition
period.

[...]

Post by Julien ÃLIE
We plan on doing a similar move for the PGP key used to sign control
messages for the fr.* hierarchy. Maybe we could synch our efforts and
choose a similar algorithm for the Big-Eight and fr.* hierarchies?
An EdDSA algorithm like ed25519 [RFC8032]?
Debian has been shipped with an OpenSSH version implementing ed25519
since Jessie (2015). Jessie was also the last version to come with
GnuPG 1.4; Strech has 2.1.

We'll start soon the experiment for the fr.* hierarchy.
Probably with an ed25519 key (which has a fixed 256-bit size).
I read that difficulty to breaking it is similar to a ~3072-bit RSA key.

Do you think it is better to change the user ID of the key or re-use the
one of the previous old key?
I would tend to re-use the previous user ID.

--
Julien ÉLIE

« – À la plage ? Mais il pleut !
– Pas du tout ! Dans le midi de la Gaule, il pleut. Ici, c'est tout
juste un peu humide. Vivifiant. Pas vrai, Astérix ?
– Ce matin, ça devient de plus en plus vivifiant ! » (Astérix)

Matthew Vernon

2020-11-16 10:53:49 UTC

Post by Julien ÃLIE
We'll start soon the experiment for the fr.* hierarchy.
Probably with an ed25519 key (which has a fixed 256-bit size).
I read that difficulty to breaking it is similar to a ~3072-bit RSA key.

My concern here is that we have to use an old gpgv (so that it
understand the old keys) to verify control messages at the moment, and
it won't understand very modern keys. Which is going to make migration a
pain in a number of ways (e.g. my current ancient tooling for signing
control messages uses gpg1 because modern gpg refuses to use the old
uk.* key - so if I make a new key I have to use a new toolchain with
that).

Post by Julien ÃLIE
Do you think it is better to change the user ID of the key or re-use
the one of the previous old key?
I would tend to re-use the previous user ID.

I would definitely favour using the old key ID - e.g. I have control.ctl
set to verify ***@usenet-fr.news.eu.org for fr.* so (assuming
previous questions about toolchain can be finessed) if your new key has
the same ID I won't have to change control.ctl at all.

Matthew

--
`O'-----0 `O'---. `O'---. `O'---.
\___| | \___|0-/ \___|/ \___|
| | /\ | | \ | |\ | |
The Dangers of modern veterinary life

Julien ÉLIE

2020-11-16 11:21:31 UTC

Hi Matthew,

The plan is to send control articles in double, during a few years.
One signed with the old key (supported by gpgv1 or equivalent, and
earlier versions of gpgv2), and another one signed with a modern key
(supported by modern gpgv2).

This way, news servers can cope with hierarchy updates, and can migrate
from gpgv1 to gpgv2 when they want to verify control messages. A smooth
transition.
Wouldn't it suit you needs? (gpgv1 / gpgv2)

As for tooling for signing control messages, yes, both toolchains have
to be maintained by hierarchy administrators. We're not plenty...

Post by Julien ÃLIE
Do you think it is better to change the user ID of the key or re-use
the one of the previous old key?
I would tend to re-use the previous user ID.

I would definitely favour using the old key ID - e.g. I have control.ctl
previous questions about toolchain can be finessed) if your new key has
the same ID I won't have to change control.ctl at all.

Yes, exactly, no changes are needed to control.ctl when re-using the
user ID.

--
Julien ÉLIE

« Ma parole… Vous êtes soûls ! Heu ! Sourds… » (Astérix)

Russ Allbery

2020-11-16 20:24:31 UTC

Post by Julien ÃLIE
We plan on doing a similar move for the PGP key used to sign control
messages for the fr.* hierarchy. Maybe we could synch our efforts and
choose a similar algorithm for the Big-Eight and fr.* hierarchies?
An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
an OpenSSH version implementing ed25519 since Jessie (2015). Jessie was
also the last version to come with GnuPG 1.4; Strech has 2.1.

I'm not currently seeing much point in using elliptic curve algorithms
instead of RSA. They're both vulnerable to quantum cryptography, so
there's not much in the way of future-proofing, and the security seems to
be roughly on par. I was planning on generating a 4096-bit RSA key
because everything understands it and has for eons, and I'm not sure how
old of software people might be running.

(4096 is probably overkill and 3072 would be fine.)

The downside of RSA compared to ed25519 is that the signature is larger
and (particularly for 4096-bit keys) slower to generate and verify, but
given the miniscule traffic of Usenet control messages, I don't think
there's much reason to care.

That said, maybe I'm missing something?

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Julien ÉLIE

2020-11-16 22:16:14 UTC

Hi Russ,

Post by Julien ÃLIE
An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
an OpenSSH version implementing ed25519 since Jessie (2015). >

A 4096-bit RSA key will last longer; 3072-bit RSA keys will probably be
considered weak within ten years. Same thing for ed25519 (256 bits)
anyway... Unless using 512-bit elliptic curves.

Post by Russ Allbery
The downside of RSA compared to ed25519 is that the signature is larger
and (particularly for 4096-bit keys) slower to generate and verify, but
given the miniscule traffic of Usenet control messages, I don't think
there's much reason to care.

Sure!

The question is probably more important for pgpmoose and NoCeM. Yet,
traffic is not that high either.

For compatibility reasons in 2020, using widespread RSA algorithm is
probably the best. So 3072 or 4096-bit is the question.

--
Julien ÉLIE

« Je suis capable du meilleur comme du pire, mais pour le pire, c'est
moi le meilleur. » (Coluche)

Franck

2020-11-18 12:57:14 UTC

Post by Julien ÃLIE
For compatibility reasons in 2020, using widespread RSA algorithm is
probably the best. So 3072 or 4096-bit is the question.

I delayed the implementation for processing control messages with PGP,
hoping that the choice would be made for RSA...

So +1 for RSA :-)

Julien ÉLIE

2020-11-20 21:49:13 UTC

Hi Franck,

Post by Franck
I delayed the implementation for processing control messages with PGP,
hoping that the choice would be made for RSA...
So +1 for RSA :-)

There is no obligation for a hierarchy administrator to choose this
algorithm, so a recent implementation should not implement only this one
I believe...

Incidentally, maybe a note about a preference for RSA keys should be
added to https://www.eyrie.org/~eagle/faqs/usenet-hier.html (Usenet
Hierarchy Administration FAQ)?
Its current wording is a bit confusing, speaking about old RSA
implementation of PGP 2.x instead of modern RSA implementations.

"Most Usenet news sites that honor control messages are set up to verify
messages signed with an algorithm called RSA, which was the algorithm
used by the original PGP implementation. Unfortunately, this is now
fairly obsolete. Current PGP implementations use a newer, more secure
algorithm for generating signatures (although the additional security is
probably overkill for Usenet control messages, at least for right now).
While this doesn't pose a problem for signing messages (current PGP
implementations can still use old RSA keys to sign things), it does
cause problems if you're starting fresh, since the keys generated by
current implementations will not work with old versions of PGP.

What all this means is that you have a few hard choices when it comes to
choosing a PGP implementation and generating your initial key pair. You
can use GnuPG <http://www.gnupg.org/>, which is probably the best
available PGP implementation, and not bother with a RSA key at all."

--
Julien ÉLIE

« Je n'aime pas faire du char-stop ! » (Astérix)

Julien ÉLIE

2020-12-08 20:00:08 UTC

Hi Franck,

Post by Franck

Post by Julien ÃLIE
For compatibility reasons in 2020, using widespread RSA algorithm is
probably the best. So 3072 or 4096-bit is the question.

I delayed the implementation for processing control messages with PGP,
hoping that the choice would be made for RSA...
So +1 for RSA :-)

Now that we know that the previous private key for fr.* has been lost,
it is no longer a question... We'll go for RSA because we cannot assume
every news server is no older than 5 years old!
Modern algorithms cannot be chosen for us; otherwise "old" news servers
would not been able to update their key ring without also updating GnuPG
or like.

--
Julien ÉLIE

« J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
(Astérix)

Franck

2020-12-11 05:51:35 UTC

Le 08/12/2020 à 21:00, Julien ÉLIE a écrit :

Hi Julien,

Post by Julien ÃLIE
Now that we know that the previous private key for fr.* has been lost,
it is no longer a question... We'll go for RSA because we cannot assume
every news server is no older than 5 years old!
Modern algorithms cannot be chosen for us; otherwise "old" news servers
would not been able to update their key ring without also updating GnuPG
or like.

I'll take a look at it as soon as I have some free time :-)

Julien ÉLIE

2020-11-20 21:52:35 UTC

Hi Russ,

Post by Julien ÃLIE
We plan on doing a similar move for the PGP key used to sign control
messages for the fr.* hierarchy. Maybe we could synch our efforts and
choose a similar algorithm for the Big-Eight and fr.* hierarchies?
An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped with
an OpenSSH version implementing ed25519 since Jessie (2015). Jessie was
also the last version to come with GnuPG 1.4; Strech has 2.1.

I'm not currently seeing much point in using elliptic curve algorithms
instead of RSA.

From GnuPG FAQ:
https://www.gnupg.org/faq/gnupg-faq.html

%%%
Will GnuPG ever support RSA-3072 or RSA-4096 by default?

Probably not. The future is elliptical-curve cryptography, which will
bring a level of safety comparable to RSA-16384. Every minute we spend
arguing about whether we should change the defaults to RSA-3072 or more
is one minute the shift to ECC is delayed.
Frankly, we think ECC is a really good idea and we’d like to see it
deployed as soon as humanly possible.
%%%

:)

--
Julien ÉLIE

« – Le bureau des renseignements ?
– Sais pas. Adressez-vous aux renseignements, ils vous
renseigneront. » (Astérix)

Russ Allbery

2020-11-20 23:02:01 UTC

Post by Julien ÃLIE
https://www.gnupg.org/faq/gnupg-faq.html
%%%
Will GnuPG ever support RSA-3072 or RSA-4096 by default?
Probably not. The future is elliptical-curve cryptography, which will
bring a level of safety comparable to RSA-16384. Every minute we spend
arguing about whether we should change the defaults to RSA-3072 or more is
one minute the shift to ECC is delayed.
Frankly, we think ECC is a really good idea and we’d like to see it
deployed as soon as humanly possible.
%%%

They subsequently changed the default to 3072-bit RSA.

I admit that I am still feeling burned about choosing a DSA/El Gamal key
way back in the day because of similar sorts of arguments that it was the
future, when I could have created an RSA key, only to have it be
discarded, now considered not sufficiently secure, and (longer) RSA keys
continue to be the standard.

--
Russ Allbery (***@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

D. Stussy

2020-06-20 06:15:57 UTC