Dear Joshua, Thanks a lot for your suggestions. >Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;). Yes I understand. It was a mistake. In my implementation I did not make this funny mistake but it seems in writing I did :-) If I can update my RFC (currently having formatting issue for uploading...) then the new version will hopefully be free of these kinds of mistakes.
>Regarding 4), Check Time Signed, if you look at a widely used standard like >Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes of >anti-replay prevention (which I believe this step in >your protocol is >designed to thwart?) it seems to provide good security without causing too >many issues (but you still do get clients with errors popping up from time to >time). Lastly regarding 5), >signature, that's fine, you just may want to be >specific that RSASSA-PSS (or something else) should be used rather than >leaving it up to interpretation or preference, which may cause >interoperability >issues. Just a suggestion. I clarified this in new version. Maybe somebody can give me a suggestion... I actually wrote a Web application that should aid in formatting RFC (maybe also later useful for others as it will be available public on my website). It works fine and generates a nice txt version with the required tags but when I want to submit this draft I receive meta-data error and it cannot retreive the authors' names. I compared the output of my application with the one that does not have any problem in different formats such as ASCII, but I could not find any special characters or any problem that cause this failure result. I look forward to receiving any help I can get to make this application generate a file that is acceptable for automatic process submission. (If I knew what the IETF parser was looking for, I could add it to my application to make it work. But I could not find anything anywhere) Best, Hosnieh -----Original Message----- From: Joshua Shire [mailto:[email protected]] Sent: Monday, November 19, 2012 10:05 PM To: Rafiee, Hosnieh Cc: [email protected] Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thanks for your responses. Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;). Regarding 4), Check Time Signed, if you look at a widely used standard like Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes of anti-replay prevention (which I believe this step in your protocol is designed to thwart?) it seems to provide good security without causing too many issues (but you still do get clients with errors popping up from time to time). Lastly regarding 5), signature, that's fine, you just may want to be specific that RSASSA-PSS (or something else) should be used rather than leaving it up to interpretation or preference, which may cause interoperability issues. Just a suggestion. Thanks, Joshua Shire Information Systems Manager Hyduke Energy Services Inc. ph: 780-955-0401 fax: 780-955-0368 mx: [email protected] -----Original Message----- From: Rafiee, Hosnieh [mailto:[email protected]] Sent: Friday, November 16, 2012 4:49 PM To: Joshua Shire Cc: [email protected] Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Dear Joshua, Thank you so much for your comments. Please find the answer below. >1) RFC3972 ("CGA") specifies that the modifier should be 64 bits and the >collision count eight bits, yet I notice in Figure 2 it specifies a 16 bit >modifier and a 1 bit collision count. Can you explain why you chose to >implement this differently? - No, that was a typo. It will be corrected in the updated version that I will submit this weekend 2) In your implementation of the protocol you call for DAD but it does not mention (or maybe I just can't find) what do re: collision count if a duplicate address is detected. Further, in 3.2.1.2 I don't see a step to verify this number as per CGA. I'm assuming you're to follow the specs from CGA but you may want to be specific regarding this. - After I implemented this draft RFC, I noticed that the values must be cached and the DNS server should not be involved in generating CGA values or be involved in addressing. So, this section is for the SEND implementation installed on a DNS server or a client. In my new draft this section will also be updated. 3) In 3.1 step 5 you may want to be clear that bits seven and eight should be set to zero. -I will correct it and included in my update version. 4) In 3.2.1.2, step 2, Check Time Signed, your window seems very short given typical retransmission timeouts and the like. - I will examine my implemenation on a larger scale to see what the delay will be and will update the document accordingly. 5) 3.2.1.2 step 5, Verify the signature, I don't see exact method you want used in this protocol to accomplish this. - Please clarify this question. As you probably know, the signature verification function uses a minimum of 2 values; the plaintext and the signature itself. The default algorithm here is RSA. This is what I meant when I said signature verification. The DNS server retreives all the plaintext contents (CGA parameters, time signed, DNS update) of the signature and also the signature itself and then verfies this signature using the RSA algorithm. The result is a boolean value. Joshua >Would you actually be running these algorithms again just for the purpose of sending a DNS update or - No, just data cached in the server. The current SEND implementation would cache this data when the server or a client wants to generate a new IP address using SEND. CGA-TSIG is an application layer protocol. Joshua >would you be layering on top of the existing IP stack and using the existing CGA functionality? Yes Best, Hosnieh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
