[tor-dev] Sanitizing bridge descriptors containing ed25519 fields

[Nick Mathewson]

On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing <karsten at torproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 30/05/15 16:44, Nick Mathewson wrote:
>> On Fri, May 29, 2015 at 4:23 PM, Karsten Loesing
>> <karsten at torproject.org> wrote:
>>>> router euler [scrubbed] 8000 0 0 identity-ed25519 -----BEGIN
>>>> ED25519 CERT----- [scrubbed] -----END ED25519 CERT-----
>>>
>>> Base64-decode that block, throw it into SHA256(), base64-encode
>>> the result, format as block.  But wouldn't the result be much
>>> shorter? There's no new "fingerprint" equivalent, like
>>> "fingerprint-ed25519", is there?
>>
>> Oh dear.  That blob is a certificate, not a key.  It changes over
>> time, because the key that it certifies varies over time.
>>
>> The format is documented in section 2.1 of proposal 220; the
>> actual identity key is in an extension labeled with type 04 (see
>> section 2.2.1).
>>
>> Maybe we should add a fingerprint-ed25519 line?  It would be
>> redundant, but maybe valuable.  What do you think?
>
> I took a quick look at proposal 220, but not to the point that makes
> me entirely certain about this ed25519 stuff.  If anything below
> remains unclear, that might be because I'm not clear about it myself.
>  Please question everything I'm saying, even more than usual.
>
> Let's also include Damian on this thread.  He usually has good ideas
> about descriptors, and he knows about sanitizing bridge descriptors.
> And let's add Isis who is working a lot with bridge descriptors, too.
>  (There may be more people we should ask, but hey, it's tor-dev at .)
>
>
> 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.


> 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

>  - 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.

>  - 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.

>
> 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.

> 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.