> On 20 Nov 2018, at 12:45 am, Mukund Sivaraman <m...@mukund.org> wrote: > > Hi Stephen, Francis > > On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >> Title : Secret Key Transaction Authentication for DNS (TSIG) >> Authors : Francis Dupont >> Stephen Morris >> Paul Vixie >> Donald E. Eastlake 3rd >> Olafur Gudmundsson >> Brian Wellington >> Filename : draft-ietf-dnsop-rfc2845bis-02.txt >> Pages : 26 >> Date : 2018-11-19 > > First, I want to point out that this is a bis document and not errata, > so it need not (and should not) be limited to just fixing the TSIG > authenication bypass attack. I strongly feel that RFC 2845 is unclearly > specified, and TSIG (the protocol) is over-specified. This bis revision > should make amends. > > Two points that I request this WG to discuss are: > > 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft)
I would accept not generating sparsely TSIG signed TCP continuation messages (except for test code) immediately. It will take many years before one could remove the validation side as you need to ensure that all you current peers don’t generate that style of stream. Time of publication +10 years if you want to remove the validation side. By that time there should be very few legacy peers. Add a bit about logging when STSTCM is seen on a connection so it becomes noisy. Include the cut off date. This logging will unfortunately be on the wrong end of the connection but will give some indication of the expected breakage. Start logging at publication date +8 years so the noise is around the breakage time and not immediately. > 2. Truncated MACs > > I feel both should be obsoleted now to reduce implementation complexity > and scope for errors causing authentication bypass. I have talked about > these on this list before, but won't restate comments in support here to > prejudice discussion. This is more complicated. Removing code support will break existing configurations that are using truncated hashes. This would require deciding a cut off date (publication +10 years), logging when used including the cut off date. This is basically human to human rather than machine to machine. Code gets updated. Humans don’t. > I previously reviewed this bis draft here: > https://www.ietf.org/mail-archive/web/dnsop/current/msg21227.html > > Many of my review comments were responded to with the terse "17y" > comment by one of the authors. > > However, ome of the comments from my previous review have been > incorporated into the current document, but some have not. I > specifically request Stephen to read the comments in my previous review > carefully comparing against the current text in context, because I feel > some of those changes still have to be made. > > Soon after this TSIG authentication bypass attack was reported, during a > review of the BIND TSIG implementation by Ray Bellis and me, we found a > couple of other issues. One of them is not a real-world issue (to do > with under-specification of what to do with full MAC length having > non-integral number of octets - there are no such common HMACs > currently), and another that I'm not able to remember that had to do > with an off-by-1 (or something similar) on the fudge and time signed > fields. Do you have any recollection of it Ray? > > Mukund > > _______________________________________________ > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
