Hi Mark On Wed, Nov 21, 2018 at 09:29:03AM +1100, Mark Andrews wrote: > > On 20 Nov 2018, at 12:45 am, Mukund Sivaraman <m...@mukund.org> wrote: > > 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.
This plan sounds good to me. We'll need a plan like this as NSD is the one among the popular open source nameservers that generates such continuations by default. I don't think there's even an option to turn it off - I may be wrong. BIND and Knot sign every message - IIRC Knot's behavior is based on BIND's though their code is different. > > 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. We'd have to do something similar here too - only generate full MACs and support verifying with truncated MACs (if configured so per local policy) for a period. I faintly seem to remember that perhaps Knot doesn't even support truncated MACs (I went through that code last when we were notified of the TSIG bypass vulnerability). Mukund _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop