From decker.christian at gmail.com Fri Sep 2 12:08:22 2016 From: decker.christian at gmail.com (Christian Decker) Date: Fri, 2 Sep 2016 14:08:22 +0200 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: References: <87oa58ox54.fsf@rustcorp.com.au> <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> <87pop1df71.fsf@rustcorp.com.au> Message-ID: <20160902120822.GA4575@nex> I'd like to pick up the conversation about the onion routing protocol again, since we are close to merging our implementation into the lightningd node. As far as I can see we mostly agree on the spec, with some issues that should be deferred until later/to other specs: - Key-rotation policies - Backlog of seen shared secrets - Payload formatting (what data to include and how it is encoded) The last pressing issue is the use of the HMAC, specifically what the per-hop verifiable HMAC should include. Having it cover the entirety of the packet, including the payloads, has the advantage that corrupted packets get dropped immediately, which prevents the route length discovery attacks Rusty described and we make more efficient use of our funds, i.e., drop a transfer immediately not allocating HTLCs for a payment that is destined to fail, and quicker retries. The downside is the rendezvous problem, in which the recipient would provide part of the onion, hence the sender cannot compute the HMACs. We can potentially sidestep this with a partially trusted reflector, have an interactive construction of the packet, or come up with a new scheme ourselves. Anyway, I'm happy to shelve this aspect for a future v2 of the onion routing protocol, and include the payload in the HMAC. I think for now we should also keep the payload sizes fixed at 20 bytes for per-hop and 1024 byte for end-to-end payload, and we can discuss how to format those payloads in another spec. Since we seem to want to add and remove bits and pieces it might be worth to make it flexible using a generic encoding (JSON, msgpack, ...). This potentially includes the "forward X units of coin Y" and the "expect X units" for the endpoint. We can also address the "last-hop corrupts" problem in the payload with an additional end-to-end secret like you suggested. Having them in the per-hop payload and HMACing the payloads secures them against tampering. Let me know if there is any major thing that is not/insufficiently addressed. BTW do we have a process in place for upgrading spec drafts or do we keep things informal? Regards, Christian On Mon, Aug 22, 2016 at 07:47:56PM +0000, Olaoluwa Osuntokun wrote: > On Sun, Aug 21, 2016 at 1:46 PM Rusty Russell wrote: > > > > This may not fully solve the problem, since if one presumes that the > > > second-to-last hop is malicious, they can re-create a new onion blob > > > (presuming consistent hashes for each hop, of course). > > > > Great catch. Oops... > > > > During the whole payment negotiation process, the sender and receiver can > additionally agree on a shared secret-ish value (possibly the hash of the > contract) that should be included in the per-hop payload for the final hop. > > If the portion of the per-hop payload doesn't match identically with this > value, then the payment should be rejected as a prior node has > unsuccessfully attempted re-create the onion packet. > > > -- Laolu > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev