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

Francis Dupont <> Tue, 26 February 2019 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9379F130EAE for <>; Tue, 26 Feb 2019 01:35:33 -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 TkLBRRk5a7i8 for <>; Tue, 26 Feb 2019 01:35:32 -0800 (PST)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4481130EA9 for <>; Tue, 26 Feb 2019 01:35:31 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (8.14.7/8.14.7) with ESMTP id x1Q8sa79074112; Tue, 26 Feb 2019 09:54:36 +0100 (CET) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Mukund Sivaraman <>
In-reply-to: Your message of Mon, 19 Nov 2018 19:15:34 +0530. <20181119134534.GA1450@jurassic>
Date: Tue, 26 Feb 2019 09:54:36 +0100
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: Tue, 26 Feb 2019 09:35:34 -0000

 In your previous mail you wrote:

>  Two points that I request this WG to discuss are:
>  1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft)

=> I'd like to do this but it is not possible to change requirements
for existing implementations so easily. I added a SHOULD for signing
all messages so on the long term they should disapear.,,

>  2. Truncated MACs

=> first they are optional so not required to be implemented/supported.
Second I'd like to get the opinion from a cryptographer because I heard
that truncated HMACs have some security benefits. Last of course they
make messages shorter so have a clear operational advantage.
 Now I do not know if they are heavily used. If they are not we can consider
to add a NOT RECOMMENDED for their implementation/support even it is not
really in the scope of the document.