#22979 closed enhancement (fixed)

prop224: Add an introduction point onion key in the descriptor

Reported by: dgoulet Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, prop224, tor-spec
Cc: asn Actual Points:
Parent ID: #21888 Points: 0.1
Reviewer: asn Sponsor: SponsorR-must

Description

So it turns out that this menagerie of keys in prop224 was missing yet one more key in it :D.

To extend to an introduction point, we need its onion key meaning we have to add it to the descriptor. Keep in mind that the client does NOT lookup the node in its consensus in order not to reveal which consensus it's using and avoid reachability issues with different consensus between service and client.

This goes in two fold. First add an onion key field in the spec and then implement it in an extra commit in #20657 code (which is being reviewed). I would like us to avoid making a branch depending on 8k lines of code from another unmerged ticket.

Child Tickets

Change History (12)

comment:1 Changed 21 months ago by dgoulet

Parent ID: #20657
Status: newaccepted

comment:2 Changed 21 months ago by dgoulet

Status: acceptedneeds_review

Spec: ticket22979_01

comment:3 in reply to:  2 Changed 21 months ago by asn

Replying to dgoulet:

Spec: ticket22979_01

LGTM.

comment:4 Changed 21 months ago by dgoulet

Parent ID: #20657#21888
Status: needs_reviewaccepted

Ok, time for the code to come! Considering this as a groundwork and should be based on git master.

comment:5 Changed 21 months ago by dgoulet

Points: 0.20.1
Reviewer: asn
Status: acceptedneeds_review

Branch: ticket22979_032_01

It's not that big so let me know if an Oniongit would be needed.

comment:6 in reply to:  5 ; Changed 20 months ago by asn

Replying to dgoulet:

Branch: ticket22979_032_01

It's not that big so let me know if an Oniongit would be needed.

LGTM, but two quick questions:

a) I assume that ip->onion_key will be initialized by the service code that is not yet included in the branch. So it's OK that it's not really filled with anything on the service-side, right?

b) Do we really want to goto err if we don't recognize the key type when decoding descriptor? Doesn't that influence our forward-compatibility that the key type field was supposed to be helping?

comment:7 in reply to:  6 Changed 20 months ago by dgoulet

Replying to asn:

Replying to dgoulet:

Branch: ticket22979_032_01

It's not that big so let me know if an Oniongit would be needed.

LGTM, but two quick questions:

a) I assume that ip->onion_key will be initialized by the service code that is not yet included in the branch. So it's OK that it's not really filled with anything on the service-side, right?

Yes exactly. This is really just the "descriptor subsystem" support for decoding and encoding.

b) Do we really want to goto err if we don't recognize the key type when decoding descriptor? Doesn't that influence our forward-compatibility that the key type field was supposed to be helping?

Hmmm yes I think you are right. Then we have the same issue with enc-key... :S

Basically, if we don't have "ntor" following it, we should just ignore it and move on. See fixup commit 76533e10a.

comment:8 Changed 20 months ago by dgoulet

Status: needs_reviewmerge_ready

From IRC: <+asn> LGTM

Actually, the fixup commit has been removed. Final branches:

Spec: ticket22979_01
Code: ticket22979_032_01

comment:9 Changed 20 months ago by nickm

Should this become an "At least once" element, so that we can someday have an ntor key and a something-else key?

comment:10 Changed 20 months ago by dgoulet

Fixup commit on both spec and code. Basically, code one changes to T1N and the spec one mentions "Exactly once per ip".

comment:11 Changed 20 months ago by nickm

Status: merge_readyneeds_revision

I don't think that's what I meant: I meant that an intro point should be able to have an ntor onion key, and also (say) have some other kind of onion key for some day in the future, too, in case we add a successor to ntor.

So I think the code in decode_introduction_point needs to handle looking for the first onion-key ntor line. Otherwise it will ignore it if the ntor one isn't in the first position.

Also the spec should say something like "At least once per intro point; each key type must be unique per intro point"

comment:12 Changed 20 months ago by asn

Resolution: fixed
Status: needs_revisionclosed

That was fixed as part of the #20657 branch, and also merged upstream. See: https://gitweb.torproject.org/tor.git/commit/?id=471489ca035a50733205f97c8d589d80c58e36e8

Closing this for now.

Note: See TracTickets for help on using tickets.