> On 19 Feb 2019, at 11:47 am, Tom Pusateri <pusat...@bangj.com> wrote: > > Mark, > >> Just closing the issue isn’t addressing it. > > That’s not a fair point about closing issue #19. > > Your main concern was that SHA-3 algorithms might not be easily available > but, luckily, they shipped with TLS 1.3 in OpenSSL 1.1.1 and so I thought #19 > was a solved issue. > > Regardless, sooner or later, someone will be the first to use a SHA-3 > algorithm that’s better than the SHA-2 algorithms DNS uses today. It’s only a > matter of time. SHA-3 has been out since 2015. As soon as you support TLS > 1.3, you’ll have all the SHA-3 algorithms with a simple API call and it > should be available everywhere because TLS 1.3 will be needed everywhere.
Where is the need to use SHA-3? This is introducing a new algorithm for the sake of introducing a new algorithm. Just because TLS 1.3 uses SHAKE128 is not a reason for DNS to use SHAKE128. There are plenty of platforms that don’t need to use TLS at all. They don’t have web interfaces. Transaction security is provided by something other than TLS. There are also lots of old server platforms that just won’t ever upgrade their OpenSSL package. Adding SHA-3 creates yet another dependancy / impediment-to upgrading the DNS server. And before someone mentions DoT and DoH. DoT/DoH have their uses but not everywhere needs to use DoT/DoH. DoT/DoH adds baggage which isn’t always justified. Mark > I will reopen this issue for discussion but I don’t see yet how this is a > problem. > > Thanks, > Tom > >> On Feb 18, 2019, at 7:27 PM, Mark Andrews <ma...@isc.org> wrote: >> >> I have yet to seen a justification for using SHAKE128 vs any of the existing >> hash algorithms used in DNS. You really need to justify this choice on >> security >> concerns. DNS server implementers need to support multiple crypto backends >> and >> adding yet another algorithm is not as easy as just calling OpenSSL. It’s >> writing / >> expanding a shim layer. It’s checking for the existence on all the platforms >> the server is built on. >> >> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19 >> >>> On 19 Feb 2019, at 10:34 am, Tom Pusateri <pusat...@bangj.com> wrote: >>> >>> DNSOP, >>> >>> We have updated the TIMEOUT resource record draft based on the great >>> feedback from Mark Andrews, Joe Abley, Ted Lemon, and Paul Vixie. I think >>> we have addressed all of the comments except for the Date format concern >>> from Mark. That is still an outstanding issue. Please comment on it if you >>> have an opinion or feel free to open other issues against the document or >>> send comments to the list. >>> >>> The TIMEOUT RR is just like any other resource record now with no special >>> handling. >>> >>> Issues are on Github: >>> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues >>> >>> Thanks, >>> Tom & Tim >>> >>> >>>> Begin forwarded message: >>>> >>>> From: internet-dra...@ietf.org >>>> Subject: New Version Notification for >>>> draft-pusateri-dnsop-update-timeout-01.txt >>>> Date: February 18, 2019 at 6:26:35 PM EST >>>> To: "Tim Wattenberg" <m...@timwattenberg.de>, "Tom Pusateri" >>>> <pusat...@bangj.com> >>>> >>>> >>>> A new version of I-D, draft-pusateri-dnsop-update-timeout-01.txt >>>> has been successfully submitted by Tom Pusateri and posted to the >>>> IETF repository. >>>> >>>> Name: draft-pusateri-dnsop-update-timeout >>>> Revision: 01 >>>> Title: DNS TIMEOUT Resource Record >>>> Document date: 2019-02-18 >>>> Group: Individual Submission >>>> Pages: 13 >>>> URL: >>>> https://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-01.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-pusateri-dnsop-update-timeout/ >>>> Htmlized: >>>> https://tools.ietf.org/html/draft-pusateri-dnsop-update-timeout-01 >>>> Htmlized: >>>> https://datatracker.ietf.org/doc/html/draft-pusateri-dnsop-update-timeout >>>> Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-pusateri-dnsop-update-timeout-01 >>>> >>>> Abstract: >>>> This specification defines a new DNS TIMEOUT resource record (RR) >>>> that associates a lifetime with one or more zone resource records >>>> with the same owner name, type, and class. It is intended to be used >>>> to transfer resource record lifetime state between a zone's primary >>>> and secondary servers and to store lifetime state during server >>>> software restarts. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
