V6 Cryptography - requirement for Encrypted Client Hello (ECH)

[danielcuthbert]

Encrypted Client Hello (ECH) pertains to TLS and its goal to protect metadata by encrypting client-sent data like the Server Name Indication (SNI) that might otherwise leak potentially sensitive information.

V6.8 In-Use Data Cryptography broadly addresses data protection during use and during transmission, this would be a suitable section to add a requirement for ECH

more on ECH can be found on the amazing Cloudflare blog https://blog.cloudflare.com/announcing-encrypted-client-hello/

As such, it's a huge privacy tool and I am proposing we add it to V6

| 6.8.3 | [ADDED] Verify that Encrypted Client Hello (ECH) is supported and properly configured within the application’s TLS settings to prevent exposure of sensitive metadata, such as the Server Name Indication (SNI), during TLS handshake processes. | | ✓ | ✓ | |

[tghosth]

Does it fit better into V9 with other TLS stuff?

[tghosth]

@danielcuthbert ?

[danielcuthbert]

You know I did ponder this and im torn. Yes and no. But then should TLS be in crypto? It could fit in 9.1 nicely but that is looking a bit bare too.

[jmanico]

This seems way too detailed. There are hundreds of crypto requirements we could aim for. Where do we stop? Why is this critical?

And ❤️ you all, asking nicely.

[randomstuff]

ECH is really great/important for privacy but I am wondering whether it is really for prime time as it is not yet RFC status. And whether we should require it for now or if this should just be a recommendation.

[jmanico]

I politely suggest we push it to ASVS post 5.0 release.

[danielcuthbert]

@randomstuff one can argue that when Cloudflare has deployed it, for me that's massive scale primetime right? you couldn't get more of a huge platform to iron out the bugs

[elarlang]

I'm not technically competent to comment the topic but...

ECH is really great/important for privacy but I am wondering whether it is really for prime time as it is not yet RFC status. And whether we should require it for now or if this should just be a recommendation.

For OAuth/OIDC we use not released drafts, we aligned many requirements from NIST not released drafts, so it is more question does it make sense as a security requirement - that is general enough, has the impact and is not too niche.

[danielcuthbert]

All valid questions @elarlang ill report back with outcomes. @jmanico what other cryptography elements do you feel 5.0 is missing?

[tghosth]

(I am going to mark PR as draft and wait to see what else @danielcuthbert finds and also result of discussion between @jmanico and @danielcuthbert )

[jmanico]

All valid questions @elarlang ill report back with outcomes. @jmanico what other cryptography elements do you feel 5.0 is missing?

I added separate issues for a few things in v6!

[tghosth]

All valid questions @elarlang ill report back with outcomes. @jmanico what other cryptography elements do you feel 5.0 is missing?

I added separate issues for a few things in v6!

Where did you add those @jmanico ?

[randomstuff]

@tghosth

Does it fit better into V9 with other TLS stuff?

The V6 chapter is now called "Stored Cryptogtaphy" and not "Cryptogtaphy". Do we want that? There are things here (such as random values) which are applicable in many different contexts (such as access tokens) which don't really fall into the "stored crypography".

ECH would definitely fit into V9 however.

[tghosth]

Having read through this a little more and also looking at the discussion on what should go into which chapter, I think this is more related to TLS/secure communications rather than pure cryptography. I think you could argue it both ways but for that reason plus the fact that TLS is mostly discussed in V9, I think it is better in V9.

I also agree that it is important enough to be specifically included although I would argue that maybe it should be L3.

@danielcuthbert would you mind closing #2359 and opening a new PR to add it as 9.4.4.