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

Mukund Sivaraman <> Wed, 21 November 2018 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C804B129AB8 for <>; Wed, 21 Nov 2018 01:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lYSMai0b6IS6 for <>; Wed, 21 Nov 2018 01:29:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5BC7312958B for <>; Wed, 21 Nov 2018 01:29:27 -0800 (PST)
Received: from jurassic (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5EC3E32C0754; Wed, 21 Nov 2018 09:29:24 +0000 (UTC)
Date: Wed, 21 Nov 2018 14:59:20 +0530
From: Mukund Sivaraman <>
To: Mark Andrews <>
Message-ID: <20181121092920.GA10342@jurassic>
References: <> <20181119134534.GA1450@jurassic> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Nov 2018 09:29:30 -0000

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 <> 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).