> On Feb 21, 2019, at 10:19 PM, Tom Pusateri <[email protected]> wrote: > > > >> On Feb 21, 2019, at 1:29 PM, Ted Lemon <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Feb 21, 2019, at 2:24 PM, Mark Andrews <[email protected] >> <mailto:[email protected]>> wrote: >>> Implementation details are beyond the scope of RFCs. >> >> Indeed they are. My point is that if you want to be careful of memory usage >> or disk usage, you can be—there is no need to use a hash. In essence, >> requiring us to use a hash is specifying an implementation detail that >> needn’t be specified: you can in fact implement this using a hash, although >> I wouldn’t. It would be nice if I were not required to implement it that >> way, since I think that’s not actually going to work reliably. >> >>> Also you mentioned caches which basically will never see these records >>> unless they are queried for. >> >> >> I mentioned caches because they are by far the biggest consumers of >> resources—authoritative name servers have much smaller memory footprints. >> I assume the reason you think using hashes is a good idea and not a >> premature optimization is because you’ve done a lot of work with caching >> name servers, and are seeing this discussion through that lens. That’s the >> wrong lens to be seeing it through. This is only relevant for >> authoritative name servers, and in that case, storing the whole >> RR-to-be-deleted is fine. >> > > I’ve been mostly listening and learning from this discussion which has been > great. Thanks for all the input. Let me summarize what I’m hearing and we > will open issues to adjust the document. > > 1. We need a motivational section to explain the purpose better > > 2. The HASH was my idea to simplify the records by making them all the same. > It appears that simplicity in this form was not noticed or not appreciated. :) > > 3. The HASH algorithm selection was intended to work long term. It was my > hope that there would only ever be one algorithm and there would never exist > the case when one implementation supported an algorithm that another > implementation did not. The HASH algorithm index was only intended to be used > if a vulnerability was found in the ONE selected algorithm and it needed > replaced. In this case, the old algorithm would be deprecated and everyone > would switch to a new single algorithm. I am strongly opposed to having more > than one HASH algorithm defined. Not being a security expert and not being > able to find any papers proving that I could take an existing algorithm like > SHA-256 that was 32 bytes and shorten it to 16 bytes using the first 16 bytes > or the last 16 bytes or 16 bytes in the middle, I opted to select an > algorithm that was already 16 bytes and proven to have terrific non-collision > properties. Since some of the RDATA can be very short (A records), there are > cases when there’s not a lot of data from which to base the hash value on. > This was another reason to start with a hash like SHAKE128. But from the > sounds of it, people prefer SHA-256 and so I will research this more to see > about its applicability in this case (if a hash is even needed anymore). > > 4. We are open to using RDATA instead of a hash. Or we can define RDATA as an > algorithm index as Mark suggested and define a hash as another algorithm (now > or later if it ever becomes a problem). By adding the record type to the > TIMEOUT instance, we have eliminated most uses of the hash already and only > in rare cases will it be needed so including large RDATA in the TIMEOUT > record should be rare. > > 5. Storing the TIMEOUT information as resource records seemed like a > convenient way to use an existing database to store timeout information > across restarts and to synchronize with secondaries. It can certainly be > stored in a proprietary database by each authoritative server vendor but > allowing them to interoperate seemed like a feature and when they each > already have a database that holds resource records, why create another > database type? But if the consensus is that the TIMEOUT info shouldn’t be > stored in the existing resource record database but instead authoritative > servers should create a new database for this info, then that is fine. This > document itself can TIMEOUT. :) >
Forgot these: 6. As far as the time format, we were simply following the recommendations of RFC 3339 for presentation. But if DNS has it’s own format preferences and the IESG is ok with this, so are we. Following RFC 3339 is a SHOULD, therefore, there must be exceptions allowed but I’m not aware of the rules here. 7. As far as the timestamp as a 64-bit number, this is the current recommendation as well (and what is returned by gettimeofday()). So every authoritative server is having to modify the output and do more work to transform it into RFC 1982 serial number arithmetic now. But, again, we are flexible and as long as the IESG will approve it, we can do it the old way. 8. Mark said: "The record MUST be in canonical DNSSEC form ([RFC4034] Section 6)”. I will update Section 4.5 to reflect this. Tom
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
