Not going to comment on the proposed protocol change itself yet, but this draft is missing something that I think is fundamentally gating to it moving forward –
To provide a support for multiple hash *algorithms, a method of reusing the security parameter bits in the address is *specified [RFC 4982] . This method can only support three hash algorithm at most, and at the same time limiting security parameter to a few values. Please explain why “only 3 hash algorithms at most” is unacceptable, please explain what you mean by “limiting security parameter to a few values” and why this is undesirable. In other words, what’s actually broken and why should we “fix” it using this proposal? This is claiming to make changes to CGAs in a way that does not downgrade the security level of CGAs. There is a burden of proof necessary to support that assertion which is also currently missing. There is also no discussion of whether there are any forward/backward compatibility issues between implementations that do or do not support this proposed change. The * above represents spelling nits that I corrected inline. Thanks, Wes George From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of zhou.suj...@zte.com.cn Sent: Sunday, March 04, 2012 8:43 PM To: ipv6@ietf.org Subject: Request for a time slot for "draft-zhou-6man-mhash-cga-00.txt" Hi, all I requested for a time slot (in pending status now ) for my newly submitted draft draft-zhou-6man-mhash-cga-00, in response to request of chairs, I give a short descriptioin here, any comments are welcome. the problems it solves: The draft provides a simple method of encoding multiple hash function types in a CGA address, it can be thought of as an improvement or an update to RFC4982. the motivation: RFC3972 defined CGA (cryptographically generated address) but only use one hash:SHA-1, it is hardcoded into CGA. RFC4982 proposed to define multiple hash functions in a CGA address, by reusing 3 bits Security parameter in a CGA, so presentation of sec and hash totally occupy 3 bits, and sec should be 0~7, even if we only use low value of sec :0,1,2, how much is left for hash function? 8/3 <3 so the motivation is trying to encode more hash function types in a CGA address while not degrading the security at the same time. May be it is more appropriate to submit to CSI WG, but I found no time slot for that WG. Are you interested in it? > > > Bob Hinden <bob.hin...@gmail.com> 写于 2012-03-01 23:42:43: > > > Thanks for the agenda request. It would be helpful if you would > > also announce it on the ipv6@ietf.org mailing list (explain the > > problems it solves, the motivation, etc.) and see what people think. > > > > Thanks, > > Bob > > > > On Mar 1, 2012, at 1:43 AM, zhou.suj...@zte.com.cn wrote: > > > > > > > > Dear Chairs, > > > > > > I'd like to request a time slot for my newly submitted draft > > draft-zhou-6man-mhash-cga-00, 5 minutes is enough, > > > Thank you! > > > Regards~~~ > > > > > > -Sujing Zhou > > > ----- 转发人 周苏静00132831/user/zte_ltd 时间 2012-03-01 17:41 ----- > > > > > > internet-dra...@ietf.org 写于 2012-03-01 15:58:34: > > > > > > > A new version of I-D, draft-zhou-6man-mhash-cga-00.txt has been > > > > successfully submitted by Sujing Zhou and posted to the IETF repository. > > > > > > > > Filename: draft-zhou-6man-mhash-cga > > > > Revision: 00 > > > > Title: Another Support for Multiple Hash Algorithms in > > > > Cryptographically Generated Addresses (CGAs) > > > > Creation date: 2012-03-01 > > > > WG ID: Individual Submission > > > > Number of pages: 8 > > > > > > > > Abstract: > > > > This document provides a support for multiple hash algorithms in > > > > Cryptographically Generated Addresses (CGAs) defined in RFC 3972. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
