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

[Ólafur Guðmundsson /DNSEXT co-chair <[e-mail]>]

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.
>
>Olafur/Olaf: OK if I bring this idea up there?


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.

>Thanks,
>Donald
>
>-----Original Message-----
>From: Elwyn Davies [mailto:[e-mail]]
>Sent: Monday, December 12, 2005 2:34 AM
>To: Eastlake III Donald-LDE008
>Cc: Mary Barnes; margaret wasserman; [e-mail]; 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:[e-mail]]
> >Sent: Friday, December 09, 2005 1:46 PM
> >To: [e-mail]; 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art