Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-02.txt

From: [email-masked]
Date: Mon, 19 Nov 2018 04:56:50 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Secret Key Transaction Authentication for DNS (TSIG)
        Authors         : Francis Dupont
                          Stephen Morris
                          Paul Vixie
                          Donald E. Eastlake 3rd
                          Olafur Gudmundsson
                          Brian Wellington
	Filename        : draft-ietf-dnsop-rfc2845bis-02.txt
	Pages           : 26
	Date            : 2018-11-19

Abstract:
   This protocol allows for transaction level authentication using
   shared secrets and one way hashing.  It can be used to authenticate
   dynamic updates as coming from an approved client, or to authenticate
   responses as coming from an approved name server.

   No provision has been made here for distributing the shared secrets.

   This document includes revised original TSIG specifications (RFC2845)
   and its extension for HMAC-SHA (RFC4635).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc2845bis-02
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc2845bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 19 Nov 2018 19:15:34 +0530

Hi Stephen, Francis

> 	Filename        : draft-ietf-dnsop-rfc2845bis-02.txt

First, I want to point out that this is a bis document and not errata,
so it need not (and should not) be limited to just fixing the TSIG
authenication bypass attack. I strongly feel that RFC 2845 is unclearly
specified, and TSIG (the protocol) is over-specified. This bis revision
should make amends.

Two points that I request this WG to discuss are:

1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft)

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.

I previously reviewed this bis draft here:
https://www.ietf.org/mail-archive/web/dnsop/current/msg21227.html

Many of my review comments were responded to with the terse "17y"
comment by one of the authors.

However, ome of the comments from my previous review have been
incorporated into the current document, but some have not. I
specifically request Stephen to read the comments in my previous review
carefully comparing against the current text in context, because I feel
some of those changes still have to be made.

Soon after this TSIG authentication bypass attack was reported, during a
review of the BIND TSIG implementation by Ray Bellis and me, we found a
couple of other issues. One of them is not a real-world issue (to do
with under-specification of what to do with full MAC length having
non-integral number of octets - there are no such common HMACs
currently), and another that I'm not able to remember that had to do
with an off-by-1 (or something similar) on the fudge and time signed
fields. Do you have any recollection of it Ray?

		Mukund

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Nov 2018 11:42:06 +0000

> fields. Do you have any recollection of it Ray?

I vaguely recall the discussion but not the detail of it.

ISTR it was something to do with using a <= comparison rather than <, or 
vice versa.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Nov 2018 09:29:03 +1100

> On 20 Nov 2018, at 12:45 am, Mukund Sivaraman <[email-masked]> wrote:
> 
> Hi Stephen, Francis
> 

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.

> these on this list before, but won't restate comments in support here to

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.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 21 Nov 2018 14:59:20 +0530

Hi Mark

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

> 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

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 28 Nov 2018 14:00:53 +0530

> > 	Filename        : draft-ietf-dnsop-rfc2845bis-02.txt

When investigating a TKEY related implementation bug, I notice that the
text in RFC 3645 is not very clearly written about prohibiting TSIG
signed responses for some error conditions (e.g., section 4.1.3 where
the writing seems to assume paragraph contexts). I recommend that you
check the various cases in RFC 3645 to make sure the protocol doesn't
allow inclusion of arbitrary or invalid request MAC in response TSIG MAC
computation, and state this so in the bis draft.

In any case, the text in the draft has to be updated for the relaxation
in RFC 3645 section 2.2. It wouldn't be so bad if the two RFCs can be
merged as part of this bis work.

		Mukund