Unsigned API responses

[cthulhu-rider]

Is your feature request related to a problem? Please describe.

each NeoFS response has https://github.com/nspcc-dev/neofs-api/blob/797e8303ff7a8b7fb55af57d0f10489140f8053c/container/service.proto#L140 field. It carries crypto signatures of the response payload and meta header. If the response message route consists of several API servers, each one adds its own signature

the purpose of this approach is:

1. signature ensures response data integrity
2. public key authenticates the server
3. client can track the request route

but:

• extra CPU, RAM and net capacity are spent on calculating and sending signature
• it does not protect from replay and other attacks
• the route is visible but not verifiable. And even if it were so, hardly anyone would be interested in it
• the listed advantages are implemented by protocols of other network levels (TLS)

based on these facts, NeoFS API protocol can be simplified by eliminating all response verification headers

Describe the solution you'd like

1. deprecate the field in all response messages
2. keep signing responses for client requests with meta_header.version <= v2.17
3. wait one release/update cycle, then prohibit the field and never sign responses

Describe alternatives you've considered

no

Additional context

• performance tests
• client: Detect invalid response message format neofs-sdk-go#661

[roman-khimov]

1. https://github.com/neo-project/neofs-api-csharp is likely to break. Who is to fix it?
2. We can't just drop all signatures. The most simple cases are GET or HEAD where we can verify the result irrespective of additional signatures. But other cases are not that easy, unless we're TLS there is no way to say the response is authentic. But, at the same time, we can say that it's the same for JSON-RPC for example. So some thought should be put at it as well as some additional tests. Take new-get test for example, how much of its gains are from signature eliminations and how much are from new GET?

[cthulhu-rider]

this gonna be a protocol change. Requests with older versions will be served with signing

unless we're TLS there is no way to say the response is authentic

that's exactly what TLS was created for i think, I'd rely on it

Take new-get test for example, how much of its gains are from signature eliminations and how much are from new GET?

i tested this GET(V2) API nspcc-dev/neofs-api@e25f79d only. Maybe I'll find time to make a comparison b/w two granular changes. If so, I'll write about it here

[roman-khimov]

My thought was to make it configurable. At least it's safer for now. Then it could be made the default, especially if we have protocol version in requests.

[cthulhu-rider]

Take new-get test for example, how much of its gains are from signature eliminations and how much are from new GET?

here are results i've got on S3 tests using Warp:

Test	Master	New GET	Unsigned GET
Size=4K Threads=10	1575	1687	1721
Size=4K Threads=100	2927	3326	3584
Size=4M Threads=10	206	200	449
Size=4M Threads=100	480	472	652

[roman-khimov]

New+Unsigned? It seems like New is ~useless. But given that signatures prevail here, maybe it gives more meaningful difference when they're not present.

[cthulhu-rider]

@roman-khimov here's what i've got

Test	New GET	Unsigned GET	Both	Unsigned + checksum
Size=4K Threads=10	1587	1826	1861	1764
Size=4K Threads=100	3091	3541	3602	3334
Size=4M Threads=10	195	412	413	366
Size=4M Threads=100	475	703	700	705

---

dropping signatures has a significant impact

chunk transmission in heading message affects much less. But still this is a nice enhancement

in total, i'd make both improvements based on the request API version

[carpawell]

But it feels like New's improvement is kinda test error, it does not differ much more than 1%

[cthulhu-rider]

it's pretty visible in 4K runs