Subject: CGA issue #12: Upgrade path for crypto algorithms (related to issue #8)

From: "Tuomas Aura" <[email-masked]>
Date: Wed, 24 Mar 2004 04:03:09 -0800

The comment by Thomas Narten (issue #8) triggered me to 
think about another issue that has been ignored so far: 
upgrade path to another signature algorithm.  

My original idea was that the CGA Parameters (the input to 
Hash1) would be an opaque blob of bytes. The CGA verification
algorithm would parse the recognized fields (modifier, 
subnet prefix, collision count, public key) and return
the public key if the verification was successful.
The CGA verification algorithm would ignore any unrecognized
data at the and of the blob after the public key.
This would enable future versions of the specification to
add new fields to the end of the CGA Parameters. 

In particular, the CGA Parameters could include a second 
public key during transition to a more secure signature 
algorithm. Implementations that do not understand the 
second algorithm would include the unrecognized data (the 
second public key at the end of CGA Parameters) in the 
hash inputs but ignore it otherwise. Implementations that
support the second signature algorithm would use the
second public key.

Unfortunately, this idea of extendibility does not work 
with the current NDOPT draft. Instead of treating the CGA 
Parameters as an opaque block of bytes, as I hoped, the 
NDOPT draft divides the CGA Parameters into several different 
fields: Collision Cnt, Modifier and Key Information. 
The advantages of this are that the packet diagrams look
prettier, and that 7 bytes are saved because the subnet prefix
need not be repeated. The disadvantage is that it is not 
possible to pass unrecognized data, such as a second public 
key, at the end of the CGA Parameters. Thus, the NDOPT 
implementation is not upward compatible in the way I had
hoped.

I should have noticed this issue earlier. I ignored the
issue because we decided not to include any extensions (such
as a second signature algorithm) in the current specs. 

The options are:

(1) Forget about this. Live with the fact that it will be 
impossible to extend the CGA Parameters data structure 
without breaking compatibility with the first-generation 
SEND implementations. (This is the easiest option but
we might regret it later if RSA or SHA needs replacing.)

(2) Change the CGA draft so that it explicitly allows
multiple concatenated public keys in CGA Parameters. 
Change the NDOPT draft accordingly. (I strongly dislike
this option because everyone will want to have their favorite 
algorithms standardized, implementations will bloat, and
interoperability will break.)

(3) Change the CGA draft so that it allows unrecognized
data at the end of the CGA Parameters, after the public key.
The unrecognized fields will be input to Hash1 and Hash2 but
will be ignored otherwise. Change the NDOPT draft by replacing
the Collision Cnt, Modifier and Key Information fields in the 
CGA option with a single block of data that has the same format 
as CGA Parameters in the CGA draft and that can have 
unrecognized data after the public key. 

I propose using the third option because it does not over-specify 
things. If we one day feel that RSA or SHA needs replacing, 
we can at that time specify an extension to the CGA Parameters
format to help the transition. Moreover, it enables other 
future extensions that we might not have thought about yet. 
On the other hand, it does not invite people to add their 
own crypto algorithms unnecessarily, which is bound to happen
if we have a well-defined process for adding them.

Opinions?

Tuomas

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Mar 2004 20:41:36 +0300

I think this issue is important.

I'd go for option #3. I'm working on what the implications
for the ndopts draft are due to this, and will get back to
you as soon as I have a text suggestion...

--Jari