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 news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
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...
Dear Julien,
On 05/04/2020 14.04, Julien ÉLIE wrote:
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
news.software.nntp in 2015 (<n62tgi$4co$1@csiph.com> from Kevin
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.
Tristan Miller <tmiller@big-8.org> writes:
On 05/04/2020 14.04, Julien ÉLIE wrote:
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)
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.
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?
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?
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.
"Adam H. Kerman" <ahk@chinet.com> writes:
Tristan Miller <tmiller@big-8.org> wrote:
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?
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. . . .
Tristan Miller <tmiller@big-8.org> wrote:
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?
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).
Matthew Vernon <control@usenet.org.uk> writes:
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.)
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.
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.
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.
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.
We normally target a minimum of 128-bit security which in RSA terms is a 3072-bit key. It’s probably overkill for Usenet.
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.
. . .
What about a new control message type that serves to update the public
PGP key?
. . .
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.
Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> writes:
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?
@Paolo, it seems that the PGP key of aioe.* has expired:
@Paolo, it seems that the PGP key of aioe.* has expired
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.
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.
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.
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 <eagle@eyrie.org> writes:
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.
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 <eagle@eyrie.org> writes:
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.
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?
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.
[...]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.
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.
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).
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 control@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.
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.
An EdDSA algorithm like ed25519 [RFC8032]? Debian has been shipped withI'm not currently seeing much point in using elliptic curve algorithms instead of RSA. They're both vulnerable to quantum cryptography, so
an OpenSSH version implementing ed25519 since Jessie (2015). >
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.
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 :-)
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.
%%%
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.
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.
% wget http://www.usenet-fr.net/pgp-fr-2020.txt
Matthew Vernon <matthew@debian.org> wrote:
Julien ELIE <iulius@nom-de-mon-site.com.invalid> writes:
% 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.
Julien ELIE <iulius@nom-de-mon-site.com.invalid> writes:
% wget http://www.usenet-fr.net/pgp-fr-2020.txt
Not https? :(
% wget http://www.usenet-fr.net/pgp-fr-2020.txt
Not https? :(
% 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!
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.
[...]@Paolo, it seems that the PGP key of aioe.* has expired
yes, i know.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 403 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 112:35:51 |
| Calls: | 8,465 |
| Calls today: | 2 |
| Files: | 13,181 |
| Messages: | 5,910,008 |