Hi Tim

Thanks for the feedback.

I agree with all of Gregs answers.

> key. Together with the encrypted packet lengths, the entire data stream looks 
> like random then,
> which is pretty useful against censorship resistance for example. (The only 
> exception is that the
> stream will never start with the magic bytes.)

All-or-none censorship attacks are out of scope for BIP151.
We won’t achieve DPI robustness in this proposal and I think it should not be 
part of the p2p protocol.

I think all-or-one censorship situations require an additional layer like TOR 
with OBFS4 (where AFAIK Eligator is used).
Eventually Core does directly support non-tor routed pluggable transports (it's 
partially already possible via SOCK proxy, but not on a gossip and 
plugin-launch level).

This does not exclude that we should obfuscate the key exchange as good as we 
can without blowing up the implementation too much.

The proposed encryption adds a robustness to the thread model with very little 
costs and low risks.

>   "salt = BitcoinSharedSecret||INITIATOR_PUBKEY||RESPONDER_PUBKEY" should 
> just avoid this issue.

This is a good point and I’d like to see more concrete examples how this (the 
non dynamic salt) could be exploited.

> Re-keying
> =========
> The problem with signalling re-keying in the length field is that the length 
> field is not covered
> by the MAC. So the attacker can flip the signalling bit. The resulting 
> protocol is probably still
> secure but the malleability is certainly not desirable.

In ChaCha20Poly1305@openssh, the length field is AAD, encrypted with a 
different key and part of the MAC.

> 
> Deterministic rekeying rules may be better. Otherwise there will be 
> implementations that rekey
> every 10 seconds and implementations that just don't rekey at all (rendering 
> the 10 s rekeying
> interval in the opposite direction useless). Different policies also make it 
> possible to
> fingerprint implementations. Another problem is that people will set their 
> policies arbitrarily.
> What's better: 5 min or 30 min? I don't know, but both are reasonable 
> choices. (Thats's very much
> like discussions about ciphers... What's better AES-GCM or ChaCha20/Poly1305? 
> I don't know, but
> again both are reasonable choices.)

The Rekey cost is two times a double-SHA256,… the costs of a rekey is similar 
to one or two v1 INV message creations.

> 
> Symmetric crypto
> ================
> You call it chacha20-poly1305@bitcoin but what's the difference to the 
> openssh then? Is the
> idea to save a call to chacha here as you mentioned?
> 
> I didn't think about this in detail: maybe there are a few meaningful cases 
> where padding could
> hide the message length without too much overhead. (I'm not convinced, just a 
> random thought.)

I think a new message type that could contain message + pad would be trivial.
Would this again be to obfuscate traffic patterns? Anti DPI is not the scope of 
BIP151.

> 
> Misc
> ====
> "The ID/string mapping is a peer to peer arrangement and MAY be negotiated 
> between the
> requesting and responding peer." I think that's overly complicated. I suggest 
> it should just be
> written in stone, again to avoid complexity and to avoid fingerprinting. New 
> implementations are
> necessary anyway, so maybe just use IDs for anything? ASCII is nice if you 
> want to debug your code
> or some random network failure but that's hard anyway when encryption is used.

I wanted to avoid too much central planing here and only cover the ones where 
it's most efficient (small messages that are used often).
The ASCII commands are in itself somehow pseude-robust against collision.
For a 1MB block message, using a 1-byte short ID (rather then a 6-byte ASCII 
command) would reduce the bandwidth requirement insignificant (99.99952%).

If we would always have used short IDs in the past, there could have been a 
collision between XTIN, compact, sendheaders or so.

> 
> In general, the entire thing is a little bit underspecified. (I'm aware it's 
> just a draft.)
> A few examples:
> - What should a peer do if the MAC verification fails?
> - What should a peer do if it receives an even key?
> - "Processing the message before the authentication succeeds (MAC verified) 
> MUST not be done."
> That should also apply to the ciphertext. (Or: What is a "message"?). It may 
> be a good idea to
> to refer to the openssh document or steal from it; it does a pretty good job.
> - "Both peers MUST keep track of the message sequence number (uint32) of sent 
> and received
> messages for building a 64-bit symmetric cipher IV." I think you mean nonce 
> when you say IV?
> - What is the initial value of the sequence number?

Good points. Will make them more clear in the BIP.
I was under the false impression that it is obvious to disconnect in those 
cases.

> - How is a 64-bit nonce formed from one (two?) uint32?

That’s specified in ChaCha20Poly1305@openssh ("a nonce consisting of the packet 
sequence number encoded as a uint64“).
But I’ll specified that more clear.

> - What if the uint32 overflows?

The max data before rekey is 1GB, AFAIK it is impossible to overflow.

> - "Re-Keying interval is a peer policy with a minimum timespan of 10 
> seconds." What if I receive
> too many re-keying requests? Nothing or should I raise the DoS score?

Current implementation proposal does a disconnect. With the risk of 
fingerprinting options, I think we can leave this open to the implementation?

> - "The Re-Keying must be done after every 1GB of data sent or received" Hm, 
> every peer updates its
> own sending key, so this should just read "sent" instead of "sent or 
> received“?

Yes. Should probably be „sent“,… and eventually a paragraph that states that a 
peer should disconnect if the remote peer did not rekey within that limit.

> Pseudocode could probably help here.

Agree. Will try to add.

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to