limit manifest size

[strantalis]

In the go sdk it was detected that a protocol attack could happen by reading an excessively large manifest. We should introduce the same limits within the java-sdk.

Let's do a test that recreates the test done on the Go sdk, using a tdf with a large manifest, and observe the behavior in order to determine what is needed for this ticket.

REF: opentdf/platform#1385

Acceptance Criteria:

• Test to make sure a manifest isn't larger than 10mb

[mkleene]

I don't think we have this exact vulnerability since all of our reads are in terms of segments but we seemingly have a related one where we allocate a buffer based on a stated segment size.

The simplest fix for this is likely to fix a maximum (ideally encrypted) segment size. One doesn't currently appear to exist but it might be a good idea to add one, I think.

@strantalis

[strantalis]

I don't think we have this exact vulnerability since all of our reads are in terms of segments but we seemingly have a related one where we allocate a buffer based on a stated segment size.

The simplest fix for this is likely to fix a maximum (ideally encrypted) segment size. One doesn't currently appear to exist but it might be a good idea to add one, I think.

@strantalis

@mkleene This has to do more with the manifest size. I don't think we restrict that right?

[mkleene]

@strantalis that makes sense; I guess that if someone gives us a big TDF then it will make us consume large amounts of memory and that is still bad. I was referring to the protocol aspect where you could have a tiny TDF that advertises a large manifest and forces you to use memory.

The fixes from opentdf/platform#1536 might also be relevant. I also think that adding a test for mismatched declared manifest size might be a good idea because I bet we'd just crash.

[sujankota]

#167