Expand draft to use dns-scoping & create DNS-01 #34
Conversation
* Update Amir's Company
Co-authored-by: Aaron Gable <[email protected]>
…eration, reference kid in introduction
aaomidi
changed the title
draft-ietf-acme-dns-account-01.mkd
Outdated
| _NODE NAME: _acme-challenge_* | ||
| Reference: This document | ||
| ~~~ | ||
| The first 10 bytes were picked as a tradeoff: the value needs to be short enough to not significantly impact DNS record and response size, long enough to provide sufficient probability of collision avoidance across ACME accounts, and just the right size to have Base32 require no padding. As the algorithm is used for a uniform distribution of inputs, and not for integrity, we do not consider the trimming a security issue. |
There was a problem hiding this comment.
The main length concern was to make sure we didn't place additional pressure on the max length of DNS names (253) and make the challenge unusable for abnormally large names. (Statistically there are very very few when I ran this against Censys many years ago.)
I don't think we were too concerned about record size or response size, but it is fine to keep that in.
There was a problem hiding this comment.
I think by record size we meant the label size. The thing is, 253 is the soft limit I believe right? Else it just gets fragmented and forced into TCP?
There was a problem hiding this comment.
I've clarified this a bit now
There was a problem hiding this comment.
The max valid length of a DNS name is 253 characters. The max label length is 63. So the full sha256 digest could fit into a base32 encoded label, but it would make more DNS names theoretically not be able to use this challenge.
https://devblogs.microsoft.com/oldnewthing/20120412-00/?p=7873
Certainly smaller responses in general are always preferred to avoid issues with fragmentation attacks.
https://www.ietf.org/archive/id/draft-ietf-dnsop-avoid-fragmentation-16.html
Co-authored-by: James Kasten <[email protected]>
No description provided.