Tracking: RFC Breaking Changes for STREAM V2

[sappenin]

This ticket is meant to track various proposals related to a potential STREAM V2. The reason we're not making breaking changes in STREAM v1 is that there are already implementations in the wild that use V1, and we don't want to break them or force people to update software.

So, let's use this ticket to catalog any improvements to STREAM that we might want to include in the next version.

• Fix Encryption AuthTag Ordering (Stream Crypto: Stop re-arranging AuthTag in CipherText interledger-rs#310)
• Use a standard HKDF (consider RFC-5869 and see here for more details). Note that transitioning to a standards-based KDF doesn't add any security value unless we start exchanging a salt during SPSP, and this would only provide marginal value due to the way we use STREAM. So, primary benefit here is just using a standard KDF. Quilt example PR here.
• Add ability to request ConnectionAssetDetails without sending a ConnectionNewAddressFrame (see Add ConnectionAssetDetailsRequestFrame #571) and STREAM Sender: Compute Sender Address Properly hyperledger-archives/quilt#445.

Other references

• Fixes #546 #551
• STREAM RFC: codify the conditions for a ConnectionAssetDetails frame being returned from a receiver. #546
• Clarify STREAM Connection Details Functionality

[kincaidoneil]

Decide what the best way to exchange Connection Asset details is (SPSP or some higher layer, ConnectionAssetDetails frame, some new frame?). See #551 as well as #546.

Can't we resolve this now without a breaking change? Alternatively, if this should be at a higher layer, could we also address this now/sooner in a backwards-compatible way?

[sappenin]

Can't we resolve this now without a breaking change

Possibly, but not in this ticket. This is just a tracking ticket for the day, perhaps very far into the future, that we decide to work on STREAM v2. For now, this is basically where we can track things that probably should be fixed, but for which we lack enough knowledge to make a good decision....or, for which the cost of fixing existing implementations is large enough that we don't want to make breaking changes in a one-off manner (i.e., we want to make only a single set of breaking changes, once we've collected enough of them to justify prodding everyone to upgrade).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.