Hmm, so to understand properly this would require a malicious DNS server that the CNAME has been delegated to, actively trying to cause a hash collision?
That's fair. Although I do think this problem can be mitigated by using CAA with account binding? https://www.rfc-editor.org/rfc/rfc8657 I would prefer to not rely on the collision resistance of this label, since there are other methods that provide a stronger security controls here? On Sat, Mar 16, 2024 at 5:22 PM Seo Suchan <tjtn...@gmail.com> wrote: > reading it again I'm no longer sure we can say account label isn't > security perpose: entire point of this challange is those > account-specific hostname CNAMEed to some delegated dns server for acme > perpose (like https://github.com/joohoi/acme-dns). and when clients are > using 3rd part DNS hosting service for that most trivial attack method > from delegated DNS server for such dns server would be trying to create > an account that using same validation domain. While I'm think while > current way is safe enough as it needs createing more than 2^40 accounts > to expecting some collison, I don't think we can say it's non-security > and should mention this lable need some collision resistence. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
