13.2.6 needs wordsmithing

[jmanico]

13.2.6

Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.

[Sjord]

See also V13.2.6: signing requests · Issue #528 · OWASP/ASVS

[tghosth]

@set-reminder 3 weeks look at this

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 28, 2022 12:00 AM (GMT+01:00)

look at this

[tghosth]

Ok so I'd like to bring @jaxley back in for his thoughts but I think we need to make this a level 3 requirement as doing anything on top of TLS is rare and complicated.

The requirement as it is seems to basically use TLS as a get out so is probably not super useful anyway.

I also think that even for L3 absolutely requiring message signing is a little extreme so I would be tempted to go with the following wording which at least provides a get out if they have specifically considered it.

#	Description	L1	L2	L3	CWE
13.2.6	[MODIFIED] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections or that this was formally considered and rejected (with the rationale documented) based on the additional complexity and risks compared to the benefits.			✓	345

What do people think?

[elarlang]

Against what attack it is and what problem it solves (which is not already solved by using TLS)?

[Sjord]

or that this was formally considered and rejected

I think developers that use ASVS can formally reject any ASVS requirement, if they think it does not apply to them or covers an acceptable risk. This requirement doesn't seem special in that way.

based on the additional complexity and risks compared to the benefits.

If we expect people to evaluate this, we need to be very clear about the risks and benefits of this requirement. Currently the benefit is stated as "provide additional assurance", which is a bit vague.

Verify that per-message digital signatures are used

Would client-side TLS count as per-message digital signatures? Would per-message digital signatures offer any benefit on top of TLS?

One situation where per-message digital signatures can be useful, is if the message traverses several systems or is stored in a database. A digital signature can then be verified by the final processor of the message. This provides security over the whole chain, where TLS only provides security between nodes.

[octo-reminder[bot]]

🔔 @tghosth

look at this

[tghosth]

@set-reminder 1 week @tghosth to look at this

[octo-reminder[bot]]

⏰ Reminder Thursday, January 5, 2023 12:00 AM (GMT+01:00)

@tghosth to look at this

[octo-reminder[bot]]

🔔 @tghosth

@tghosth to look at this

[tghosth]

@elarlang this is defense in depth measure to protect against some sort of TLS mess up

@Sjord your comments make me wonder, do we think this is important enough to include as a requirement?

[Sjord]

The existing requirement already says that TLS is sufficient, and in this discussion we seem to agree on that. Per-message digital signatures can be provide additional security in specific cases, but I wouldn't say it's a general requirement for all applications.

[tghosth]

Ok so how about this updated suggestion:

#	Description	L1	L2	L3	CWE
13.2.6	[MODIFIED] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests/transactions which are highly sensitive or which traverse a number of systems without an uninterrupted TLS connection.			✓	345

[tghosth]

@Sjord @jmanico what do you think about this updated wording and level change?

Old:

#	Description	L1	L2	L3	CWE
13.2.6	Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.		✓	✓	345

New:

#	Description	L1	L2	L3	CWE
13.2.6	[MODIFIED, L2>L3] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests/transactions which are highly sensitive or which traverse a number of systems without an uninterrupted TLS connection.			✓	345

[jmanico]

The whole point of things like SOAP message encryption is not because TLS is missing but because one of the systems along the way does not have access to that data but still needs to route it.

So I'd suggest dropping the TLS part:

/[MODIFIED, L2>L3] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests/transactions which are highly sensitive or which traverse a number of systems./

[tghosth]

ok so @Sjord what do you think about this updated wording and level change?

Old:

#	Description	L1	L2	L3	CWE
13.2.6	Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection. Per-message digital signatures can provide additional assurance on top of the transport protections for high-security applications but bring with them additional complexity and risks to weigh against the benefits.		✓	✓	345

New:

#	Description	L1	L2	L3	CWE
13.2.6	[MODIFIED, L2>L3] Verify that per-message digital signatures are used to provide additional assurance on top of transport protections for requests/transactions which are highly sensitive or which traverse a number of systems.			✓	345

[tghosth]

I have opened https://github.com/OWASP/ASVS/pull/1685 to resolve this.