Re: Re: your ECP-QKD draft

Dear All,

> James Carlson wrote:
>
>Bill Manning writes:
>  
>
>>a couple of things here:
>>
>>
>>the I-D is in the DB at
>>https://datatracker.ietf.org/public/idindex.cgi? 
>>command=view_related_docs&id=13770
>>  but clicking on the "view document" link gets nothing!
>>    
>>
>
>The only extant version of the document that I know of is the one that
>IANA forwarded to the pppext list.
>
>We asked specifically for a draft to review.  I don't know why the
>submitter wasn't told to go through the normal I-D submission process,
>but I'm guessing that either they didn't do it, or the publishing
>process somehow failed.
>
>In any event, we got the text we were asking about, so I'm less
>concerned about the publication process.  We can revisit that issue
>later _if_ anything substantive comes out of the discussion.
>
>(Since I don't expect there to be any positive consensus on this
>document, I'm a bit reluctant to raise their expectations by telling
>the authors to jump through the I-D hoop first.  It's not as though
>I-D publication is 'trivial' anymore.  :-<)
>  
>

We asked the IANA for a new type number and the IANA told us to publish 
an I-D first. We have already submit our I-D according to the normal I-D 
submission process. I don't know why the web link doesn't work !!


>
> Bill Manning wrote: a couple of things here:
>
>
>
> the I-D is in the DB at
> https://datatracker.ietf.org/public/idindex.cgi?command=view_related_docs&id=13770 
>
> but clicking on the "view document" link gets nothing!
>
> and one of my quantum computing cohorts makes this comment:
>
> >Mr. Sfaxi either misunderstands or fails to explain one VERY important
> >point: QKD REQUIRES an authenticated classical channel to operate
> >securely. Such a channel involves either PKI or a pre-shared secret.
> >

It is possible to have only one channel for the quantum communication 
and for the classical communication. It is feasible (confirmed by 
IdQuantique). IdQuantique and MagiQ use separate modules for quantum 
communication and classical communication in their devices to improve 
the QKD performances and because easy to implement that's why they use 
two different channels (in my opinion).


> >See
> >http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-what-shor.html 
>
> >http://dabacon.org/pontiff/?p=1086
> >and especially
> >http://arxiv.org/abs/quant-ph/0406147
> >
> >As to id-quantique and MagiQ Technologies, they have been around for a
> >couple of years. I don't know anyone who has actually purchased and
> >used their equipment. If you know anyone who has, please ask them to
> >contact me; I would love to find out about their experiences!
> >
> >Feel free to forward this to the reflector, and include me on any
> >replies or further conversations, but I don't read pppext.
> >
> > --Rod
>



>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.
>  
>
Negotiating the key length is a feasible way to be independent from the 
encryption algorithm and to use the QKD for new algorithms and other 
encryption mechanisms like the one-time-pad function.



>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?
>  
>
We have to use TTL for two reasons :

- security purpose (to have the possibility to refresh encryption key often)

- as we use the link as the quantum channel and the classical channel 
the classical communication must stop (when the TTL expires) and the 
quantum communication starts.

>  
>
>>> 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?
>  
>
"additional option" for us is a way to negotiate new QKD parameters. 
This field is not used now but could be used if required by users and we 
think that we may need a free field for the future use.



>>> 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
>


>
>
> Vernon Schryver wrote:
>
>>From: Mohamed Ali SFAXI <[email protected]>
>>    
>>
>
>
>  
>
>>In order to have a valid key, we need some negotiation before. The=20
>>negotiation is done thanks to ECP. The two peers have to agree on the=20
>>key length, TTL and perhaps additional option not described in our draft.
>>    
>>
>
>Your words "perhaps additional option not described in our draft" would
>demand that your draft be rejected by the IESG until it is complete.
>
>Have you read the RFCs on how to publish an I-D?
>  
>

As we said above : "

"additional option" for us is a way to negotiate new QKD parameters. 
This field is not used now but could be used if required by users and we 
think that we may need a free field for the future use.

"

>
>  
>
>>when these parameters are fixed, a QKD starts. This is done out of the=20
>>PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=20
>>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
>>    
>>
>
>Again, that seems to have nothing to do with QKD in particular.
>
>
>  
>
>>>Moreover, the draft does not explain how the key to be used with the
>>>chosen algorithm is actually derived, nor what algorithms are
>>>possible, so there's essentially no hope of interoperability.  As IETF
>>>documents have the explicit goal of producing interoperable
>>>implementations, this draft falls short of what's needed.
>>>
>>>      
>>>
>>We didn't propose any encryption algorithm that could be used because=20
>>all the encryption algorithms that are already recognized by PPP could=20
>>be used. In fact, we have  introduced only a new way to obtain the=20
>>encryption key. I think that our draft do not harm the interoperability.
>>    
>>
>
>Until and unless your draft does something to help interoperability,
>the IESG should to reject it.  Guessing that some as yet unknown ECP
>negotiations might be needed for QKP does not justify an RFC or
>an IANA type assignment.
>
>
>
>] From: Mohamed Ali SFAXI <[email protected]>
>
>
>] We are already in contact with Idquantique and maybe we will propose 
>] something togother.
>
>It would be wise to withdraw now and return later when you have something
>of substance to propose.
>
>
>]>>Here are some requirements to perform a quantum key distribution:
>
>] >As far as PPP is concerned, exactly the same is true of any use of=20
>] >PPP encryption.  In general one does not change PPP when one uses
>] >new kinds of modems.
>]
>] You are right. However, the question was how to exchange the key so I=20
>] answered to that question.
>
>I do not recall that anyone asked how quantum cryptography works
>or how it might be used in a vague, hand waving theory to exchange
>keys.  Perhaps you did not realize that people interested in moving
>encrypted or otherwise secure data over long distances might already
>be as aware of QKD as you seem to be.
>
>More important, your document fails to specify how to exchange keys
>using quantum crypography.  I suspect that there is more than one way,
>and that some sort of negotiating might be useful.  That negotiating,
>if needed, sounds like an appropriate subject of an RFC.  However,
>your draft of an I-D does not in any way address such issues.
>  
>
The QKD negotiation depends mainly on the QKD protocols. We assume that 
the modems and the software in these modems are the only concerned by 
the negotiation. I completely agree with you to have a common 
negotiation way in QKD.

>
>] >>Here are some requirements to perform a quantum key distribution:
>
>] >That fact does not affect PPP, and does not answer the questions
>] >that have been raised about your I-D.
>]
>] Same thing
>
>Telling us things we already know about QKD does not answer questions
>about you draft of an I-D.
>
>
>] >>b- A Q3P modem: this modem has to polarize, send and detect photons; it=
>
>] >That also does not affect PPP, and does not answer the questions raised
>] >about your I-D.
>
>] Same thing
>
>Why do you assume we know nothing of quantum cryptography?
>  
>
I don't assume that but I presented what we need to use quantum 
cryptography.

>
>] >PPP often does not change to use new kinds of conventional modems.
>
>] Our idea was to create some kind of ECP negotiation to fix the key=20
>] exchange parameters 
>
>According to your own words about possible additional options, your
>draft of an I-D fails to do that.
>  
>
please see above

>]                                                                 So it=20
>] is normal that the existing PPP implementations fits well. The only=20
>] difference is that to start the network phase using an encryption=20
>] algorithm we can choose to use the QKD to share a secret key or to=20
>] assume that the key is already shared (i..e what is done now in PPP).
>
>You do not need a special negotiation for QKD PPP to do that.  When
>you install the quantum cryptography modems, you must configure them
>and rest of your PPP machinery to use them.  Part of that installation
>procedure can involve setting the parameters that are pecular to QKD.
>Parameters that are common to other ECP schemes do not need a QKD RFC.
>It might be that QKD will need some PPP negotiations, but they cannot
>be standardized before they are specified.
>
>You persist in not answering the question of how QKD differs from
>plain old telephones for key distribution as far as PPP and ECP are
>concerned.
>  
>
The QKD is a solution to distribute keys.  We try to have an automatic  
"on-line" way to share the secret key. We choose the QKD as it is an 
unconditional secure mechanism to distribute secret. We need the ECP to 
configure this exchange (not physical configuration but logical 
configuration).

>
>This is all supposed to be about assigning an ECP type number to BB84.
>I've been told by people actually working on quantum cryptography and
>quantum computing that BB84 is an extremely unlikely choice.  Actually,
>the words they used about this whole proposal were a lot stronger.
>
>This should be rejected until something is actually proposed (i.e.
>without any TBD holes for possible additional parameters) and with
>support from people actually working with QKD.  It would be wrong to
>tie the hands of people working on QKD by advancing something that is
>only a place keeper.
>
>  
>

We propose the BB84 as it is the initial QKD protocol and the most 
famous. In addition, BB84 is still used by MagiQ and IdQuantique.

>Vernon Schryver    [email protected]
>
>  
>


*Mohamed Ali SFAXI*
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

 


>  
>

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