Subject: [dnsext] axfr-clarify-10 TSIG inconsistencies

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 10 Jan 2009 17:38:01 +0200

draft-ietf-dnsext-axfr-clarify-10.txt says (in section 2.6.6):

    Note that TSIG and SIG(0), if in use, will treat each individual
    AXFR response message within a session as a unit of data.  That is,
    each message will have a TSIG or SIG(0) (if in use) and the
    cryptographic check will cover just that message.

That's not what the TSIG specification says.  According to RFC2845
section 4.4, the TSIG does not have to be present on every message
(only at least every 100th message), and does not cover just that
message but the "Prior Digest", every unsigned message since the last
TSIG, and the "TSIG Timers".

I suggest removing the paragraph containing the quoted text.
-- 
Andreas Gustafsson, [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 12 Jan 2009 09:13:02 -0500

Thanks for pointing that out.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 13 Jan 2009 13:36:35 -0500

Isn't it a true statement that TSIG (2845) sets minimum requirements (e.g. at least one TSIG per 100), but that AXFR clarify can specify more stringent requirements - (e.g. a TSIG per message)?

One of the processing issues here is that you must wait until you see a TSIG before committing AXFR changes.  From a simplicity POV placing a TSIG in each message may be the right approach.

On the other hand, it may make sense to weaken 2845 and only provide a TSIG in the last message before closing an AXFR session within a TCP session.

And can you mix and match TSIG signers (e.g. different key ids in the TSIG record) during an update session?

So I don't think its as simple as removing the quoted text.

Mike

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Jan 2009 13:46:56 -0500

I don't think mixing and matching would work - the TSIG respondent 
uses the key named by the TSIG requestor.  The respondent does not 
know what key the requestor has (or still has).

I'm neutral on the other issue - AXFR could say one each per message 
or stay as "lax" as the TSIG spec.  What do others say?

At 13:36 -0500 1/13/09, Michael StJohns wrote:
>Isn't it a true statement that TSIG (2845) sets minimum requirements 
>(e.g. at least one TSIG per 100), but that AXFR clarify can specify 
>more stringent requirements - (e.g. a TSIG per message)?
>
>One of the processing issues here is that you must wait until you 
>see a TSIG before committing AXFR changes.  From a simplicity POV 
>placing a TSIG in each message may be the right approach.
>
>On the other hand, it may make sense to weaken 2845 and only provide 
>a TSIG in the last message before closing an AXFR session within a 
>TCP session.
>
>And can you mix and match TSIG signers (e.g. different key ids in 
>the TSIG record) during an update session?
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Jan 2009 15:38:13 -0500

Expanding more on the suggestion to restrict TSIG for AXFR to each 
message (as opposed to not):

- During the development of DNSSEC, there was once an AXFR signature. 
It came at the conclusion of the transfer and was cognizant of the 
order of the records.  During early prototyping, it proved to be too 
much of a pain, further, it was redundant to the information in the 
NXT and NXT signatures.

The TSIG spec is not exactly the same.  My first concern about using 
one TSIG for multiple (or all) the messages in an AXFR response is 
reordering - but AXFR has to be in (MUST) TCP or (theoretically) any 
stream-oriented protocol.

TSIG only looks at messages, not the data inside, as did the AXFR 
signatures.  Don't know what that means significance-wise.

- To me the issue is whether we want AXFR to odd-ball the TSIG spec 
by doing one message per TSIG or have to put up with the overhead of 
having to hold back a pool (FIFO buffer) of messages until the TSIG 
appears for the check.

At 13:46 -0500 1/13/09, Edward Lewis wrote:
>>Isn't it a true statement that TSIG (2845) sets minimum 
>>requirements (e.g. at least one TSIG per 100), but that AXFR 
>>clarify can specify more stringent requirements - (e.g. a TSIG per 
>>message)?
>>
>>On the other hand, it may make sense to weaken 2845 and only 
>>provide a TSIG in the last message before closing an AXFR session 
>>within a TCP session.
>>

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 14 Jan 2009 09:50:05 +0100

Hi Ed,

You cannot commit AXFR changes until you have obtained all of the AXFR
data.  Since this would also end your TCP stream, I would expect a TSIG
over the unauthenticated remainder of the AXFR data.  Then you have both
the data and TSIG on it.

You have to wait anyway, because you have to publish the new serial
number in one atomic publication.  So, the AXFR is going to sit
somewhere in any case until it is complete.  That place it can also wait
until it is properly authenticated.

What I mean to say is, this TSIG problem is not there.

Best regards,
   Wouter

Edward Lewis wrote:
> - During the development of DNSSEC, there was once an AXFR signature. It
> came at the conclusion of the transfer and was cognizant of the order of
> the records.  During early prototyping, it proved to be too much of a
> pain, further, it was redundant to the information in the NXT and NXT
> signatures.
> 
> The TSIG spec is not exactly the same.  My first concern about using one
> TSIG for multiple (or all) the messages in an AXFR response is
> - To me the issue is whether we want AXFR to odd-ball the TSIG spec by
> doing one message per TSIG or have to put up with the overhead of having
> to hold back a pool (FIFO buffer) of messages until the TSIG appears for
> the check.
> 
>>> One of the processing issues here is that you must wait until you see
>>> a TSIG before committing AXFR changes.  From a simplicity POV placing
>>> a TSIG in each message may be the right approach.
>>>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jan 2009 09:48:57 -0500

I think there maybe some confusion over "commit."  Yes, only after 
the "ZIT" completes and is whole is it committed to being the "ZIP." 
(T/P = Transfer/Published from an earlier email.)  But, when AXFR 
messages are being received, the ZIT is being built up in memory - 
that is the commit in question, e.g., how many messages do I have to 
hold before editing the ZIT copy?

At 9:50 +0100 1/14/09, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Ed,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>iEYEARECAAYFAkltpz0ACgkQkDLqNwOhpPiTzgCeKiy9qeK/HyQIO99D6r0yNIaF
>Z0kAoJakeRF7Xuc9EzQJ9u1L3UHsPzRj
>=3NcF
>-----END PGP SIGNATURE-----

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 14 Jan 2009 17:38:55 +0200

> hold before editing the ZIT copy?

One.  You update the digest state and the "ZIT" with each message as
it arrives and then you can immediately throw the message away.

TSIG isn't broken.  Can we please stop fiddling with it and focus on
AXFR?
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Wed, 14 Jan 2009 15:46:39 +0000

packets/bits "in-flight" are not commited.  even when they
 have arrived at the destination (but are still held up in customs).
 (you can hold zero-millions+ messages - i don't realy care)

 Only when the canonical instance has been modified is the commit 
 done.  There still might be a lag to push out the updates to the
 visible servers.

--bill

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 14 Jan 2009 14:41:19 -0500

> TSIG isn't broken.  Can we please stop fiddling with it and focus on

Yes, please!  AXFR-clarify does not have the change anything about
TSIG.  Periodic TSIGs are fine, and create no additional "message
holding" requirements on the xfer recipient.  At the TSIG level, the
intervening packets just feed into the HMAC state.

-josh

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205