Subject: [Gen-art] Gen-ART Review of draft-ietf-dnsext-tsig-sha-05.txt

From: Elwyn Davies <[email-masked]>
Date: Fri, 09 Dec 2005 18:45:56 +0000

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary:
This document appears to have some issues, one significant and some 
minor ones.  This document updates RFC2845 but it does not appear to 
consider interoperability with existing implementations.  A related 
issue is that it defines a number of optional to implement features but 
does not appear to indicate how a receiver can inform a sender that it 
does not support the sender's chosen algorithm (an RFC2845 
implementation just supports one algorithm) and at a quick glance I 
couldn't find anything in RFC2845 that covers this issue.  There are 
also some editorial nits.

Details:

s2: This specification introduces a number of optional to implement 
algorithms but doesn't appear to have any way for a recipient to notify 
the sender that it does not support the sender's chosen algorithm and 
what should happen in this case.  This also has a bearing on 
interoperability between new senders (conforming to this draft) and old 
receivers that only support RFC2845.  Some words on interoperability 
should be included.  Consideration should also be given to whether the 
resulting specification is vulnerable to a bidding down attack.

s2: I am not sure why the gss-tsig identifier doesn't appear as an 
Optional entry in the table at the end of the section.

s3.1: The statement in the last para that the protocol SHOULD support 
SHA-1 truncated to 96 bits seems a bit out of place in this section.  It 
probably deserves a separate section however short and possibly a 
mention in the policy section as it is implying that this is a good 
thing to generate/accept.

s9:  I think RFCs 3174, 3645 and 3874 plus the [SHA2draft] references 
are normative since they specify algorithms which are used by this protocol.

Editorial:

Abstract/Intro: Lots of acronyms need expanding, including TSIG, DNS, 
GSS, HMAC, SHA.

s1, para 3: s/meaning/effect/

s4, para 1: s/doucment/document/
s4, para 5: s/spearate/separate/

s6, para 1: s/brute force/break the authentication by brute force/

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Thu, 15 Dec 2005 12:33:43 -0500

Hi,

On a point raised earlier, I think the statement that HMAC-SHA-1 truncated to 96 bits SHOULD be supported should be moved from section 4 to section 2, since most or all of the other implementation requirements are in section 2.

See below at @@@

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2005 6:05 AM
To: Ólafur Guðmundsson
Cc: Eastlake III Donald-LDE008; margaret wasserman; [email-masked]; Olaf Kolkman
Subject: Re: Gen-ART Review of draft-ietf-dnsext-tsig-sha-05.txt

Hi.

Ólafur Guðmundsson wrote:

> Actually the TISG_BADKEY error code is used when the key requested 
> does not exist at server.
> Standard TSIG processing (as implemented) is requires exact match 
> between key-name and algorithm.
>
> But the higher level issue you raised (implicitly), is "a secret is a 
> secret so it should be useful with any of the available algorithms".
> In this case there is a downgrade attack possible but so far I know of 
> no implementations that separates the secret from the an algorithm 
> used.
>
>         Olafur
>
In the light of this discussion, I would suggest adding some additional words about the expected behaviour, to s2.
- Indicating that the client will get TSIG_BADKEY back either if it uses an algorithm that was unsupported or if the key isn't right.

@@@ Right now RFC 2845 says that you get back TSIG_BADKEY if the algorithm is "unknown". It seems reasonable to interpret that as including algorithms disabled by policy and adding some clarifying text seems like a good idea.

- Reinforcing the idea that a given client and server are expected to settle on a particular algorithm and key pair out of band so that getting the above error for either reason is unexpected: If I understand correctly the client would not be expected to cycle through a set of available (algorithm, key) pairs in the event of getting an error - because it would only have one it thought acceptable.

@@@ Pretty much. Keys generally have validity periods and it is certainly reasonable that two valid keys be in place since you would want to set up the next one before the previous one expires. There is nothing particularly prohibiting having lots of keys and algorithms set up, but in that case one would expect any of them to work, if you are within its validity period.

Looking again at the document I think that maybe the words in the first para of s4 might mislead the uninformed (like me):  it says 'policies as to acceptable *keys and algorithms*' - my emphasis on plurals.  My reading of this was that a particular resolver and server might have multiple options and  hence some choice was involved and you might get error conditions.  This was exacerbated by the rest of the section which seems to imply the possibility of dynamic choice of how much truncation to apply and appears to give the possibility that a client might retry if the server rejects an overly truncated MAC. I think this needs to be redrafted to be very precise about what would be agreed and to clarify whether a client might be expected to retry and under what circumstances

@@@ Yes, revision in this wording to avoid incorrect implications would be good. On the other hand, while the space of possible key names and algorithm name is too large to search, assuming a resolver and server are agreed on the algorithm and key, it would not take very many probes to determine the allowable truncation and, while it is not what I would normally expect to happen, I don't see any good reason to prohibit such behavior.

@@@ Most TKEY modes (RFC 2930) result in a key name, key value, and algorithm being set up at the resolver and server. There is currently no provision in TKEY for also setting a truncation limit as part of that set but the format of TKEY was designed so that it would be possible to add one or more fields later. Possibly extending TKEY to add an optional truncation limit parameter should be considered for the future.

- To repeat, what I think I am hearing from the email discussion is that a given client and server will agree out of band on a single (algorithm, key) pair and I could (would?) interpret that as also agreeing on the amount of truncation to be used.

@@@ That's generally true. However, truncation is such a straightforward thing that it is reasonable to say, as this draft does, that you SHOULD accept something that has less than the agreed truncation (i.e., is longer and stronger).

Regards,
Elwyn

@@@ Thanks,
@@@ Donald

> At 02:34 12/12/2005, Elwyn Davies wrote:
>
>> A suggestion for the first issue below: Otherwise all is fine.
>>
>> Regards,
>> Elwyn
>>
>> Eastlake III Donald-LDE008 wrote:
>>
>>> Hi,
>>>
>>> See comments below at @@@
>>>
>>> -----Original Message-----
>>> From: Elwyn Davies [mailto:[email-masked]] Sent: Friday, 
>>> December 09, 2005 1:46 PM
>>> To: [email-masked]; Mary Barnes; Eastlake III Donald-LDE008; 
>>> Margaret Wassermann
>>> Subject: Gen-ART Review of draft-ietf-dnsext-tsig-sha-05.txt
>>>
>>> I was selected as General Area Review Team reviewer for this 
>>> specification (for background on Gen-ART, please see 
>>> @@@ Thanks for this detailed review.
>>>
>>> Summary:
>>> issue is that it defines a number of optional to implement features 
>>> but does not appear to indicate how a receiver can inform a sender 
>>> that it does not support the sender's chosen algorithm (an RFC2845 
>>> @@@ See below.
>>> algorithms but doesn't appear to have any way for a recipient to 
>>> notify the sender that it does not support the sender's chosen 
>>> algorithm and what should happen in this case.  This also has a 
>>> bearing on interoperability between new senders (conforming to this
>>> draft) and old receivers that only support RFC2845.  Some words on 
>>> interoperability should be included.  Consideration should also be 
>>> given to whether the resulting specification is vulnerable to a 
>>> bidding down attack.
>>>
>>> @@@ The general conception for TSIG was that the algorithm, which 
>>> was intended to always be a keyed MAC such as an HMAC, would be 
>>> pre-arranged out of channel and statically configured at both ends.
>>> TSIG (and DNS in general) is not a symmetric peer-to-peer protocol 
>>> but a client-server (resolver-server) protocol so one would 
>>> generally think that the server operator would just dictate this to 
>>> the client/customer. Keep in mind that this is a pretty light weight 
>>> mechanism and it is assumed that both ends have approximately 
>>> synchronized clocks with a small time window for each response 
>>> outside of which replies are rejected. If there were two possible 
>>> algorithms but you were sure you had the keying material correct, it 
>>> would just take one UDP round trip to check if an algorithm was the 
>>> acceptable one. (There are mechanisms for negotiating the shared 
>>> secret key. See TKEY, RFC 2930.)
>>>
>>> @@@ While I have no problem with the concept of providing algorithm 
>>> negotiation, perhaps via the OPT RR, it would be a MAJOR change 
>>> requiring extensive discussion on the DNSEXT (or some other) mailing 
>>> list. Given the severely broken nature of MD5 and the desire of some 
>>> to use a NIST approved algorithm, I believe it unwarranted to delay 
>>> providing a standard interoperable way to use HMAC's of the SHA 
>>> series instead of HMAC-MD5.
>>>
>> I have no problem with the general concept and I agree that you 
>> probably don't want to go in for full blown algorithm negotiation.  I 
>> think it would be sufficient to provide a separate error code that 
>> indicates that the server doesn't support the algorithm used.  I 
>> didn't see such an error code defined anywhere.  It is then up to 
>> client policy as to what it does about this.
>>
>> Regards,
>> Elwyn
>>
>>> @@@ I guess it was just that these are all HMAC algorithms and 
>>> gss-tsig isn't. But I would have no objection to adding gss-tsig to 
>>> this table.
>>>
>>> SHA-1 truncated to 96 bits seems a bit out of place in this section.  
>>> It probably deserves a separate section however short and possibly a 
>>> @@@ I'm not sure I see the need for a separate section but I have no 
>>> big objection to it.
>>>
>>> s9:  I think RFCs 3174, 3645 and 3874 plus the [SHA2draft] 
>>> references are normative since they specify algorithms which are 
>>> used by this protocol.
>>>
>>> @@@ OK except for 3645. That is a separate specification, although 
>>> it also modifies RFC 2845, referenced only for informative purposes.
>>>
>>>
>>> Editorial:
>>>
>>> Abstract/Intro: Lots of acronyms need expanding, including TSIG, 
>>> DNS, GSS, HMAC, SHA.
>>>
>>> @@@ OK, they should probably be expanded in the Abstract and when 
>>> first used.
>>>
>>> @@@ These all look reasonable and I'd be happy to make them.
>>>
>>> @@@ Margaret/Olafur: Should I make these changes, except for the 
>>> addition of algorithm negotiation and making 3645 normative?
>>>
>>> @@@ Thanks,
>>> @@@ Donald
>>>
>