search

sftcd / wkesni

A well-known URI for publishing ESNIKeys
7 stars 2 forks source link

needs a better security argument #18

Closed sftcd closed 2 months ago

sftcd commented 3 months ago

Part of @martinthomson's review

It might be the case that the design is fundamentally sound, but it isn't clear to me that this is true.

We can try add text to the security considerations that argues that the design meets some security goal(s) and we can discuss that text as we go forward.

sftcd commented 3 months ago

I took a not very good stab at this in #24 - needs work though...

bemasc commented 3 months ago

I think the trickiest thing about this is the cyclic interaction between WebPKI and DNS. For example, if the origin's certificates are issued via ACME with an HTTP-01 challenge, and the ACME client respects HTTPS records, then an attacker who transiently compromises the secure origin could insert HTTPS records that point to its own servers, receive the subsequent ACME challenge, answer it, and become the validated holder of this and subsequent certificates. (This is a form of "transient to persistent attack upgrade".)

I doubt any ACME servers support HTTPS records today, but the standard doesn't exactly forbid it. (The standard does require servers to use insecure HTTP, but Let's Encrypt bends this rule to implement insecure "https://".)

As long as we aren't updating the A/AAAA records, this can be resolved by emphasizing that ACME servers are required to use only the A/AAAA records, since HTTPS records do not apply to insecure HTTP, by definition.

sftcd commented 3 months ago

Fair point and defo worth a mention. Feel free to add some text or I can in a while.

sftcd commented 3 months ago

I just pushed some text about that ACME issue to #24.

richsalz commented 2 months ago

Merged in #24, with Ben's suggestions and others. Closing this.