Re: [tor-dev] Let's identify which measurement-related tools need work when relays switch from RSA identities to ed25519 identities
Hi Karsten. Quick question: with the switchover are relay fingerprints going away? That is to say, server descriptors no longer have a...
fingerprint D203 4DDF 1275 A234 4F66 9935 A3EF B908 FFC7 AE9A
... line, and router status entries don't have it on their dir-source? If not, what in particular are being dropped?
Cheers! -Damian
yes, I think that's the plan. Please see proposal 220, Sections 8 and 9 for some more details.
Thanks Karsten. Now that I know this isn't a completely foolish question adding tor-dev@ back in. If we're dropping the fingerprint that's a lot more invasive. Fingerprints are relay's canonical identity, and simply dropping them will break... a lot. I'd suggest instead relays should continue to have a fingerprint but that it's the 40 character hex hash of the ed25519 identity. On a side note it would be nice to have a spec patch before changing things this time. Sections 8 and 9 are a fine summary, but it's not clear to me precisely how the descriptors are changing from it. They certainly don't say to me "we're dropping the fingerprint field". If that change went out without a spec patch first I'd borrow Mr. Potato Head's angry eyes to stare at its author. Cheers! -Damian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/15 18:16, Damian Johnson wrote:
Hi Karsten. Quick question: with the switchover are relay fingerprints going away? That is to say, server descriptors no longer have a...
fingerprint D203 4DDF 1275 A234 4F66 9935 A3EF B908 FFC7 AE9A
... line, and router status entries don't have it on their dir-source? If not, what in particular are being dropped?
Cheers! -Damian
yes, I think that's the plan. Please see proposal 220, Sections 8 and 9 for some more details.
Thanks Karsten. Now that I know this isn't a completely foolish question adding tor-dev@ back in.
If we're dropping the fingerprint that's a lot more invasive. Fingerprints are relay's canonical identity, and simply dropping them will break... a lot. I'd suggest instead relays should continue to have a fingerprint but that it's the 40 character hex hash of the ed25519 identity.
It's true, dropping the fingerprint is quite invasive and might break things. But that's why we're making plans now to make this transition as smooth as possible. However, I don't think that we can get away by just replacing the existing 20 byte long RSA key digest with a 20 byte long hash of the new, 32 byte long ed25519 key. There are probably cryptographic reasons for that. But in addition to that, there should be a time when relays use both fingerprints in parallel so that directory authorities and other tools can build a map from old to new identities. Otherwise, relays would lose all their history only because they are switching from RSA to ed25519, and wouldn't that be sad? There might be more reasons that I'm currently not thinking of. But: I'm not making this call, I'm just thinking about the possible impact of this change and which code needs to be updated. How about we talk more about this in Berlin together with Nick? Maybe take a look at the list I wrote and think of other code that will need work when this change actually takes place? All the best, Karsten
On a side note it would be nice to have a spec patch before changing things this time. Sections 8 and 9 are a fine summary, but it's not clear to me precisely how the descriptors are changing from it. They certainly don't say to me "we're dropping the fingerprint field". If that change went out without a spec patch first I'd borrow Mr. Potato Head's angry eyes to stare at its author.
Cheers! -Damian _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV9YYpAAoJEJD5dJfVqbCr5bQIAMDFa02wnrxpL+qCiXBHCJ+g RAIZHgKWOUSO35dAyLDpDbnRWLbTMOlXgxrdbBNLzzXrs+9jT9Ivz2ZEHPnSwt88 P0f396ZU/QvpT4M4uZXLV/Nzq0S1+OqjK/brDXMNwZaKuJKF8rjtvJvVb4s1HQVD ubf8EV1vz4/7XS+yPKanZWdnFnBTCsT/56D0pcEyntk3evLElJCeC1f5fMXkrzLO Iu8ZfRoNgAMJ7EbKH6SucyExpsY0xfSOSl+E06ZVYH20AuT/ZBT88S/Yqv0vTduW vY10tSrigm5/UsoCV5sTNG/DMq5F19MPfYts7N05NM5iOEFIkIulD1AOPBhVj34= =nWI2 -----END PGP SIGNATURE-----
It's true, dropping the fingerprint is quite invasive and might break things. But that's why we're making plans now to make this transition as smooth as possible.
However, I don't think that we can get away by just replacing the existing 20 byte long RSA key digest with a 20 byte long hash of the new, 32 byte long ed25519 key. There are probably cryptographic reasons for that. But in addition to that, there should be a time when relays use both fingerprints in parallel so that directory authorities and other tools can build a map from old to new identities. Otherwise, relays would lose all their history only because they are switching from RSA to ed25519, and wouldn't that be sad? There might be more reasons that I'm currently not thinking of. But: I'm not making this call, I'm just thinking about the possible impact of this change and which code needs to be updated.
How about we talk more about this in Berlin together with Nick? Maybe take a look at the list I wrote and think of other code that will need work when this change actually takes place?
Certainly, sounds good! For what it's worth my concern is about the fingerprint's longstanding role as the relay identifier. Some spots off the top of my head... * The control spec allows you to query descriptors by fingerprint or nickname. * Circuit events and most other things citing relays do so by fingerprint or fingerprint~nickname. * Atlas, Globe, and just about every tool that allows you to look up relay information does so by fingerprint. * In Stem anything related to identifying a relay does so by fingerprint. No doubt there's many, many other things that'll break too. This is the main identifier of a relay and I'd expect mucking with it to break all the things. Hence my interest in an in-place replacement instead. ;) Cheers! -Damian
participants (2)
-
Damian Johnson -
Karsten Loesing