Move name validation #642
Move name validation #642
Conversation
This is partly motivated by my interests in doing something evil, but mostly this is because coupling name validity to ECH config validity is a layering violation. It's fine to invoke some name validation, but that should be dictated by the needs of the thing that ends up relying on that name. This corrects both problems. In doing this, I realized that RFC 791 says nothing about the IP address textual format. That's problematic, but I couldn't come up with anything better in short notice. Closes tlswg#628. Closes tlswg#637.
Co-authored-by: David Benjamin <[email protected]>
|
@bemasc any objections? |
Co-authored-by: Benjamin M. Schwartz <[email protected]>
| Prior to attempting a connection, a client SHOULD validate the `ECHConfig` to | ||
| ensure that the public_name can be authenticated. Clients SHOULD ignore any |
There was a problem hiding this comment.
One change I see compared to the earlier text is "ensure that the public_name can be authenticated".
What does "authenticated" mean exactly in this context?
There was a problem hiding this comment.
That it can be bound to a valid WebPKI certificate. With that said, I agree that this text is confusing, because the "to ensure" is actually the purpose of the validation, rather than a separate requirement, so I propose to just remove "to ensure..." and following. @bemasc any objections?
There was a problem hiding this comment.
I think it would be clearer to remove this whole sentence. It seems to be redundant with the next sentence (which is also repeated by the sentence after that!), and asking clients to "validate" without explaining what that entails seems odd.
This keeps MT's move but adopts the IP address rejection rule from before. From #638