[tor-dev] Sanitizing bridge descriptors containing ed25519 fields

[Karsten Loesing]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Nick,

On 31/05/15 16:21, Nick Mathewson wrote:
> On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing
> <karsten at torproject.org> wrote:
>> So, I think a "fingerprint-ed25519" line would be useful.  It
>> would make the bridge descriptor sanitizing process much easier.
>> It would also facilitate debugging network problems, because
>> people can just grep descriptors rather than using specialized
>> tools that know how to decode the cert.  And with
>> microdescriptors in place it should be okay to add this line even
>> if it's redundant information, because clients would never
>> download it.
> 
> Hm.  Okay, that sounds solid enough.  I'll try to hack it in
> tonight or Monday, and add it to prop220.

Sounds good.  Thanks!

>> If the server descriptor in #16227 were a bridge descriptor, I'd
>> do the following steps for sanitizing it:
>> 
>> - Remove identity-ed25519 line and subsequent crypto block.
> 
> +1

Okay.

>> - Keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its
>> value. - Keep extra-info digest line, but SHA1 and SHA256 its
>> values.
> 
> Suggestion: Don't use raw SHA256(x) but instead use
> SHA256("sanitize ID for bridge descriptor" | x) or SHA256("sanitize
> extra-info digest for bridge descriptor" | x). That way we don't
> need to worry about colliding with something else that decides to
> SHA256 these.

Hmm, actually I worry more about simplicity here than possible SHA256
collisions.  This algorithm needs to be implemented in various places
and sometimes even performed manually:

 - `router_write_fingerprint(int hashed)` in router.c: for the log
line and hashed-fingerprint file (want me to add a ticket for this, btw?),
 - Nyx (formerly known as arm): to display the hashed fingerprint that
users can paste into Atlas/Globe,
 - Atlas/Globe: to make sure that only hashed fingerprints are
submitted to Onionoo,
 - Onionoo: to make sure we also return relays that had their identity
hashed by Atlas/Globe and bridges that had their identity hashed twice,
 - CollecTor: to sanitize bridge descriptors,
 - bridge operators/BridgeDB devs: to find out more details about a
bridge that they only have a bridge network status or server
descriptor for,
 - and maybe others.

How bad would it be to just SHA256 values for sanitizing bridge
descriptors for the sake of simplicity?

>> - Remove onion-key line and subsequent crypto block. - Remove
>> signing-key line and subsequent crypto block. - Remove
>> onion-key-crosscert line and subsequent crypto block. - Remove
>> ntor-onion-key-crosscert line and subsequent crypto block. - Keep
>> ntor-onion-key line, mostly because we didn't remove it so far;
>> unless it should be removed? - Remove router-sig-ed25519 line. -
>> Remove router-signature line and subsequent crypto block. - Add
>> router-digest line with SHA1 of SHA1 of descriptor content and 
>> SHA256 of SHA256 of descriptor content; the rationale is that we
>> don't have to write entirely new digests into the network status
>> in order to match "r" lines with descriptors.
> 
> That all sounds fine.

Cool.

>> I also added the extra-info descriptor that corresponds to the
>> server descriptor to #16227:
>> 
>> https://trac.torproject.org/projects/tor/ticket/16227#comment:5
>> 
>> I wonder, what's the best way for including the ed25519 identity
>> in the extra-info descriptor?  How about extending the first line
>> to:
>> 
>> "extra-info Truie SHA1-of-RSA SHA256-of-ed25519"
>> 
>> Possible downsides are that this additional value might break
>> existing code and that it might be problematic to get rid of the
>> SHA1-of-RSA part later.  But the same issues would come up with
>> the "extra-info-digest" line in server descriptors, and maybe
>> there are good solutions.
>> 
>> Otherwise, a separate "fingerprint-ed25519" line might work here,
>> too.
> 
> Plausible.

Which one, the extended "extra-info" line or the additional
"fingerprint-ed25519" line? :)

>> In order to sanitize such an extra-info descriptor, I'd do these
>> steps:
>> 
>> - Keep extra-info line, but SHA1 (and possibly SHA256) its
>> value(s).
> 
> See above.
> 
>> - Or, keep yet-to-be-added fingerprint-ed25519 line, but SHA256
>> its value.
> 
> See above.
> 
>> - Remove router-sig-ed25519 line. - Remove router-signature line
>> and subsequent crypto block. - Add router-digest line with SHA1
>> of SHA1 of descriptor content and SHA256 of SHA256 of descriptor
>> content; same rationale as above, but with the
>> "extra-info-digest" line in server descriptors.
>> 
>> What do you think?
>> 
> 
> Sounds fine.

Thanks for looking!

All the best,
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVbAl7AAoJEJD5dJfVqbCrwTEIAMnXjFxwcHQUfcqozO/15gta
W7J5XNTfBFnXYy5a8ZFWRMf80+Mt+qwb9wJG2Nvjot9enBRS1Bn2TFchcKFUgEeS
U/epBGdWYgq1Uq7At7suX9AOt2SYYBKnQk3dfkvs3EJHVTWz+3s02Mh9Fz/FZl47
QcDXZkR7DYv1pu6XfVpidm4S390z5J+IuWzZGFfwTe2AElGBUQUxxLrQGPnLVCX/
Ue6WXtwgr8GvFgoXZ1ZAz43r2/P5IxCnuSsmFpKTJynvwkosK9TG/5fj/wmxxaiK
C1De+Dqfsrkket+wJQm5FUpx6wowIp5rIwkDqAgZYzwTNwViE3Ijg1nW0RtRTbg=
=ABhA
-----END PGP SIGNATURE-----