[DNSOP] Review of draft-andrews-dnsop-defeat-frag-attack-00

[Mukund Sivaraman <[e-mail]>]

Hi Mark

After the paper from last week about a new variant of a Kaminsky style
attack, I remembered seeing an email from you recently asking to adopt
the well-known TSIG key idea. I looked for it but I'm not able to find
such an email - did I imagine it? Anyway my review comments follow.

There have been a few proposals to prevent forms of off-path UDP
response poisoning which include Kaminsky style attacks, IP fragment
poisoning, etc. Your well known TSIG key idea is a good one and this
draft is well-written. I think I'd mentioned this to you privately as
well when you first brought up well known TSIG key that it was a nice
idea. The proposal has the potential to prevent all forms of off-path
UDP DNS response posioning for plain DNS over UDP going forward.

>                 Defeating DNS/UDP Fragmentation Attacks
>                draft-andrews-dnsop-defeat-frag-attack-00

I suggest changing the title of this draft to something like "Well-known
TSIG key", because the proposal helps more than just defeating IP
fragmentation attacks. A marketing title is easier to remember too. When
talking about it we're going to call it well-known TSIG key anyway, so I
suggest naming it so.

> 2.  The Well Known Key

>    The well known key has a owner name of "." and uses HMAC-SHA256
>    [RFC4635] as its algorithm with a key of 256 zero bits.

>    Should it become necessary to roll the well known key's algorithm, an
>    updated RFC should be published with new algorithm and matching key
>    definition.  The standard TSIG error response of NOTAUTH/BADALG can
>    be used to signal to try alternate algorithms.

Is it necessary to prescribe any one algorithm, if we can assume the
HMAC secret to be all 0s?

>    It is possible for servers to support multiple algorithms
>    simultaneously by trying each in turn.  Not all existing servers
>    support trying multiple algorithms/keys for the same name.

I have not followed the sentence why servers would have to try multiple
algorithms in turn - doesn't the TSIG RR contain the algorithm name?

> 3.  Using The Well Known Key

>    Clients should opportunistically attempt to use the well known key
>    and if they get an expected error they should fallback to not using
>    the well known key unless they have already had a successful
>    transaction using the well known key or have a priori knowledge that
>    the well known key is supported.

Is there a possibility of an off-path downgrade attack due to this?

>    All members of a anycast cluster of servers should use the same well
>    known keys.

I did not follow this. From the description, there is only one
well-known key - all zeros, so it is not clear what is meant by "same
well known keys". Did you mean "all members of an anycast cluster should
all implement well-known keys?"

>    When sending a request a 64 bit nonce should be added to the TSIG
>    Other Data section to increase the entropy of the request.  The TSIG
>    Other Data section currently unused in TSIG requests.

The nonce in the other data field is well thought out. I suggest
imposing a minimum of a 64-bit nonce, but not otherwise limiting the
nonce's size as it isn't required.


RFC 2845 section 4.5.2 (TIME check and error handling) states:

> If the server time is outside the time interval specified by the
> request (which is: Time Signed, plus/minus Fudge), the server MUST
> generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
> (BADTIME).  The server SHOULD also cache the most recent time signed
> value in a message generated by a key, and SHOULD return BADTIME if a
> message received later has an earlier time signed value.

On the public internet, multiple clients would use the same well known
key, and their clocks may be out of sync. Also, due to path conditions,
different clients' requests generated at the same absolute time may
arrive separated by multiple seconds at the server. So queries arriving
with time signed value in the past would be quite common.  The above
requirement should be relaxed for the well-known TSIG key.  This
proposal does not need to prevent transaction replay attacks, so all
TSIG time checks can be disabled for the well-known TSIG key.

As it requires implementation changes, you may want to consider other
aspects of this draft and see if you want to change anything.

At a bigger picture, considering DNS transport security proposals that
are being worked on and the existing DNSSEC protocol, one could question
if there is a pressing need to add this for plain DNS over UDP. However,
given how prevalent DNS over UDP is expected to be for some time, and
the potential for off-path UDP response poisoning that keeps coming up
again and again, I support adoption.

		Mukund