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

From: Elwyn Davies <[email-masked]>
Date: Mon, 12 Dec 2005 07:34:07 +0000

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 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>@@@ Thanks for this detailed review.
>
>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.
>
>@@@ See below.
>
>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.
>
>@@@ 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

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

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

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Sun, 11 Dec 2005 21:19:58 -0500

Hi,

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

Summary:

@@@ See below.

Details:

Editorial:

@@@ Thanks,
@@@ Donald

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 12 Dec 2005 23:15:44 -0500

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

At 02:34 12/12/2005, Elwyn Davies wrote:
>>From: Elwyn Davies [mailto:[email-masked]] Sent: Friday, 
>>December 09, 2005 1:46 PM
>>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).
>>
>>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.
>>
>>@@@ See below.
>>
>>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.
>>
>>@@@ 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
>
>>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.
>>
>>@@@ 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 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.
>>
>>@@@ 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.
>>
>>@@@ Margaret/Olafur: Should I make these changes, except for the 
>>addition of algorithm negotiation and making 3645 normative?
>>
>>@@@ Thanks,
>>@@@ Donald
>>

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 13 Dec 2005 11:04:48 +0000

Hi.

> no implementations that separates the secret from the an algorithm
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.
- 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.

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

Regards,
Elwyn

>>> 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.
>>>
>>> @@@ See below.
>>>
>>> Details:
>>>
>>> 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.)
>>>
>>> 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.
>>>
>> 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
>>
>>> possibly a mention in the policy section as it is implying that this 
>>> is a good thing to generate/accept.
>>>