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
