Re: Re: your ECP-QKD draft

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


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


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


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

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


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.


Vernon Schryver    [email protected]

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