Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

[Mukund Sivaraman <[e-mail]>]

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 <[e-mail]> 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