Subject: [Int-area] Fwd: I-D ACTION:draft-bagnulo-multiple-hash-cga-01.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Oct 2006 17:40:25 +0200

Hi,

we have submitted a new version of the draft including the comments  
discussed in this ml and the meeting.

further comments on the document are welcome

Thanks, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 9 de octubre de 2006 21:50:02 GMT+02:00
> Para: [email-masked]
> Cc: Asunto: I-D ACTION:draft-bagnulo-multiple-hash-cga-01.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Support for Multiple Hash Algorithms in Cryptographically  
> Generated Addresses (CGAs)
> 	Author(s)	: M. Bagnulo, J. Arkko
> 	Filename	: draft-bagnulo-multiple-hash-cga-01.txt
> 	Pages		: 9
> 	Date		: 2006-10-9
> 	
> This document analyzes the implications of recent attacks on commonly
>    used hash functions on Cryptographically Generated Addresses (CGAs)
>    and updates the CGA specification to support multiple hash
>    algorithms.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga 
> -01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-bagnulo-multiple-hash-cga-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-multiple-hash-cga-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Christian Vogt <[email-masked]>
Date: Tue, 10 Oct 2006 20:05:47 +0200

Hi Marcelo,

thanks for revising the document according to the earlier comments.
The new text is technically fine IMO, although I would add the following
three points regarding CGA Sec reuse to the last paragraph of section 3.1:

(1)  Erroneous use of an obsolete set of CGA parameters for a given SEC
value, both on the CGA owner's side and the CGA verifier's side, would
not be dramatic:  CGA verification would fail in the worst case and both
nodes would have to revert to unprotected IPv6 addresses.  This can
happen only with obsolete CGA parameter sets, which would be considered
insecure anyway.

(2)  CGA implementations must not accept two different meanings of the
same Sec value as this would introduce a possibility for downgrading
attacks.  Specifically, an attacker may be able to find a set of CGA
parameters that produces a victim's CGA with a cryptographically weak
algorithm, while the victim itself has previously generated the CGA with
a cryptographically stronger algorithm.

(3)  Optimally, new CGA implementations should include an interface via
which they can be updated to registry changes.  But since such changes
are expected to occur only at a very low frequency, it may just be
sufficient to pre-configure CGA implementations.

Feel free to copy and paste.

And some editorial suggestions...

> 4.  CGA generation procedure
> 
> CGAs MUST be generated according to the generation procedure defined 
> in the SEC registry defined in the IANA considerations section of 
> this document.

More precisely:  The corresponding Sec registry entry defines an RFC
which in turn defines the CGA generation/verification procedure.

> It should be noted that the CGA generation procedure may be changed 
> by the new procedure not only in terms of the hash fucntion used but 
> also in other aspects, e.g. longer Modifier values may be required if
>  the number of 0s required in Hash2 exceed the currently defined 
> bound of 112 bits.

You may want to add a sentence saying that the new procedure (which
potentially involves a longer Modifier value) would be described in the
RFC pointed to by the corresponding Sec registry entry.  The reader may
otherwise wonder where the procedure is actually defined.

In section 3.1, last paragraph:

> interoperate properly (i.e. if an old implementation receives a CGA 
> generated with the new meaning of the Sec value, it will fail and the
>  same for a new implementation receiving a CGA generated with the new
>  meaning of the Sec value).  In case the approach of reassigning a 
> Sec

"and the same for a new implementation receiving a CGA generated with
the s/new/old/ meaning of the Sec value"

Kind regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Oct 2006 17:49:54 +0200

Hi Christian,

thanks for your careful review, it is much appreciated

some comments below...

> happen only with obsolete CGA parameter sets, which would be considered

ok

> a cryptographically stronger algorithm.

fully agree with this, however, not sure if we should include this in 
the draft

i mean, we have discussed this point while writing this version of the 
draft and our conclusion was that an implementation that would do this 
would be really bogus so it was not worth mentioning it in the draft... 
i mean, i am not sure we need to describe how people should not shoot 
themselves in the foot in various ways...

> sufficient to pre-configure CGA implementations.

i am not sure i understand this... i mean reassigning the Sec value 
would result in a different implementation i.e. additional code for the 
new hash function and so on, so i guess that more that a change in the 
registry will be needed, but actual code is needed in the stack.Feel 
free to copy and paste.

> which in turn defines the CGA generation/verification procedure.

ok

> otherwise wonder where the procedure is actually defined.

ok

> the s/new/old/ meaning of the Sec value"

right

thanks again for your comments

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 12 Oct 2006 09:56:02 +0200

Hi Marcelo!

<snip>

>> (2)  CGA implementations must not accept two different meanings of
>> the same Sec value as this would introduce a possibility for
>> downgrading attacks.  Specifically, an attacker may be able to find
>> a set of CGA parameters that produces a victim's CGA with a
>> cryptographically weak algorithm, while the victim itself has
>> previously generated the CGA with a cryptographically stronger
>> algorithm.
> 
> i mean, we have discussed this point while writing this version of
> the draft and our conclusion was that an implementation that would do
> this would be really bogus so it was not worth mentioning it in the
> draft... i mean, i am not sure we need to describe how people should
> not shoot themselves in the foot in various ways...

Good point.  Maybe the security considerations is a better place to
discuss this.  The security considerations should in any case discuss
the issue of downbidding attacks IMO---basically saying that no
downbidding threat exists---, so it could be briefly mentioned there
that the inability to pursue a downbidding attack hinges on
implementations not accepting two different meanings of the same Sec value.

>> (3)  Optimally, new CGA implementations should include an interface
>> via which they can be updated to registry changes.  But since such
>> changes are expected to occur only at a very low frequency, it may
>> just be sufficient to pre-configure CGA implementations.
> 
> would result in a different implementation i.e. additional code for
> the new hash function and so on, so i guess that more that a change
> in the registry will be needed, but actual code is needed in the
> stack.

I see your point.  That's correct.

<snip>

Take care,
- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Oct 2006 12:26:41 +0200

Hi Christian,

El 12/10/2006, a las 9:56, Christian Vogt escribió:

> the issue of downbidding attacks IMO

but all the document discuss security issues, so we could say that all 
the document is security considerations (that is basically what it says 
in the security considerations section...)

I am not sure what is the usual approach for this type of documents 
where all the content is security related... do they usually contain a 
sort of summary in the security consideration section or do they just 
mention that all the document is about security and that's it?

i am ok with any of the approaches, just that this one was easier :-)

> ---basically saying that no

don't know... does anyone else has an opinion?

thanks, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 12 Oct 2006 12:41:34 +0200

Hi Marcelo -

>>> i mean, we have discussed this point while writing this version
>>> of the draft and our conclusion was that an implementation that
>>> would do this would be really bogus so it was not worth
>>> mentioning it in the draft... i mean, i am not sure we need to
>>> describe how people should not shoot themselves in the foot in
>>> various ways...
>>
>>  discuss this.  The security considerations should in any case
>> discuss the issue of downbidding attacks IMO
> 
> but all the document discuss security issues, so we could say that
> all the document is security considerations (that is basically what
> it says in the security considerations section...)
> 
> where all the content is security related... do they usually contain
> a sort of summary in the security consideration section or do they
> just mention that all the document is about security and that's it?
> 

Hmm, the document first describes the deficiencies of today's CGA and
then provides a solution.  The Security Considerations section typically
discusses any remaining security issues with the solution, or it
explains why a typical threat that people might be concerned about does
not apply.  Since downbidding is such a typical threat, I thought that
the Security Considerations should explain why the proposed solution is
not vulnerable to it.  But it's totally fine if you put the explanation
elsewhere if that works better with the current draft structure.

Best,
- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Oct 2006 12:50:14 +0200

> elsewhere if that works better with the current draft structure.

the second and the third paragraph in section 3.1. describes how a 
downgrading attack would work and the rest of the section presents 
different approachs that would not be vulnerable to those attacks and 
selects one among them. Do you think that more text is needed about 
downgrading attack?

  Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Fri, 13 Oct 2006 09:57:38 +0200

Hi Marcelo,

actually, I do, because the conclusion from the 2nd and 3rd paragraphs
in section 3.1 is that downgrading can be prevented by encoding the hash
function into the CGA (rather than specifying it as part of the CGA
parameters).  But this is true only under the assumption that no two
encodings can be valid at the same time.

You may say that this is a matter of course (which I actually do agree
with).  But it may not be so obvious for everyone who reads the document
or even writes the CGA software.  It's my personal feeling that the
document should explicitly mention that CGA implementations must always
be limited to a single meaning per Sec value.

Regards,
- Christian

marcelo bagnulo braun wrote:
>> Hmm, the document first describes the deficiencies of today's CGA 
>> and then provides a solution.  The Security Considerations section 
>> typically discusses any remaining security issues with the 
>> solution, or it explains why a typical threat that people might be 
>> concerned about does not apply.  Since downbidding is such a 
>> typical threat, I thought that the Security Considerations should 
>> explain why the proposed solution is not vulnerable to it.  But 
>> it's totally fine if you put the explanation elsewhere if that 
>> works better with the current draft structure.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Oct 2006 11:45:56 +0200

> be limited to a single meaning per Sec value.

ok i see your point and i don't have a strong preference w.r.t. 
including or not including a comment about this issue.

If anyone else has an opinion on this it would be nice to hear about it.

Regards, marcelo