On Sun 2021-12-12 07:58:08 -0500, Robert Evans wrote: > Yes. It is reasonable to leave room for clients to validate for measurement > or analysis purposes that have no effect on authoritative operators. > > Perhaps you can consider changing the "SHOULD NOT" in that section to "MUST > NOT". > > Or perhaps it would be better to reframe this section as "MUST accept any > certificate presented" rather than framing this around MAY validate and > MUST NOT reject invalid certs.
Thanks for this suggestion, Robert. I'm proposing the attached change to address it. Joey and I are trying to push out a draft -02 soon, and it should be included in that revision. --dkg
From 0e05878a7814100a994e38515a33f3dc280b0354 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor <[email protected]> Date: Tue, 25 Jan 2022 11:08:11 -0500 Subject: [PATCH] Clarify that failed server authentication MUST NOT cause cleartext fallback Robert Evans suggested clearer text here, thanks! I also took the opportunity to remove the line about not suggesting what name to use for authentication, since we do actually offer a suggestion. --- unilateral-probing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/unilateral-probing.md b/unilateral-probing.md index 8410808..a9b7cb8 100644 --- a/unilateral-probing.md +++ b/unilateral-probing.md @@ -356,9 +356,9 @@ If the recursive resolver needs to send SNI to the authoritative for some reason A recursive resolver following this guidance MAY attempt to verify the server's identity by X.509 certificate or DANE. When doing so, the identity would presumably be based on the NS name used for a given query. -However, since this probing policy is unilateral and opportunistic, the client SHOULD NOT consider it a failure if an encrypted transport handshake that does not authenticate to any particular expected name. - -To avoid the complexity of authoritative servers with multiple simultaneous names, or multiple names over time, this draft does not attempt to describe what name a recursive resolver should use when validating an authoritative server, or what the recursive resolver should do with an authentication success. +However, since this probing policy is unilateral and opportunistic, the client connecting under this policy MUST accept any certificate presented by the server. +If the client cannot verify the server's identity, it MAY use that information for reporting, logging, or other analysis purposes. +But it MUST NOT reject the connection due to the authentication failure, as the result would be falling back to cleartext, which would leak the content of the session to a passive network monitor. ### Establishing an encrypted transport connection -- 2.34.1
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
