Re: Re: your ECP-QKD draft

Mohamed Ali SFAXI writes:
> In order to have a valid key, we need some negotiation before. The 
> negotiation is done thanks to ECP. The two peers have to agree on the 
> key length,

The key length and how the key bits are manipulated is intimately tied
with the encryption algorithm chosen.  This is why I keep asking about
that problem.

For example, if you use 3DES (RFC 2420), you need three 56-bit
subkeys, each of which is normally stored in an 8-octet block, with
the 8 LSBs ignored (used as parity).  So, one plausible transform
would be to take exactly 24 octets from the quantum stream, and use
them directly as the three keys (k1, k2, and k3).  To do this, you
need to wipe out the LSBs (for use as parity) and reject any weak key
proposed by your peer.

But that's only *ONE* plausible transform among many, and it seems to
assume that the quantum stream itself is error-free.  If each
implementation chooses to do this a different way, you'll end up with
chaos.  It won't be interoperable.

Furthermore, once you've chosen the algorithm, at least in this case,
you no longer have the option of negotiating the key length.  The
algorithm dictates it.

In addition to that, the TTL appears to be unnecessary.  The simplest
way to deal with key expiry is to renegotiate ECP itself.  Why isn't
that the chosen method?

Or, if you can change the key on the fly without restarting ECP, then
why not just do it?  Why must the peers agree on this parameter at
all?

If it's a useful feature, wouldn't a key TTL be something that's
generally helpful for ECP, rather than a specific issue with quantum
key exchange?

> TTL and perhaps additional option not described in our draft.

Please explain the "additional option," or at least the intended
behavior.  How do we get interoperability if we have features that
aren't documented?

> when these parameters are fixed, a QKD starts. This is done out of the 
> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to 
> show that the network phase will start after the key is shared.
> after that, the key is delivered to the network phase to encrypt data

I don't see how this requires any special negotiation.

Obviously, you must have prior arrangement to use these "Q3P modems"
on the two consenting peers.  Why is that by itself not sufficient to
indicate that this new key source is desired?  Why must the peers also
negotiate something that they already know to be true?

> We didn't propose any encryption algorithm that could be used because 
> all the encryption algorithms that are already recognized by PPP could 
> be used. In fact, we have  introduced only a new way to obtain the 
> encryption key. I think that our draft do not harm the interoperability.

See above.  That choice is an interoperability problem.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext