SHOULD utilize...

[ekr]

When performing the DNS resolution during the HTTP GET request, the client SHOULD utilize
in order to prevent Man-in-the-middle attacks as well as to prevent tracking of the lookup.

Should utilize what?

[gribneau]

I think that section was referencing DoH. I'll take a look in the context of #43.

[ekr]

I do think you should use DoH, but I don't think it's that helpful to specify it as a defense against MITM attacks; that's why the TLS connection is authenticated with the WebPKI. Depending on the attacker's capabilities, it seems likely that an attacker who can attack the HTTPS connection can also attack DoH.

[gribneau]

That text was:

client SHOULD utilize <div RFC8484=""></div> in order to prevent
Man-in-the-middle attacks as well as to prevent tracking of the lookup.

I've revised the RFC reference in a recent PR, but have not updated the substance. Let's bring @kdenhartog into the conversation about DNS vulnerabilities.

[ekr]

To be clear, my point is primarily that HTTPS is designed to be secure even if the local network is totally compromised. In that case, it does not matter if DNS is secure because the attacker can just hijack the TCP connection to the server.

[kdenhartog]

Thanks @gribneau for tagging me

So are you suggesting that securing the DNS connection won't do anything and therefore this SHOULD isn't necessary? Part of the reason I went with a SHOULD here rather than a MUST was that I was thinking that there's other options available here to secure things. In particular using DNSSEC would be an alternative method although it's adoption rate was rather poor and similarly so in trusted network environments normal DNS should be fine.

@ekr what would you propose the text should be changed to?

[ekr]

@kdenhartog. I do think you should secure the DNS connection for privacy reasons.

I do not think that it adds significant security value. My reasoning here is that most attackers who can attack your DNS resolution can also intercept your TCP connections directly, and therefore having accurate A/AAAA records (whether via DoH or DNSSEC) does not meaningfully increase security. The security of HTTPS rests on the WebPKI and we generally assume that there is an on-path attacker who is able to intercept the TCP connection (see RFC 3552)

[kdenhartog]

I'm not sure I fully buy the assumption, because my understanding was that DNSSEC was designed to sign the records in order to provide integrity guarantees for the records. The intent behind the original statement was to pickup integrity guarantees off the optional features available today such as DoH or DNSSEC. Are you suggesting that because an attacker can intercept the TCP connection they can also break the integrity guarantees in a non-tamper evident way?

Also, just so we're clear what are you proposing for the text to be changed to? Your rationale seems fairly reasonable and so we may find that the proposed text you put forward will be suffice for both of us without needing to establish a clear threat model first.

[ekr]

I'm saying that the integrity guarantees are to a value (the A/AAAA record) which is not cryptographically bound to the connection, and so don't buy you much. Note that things would be different if we were using DANE/TLSA, but we are not.

I proposed a PR. #48

[kdenhartog]

Sweet I hadn't seen that text - I'm in alignment with what you're proposing. Thanks for clarifying what you meant.