Re: [tor-bugs] #18875 [Metrics/metrics-lib]: Consider replacing RelayNetworkStatusVote's getDirectorySignatures() with getDirectorySignature()

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#18875: Consider replacing RelayNetworkStatusVote's getDirectorySignatures() with
getDirectorySignature()
---------------------------------+-------------------------
 Reporter:  karsten              |          Owner:  karsten
     Type:  enhancement          |         Status:  new
 Priority:  Medium               |      Milestone:
Component:  Metrics/metrics-lib  |        Version:
 Severity:  Normal               |     Resolution:
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
 Reviewer:                       |        Sponsor:
---------------------------------+-------------------------

Comment (by karsten):

 Replying to [comment:2 teor]:

 Thanks for your thoughts here!

 > I think the underlying question here is:
 > "What will happen when we stop using SHA1/RSA_PKCS1_PADDING for our
 consensus digests?"
 >
 > I would imagine we'll have to sign both SHA1/RSA_PKCS1_PADDING and
 SHA256/ED25519(?) for a while.

 Probably, yes.  I mean, we could also teach all fellow directory
 authorities how to verify the new signature scheme and then switch, but it
 seems easier to just include two signatures for a while.  It would violate
 the "Exactly Once" part in dir-spec.txt, but I guess that's easy to
 change.

 I'd say, for metrics-lib, let's assume it's at least possible that votes
 contain more than one signature, even if that has not happened so far.

 > I also have a related question:
 > What is the "String" key in the current metrics-lib
 getDirectorySignatures() map?

 From the latest Javadocs, that string is "the SHA-1 digest of the
 authority's identity key in the version 3 directory protocol, encoded as
 40 upper-case hexadecimal characters."

 Maybe the better answer is: let's get rid of that string, because it's
 confusing and is already contained in `DirectorySignature`, and turn the
 map into a list.  (See suggestion below.)

 > How does it handle signatures from legacy keys?

 Uhm, fine question.  IIUC, votes only contain signatures made by the
 authority's non-legacy key, and consensuses contain both legacy and non-
 legacy signatures.  So, for this ticket where we primarily consider votes,
 this doesn't matter.  And consensuses simply contain more signatures than
 there were authorities contributing to the consensus.

 > I'd suggest passing the algorithm / identity / signing key digest to the
 function (if they're not already implicit as part of the
 RelayNetworkStatusVote object).
 > That way, you can return the appropriate signature.
 > Perhaps it's worth having a form of the function with sensible defaults,
 like `getDirectorySignatureSHA1RSA()`, which would get the SHA1/RSA
 signature from the most recent signing key for that authority.

 I think the simpler approach is to return a list of all signatures which
 contain algorithm, identity and signing key digest, and let the
 application skip over all signatures it doesn't care about.  That would be
 `public List<DirectorySignature> getSignatures()`, both in consensuses and
 in votes.

 Again, thanks for your feedback!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18875#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs