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

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Mon, 12 Dec 2005 16:09:43 -0500

Well, actually there is a "bad algorithm" error code, defined in RFC 3930 in connection with the TKEY RR. However, to require its return by a server when that server receives a query with a TSIG specifying an algorithm that is not implemented or not allowed by that server would be a change to RFC 2845. 2845 specifies that a response to a query where the algorithm name is bad be, at the DNS header RCODE level, the RCODE NOTAUTH, and at the enclosed TSIG RR error code level, the error code BADKEY or BADSIG. It seems to me that it would be reasonable to add BADALG to that list and specify that it be returned under these circumstances. Given that this is effectively a "sub code" under the overall NOTAUTH error, it seems unlikely to do much harm to a resolver which is surprised by getting it. Nevertheless, this seems like something which, at a minimum, should be discussed on the DNSEXT mailing list to obtain further opinions as well as feedback by implementers of deployed TSIG co!
 de.

Olafur/Olaf: OK if I bring this idea up there?

Thanks,
Donald

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Monday, December 12, 2005 2:34 AM
To: Eastlake III Donald-LDE008
Cc: Mary Barnes; margaret wasserman; [email-masked]; Olafur Gudmundsson; Olaf Kolkman
Subject: Re: Gen-ART Review of draft-ietf-dnsext-tsig-sha-05.txt

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: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 12 Dec 2005 23:27:54 -0500

At 16:09 12/12/2005, Eastlake III Donald-LDE008 wrote:
>Well, actually there is a "bad algorithm" error code, defined in RFC 
>3930 in connection with the TKEY RR. However, to require its return 
>by a server when that server receives a query with a TSIG specifying 
>an algorithm that is not implemented or not allowed by that server 
>would be a change to RFC 2845. 2845 specifies that a response to a 
>query where the algorithm name is bad be, at the DNS header RCODE 
>level, the RCODE NOTAUTH, and at the enclosed TSIG RR error code 
>level, the error code BADKEY or BADSIG. It seems to me that it would 
>be reasonable to add BADALG to that list and specify that it be 
>returned under these circumstances. Given that this is effectively a 
>"sub code" under the overall NOTAUTH error, it seems unlikely to do 
>much harm to a resolver which is surprised by getting it. 
>Nevertheless, this seems like something which, at a minimum, should 
>be discussed on the DNSEXT mailing list to obtain further opinions 
>as well as feedback by implementers of deployed TSIG co!
>  de.
>

Adding new error codes is a big change, as I said before most implementations
took the same approach as we did in DNSSEC, each key is tied to one
algorithm. If we add BADALG then we should consider at the same time to
uncouple the hash algorithm from the secret. But it is going to much more
productive to push on getting automated TKEY exchanges to create shorter
lived TSIG keys.

         We need TSIG/SHA yesterday, so please no changes.

         Olafur (TSIG co-inventor at IETF-36)

PS: I was to propose a change to this document it would be to remove SHA1
from it.

> >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.
> >
> >@@@ 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:
> >
> >@@@ Margaret/Olafur: Should I make these changes, except for the 
> addition of algorithm negotiation and making 3645 normative?
> >
> >@@@ Thanks,
> >@@@ Donald
> >
> >