Re: Re: your ECP-QKD draft

> From: Mohamed Ali SFAXI <[email protected]>


> Negotiating the key length is a feasible way to be independent from the=20
> encryption algorithm and to use the QKD for new algorithms and other=20
> encryption mechanisms like the one-time-pad function.

That not only does not address the point, it is wrong.

For example, to use a one-time pad, it would be necessary to specify
which pad, where you start using it, and how you use it.  Do you
use bit-wise XOR or something else such as byte-wise addition?
Is the idea is to XOR a stream of random bits carried on the quantum
channel with the bits on a conventional channel?  Perhaps you would
do that because the quantum channel is slow but runs continuously but
you'd run the conventional channel only there are PPP bits to carry.
But in that case, which bits on the conventional channel are encrypted?
link layer framing? LCP? I assume not ECP, but is that right?


In checking the draft to see if it says anything on that issue, I
noticed the T field which is defined as

     The T field specifies if the TTL field concerns the number of
     messages or the amount of time. If the value is 1, the TTL 
     field corresponds to the amount of time in second. If it is 0, 
     the TTL is the number of messages per key.
 
What is a "message"?  Is it a PPP packet for any NCP or something
else?  Are any PPP packets not counted, such as ECP packets carrying
TTL and T fields?  Or is a message a fixed block of bits or something 
else understood by the QKD modems and not known to PPP?

What, if any state change happens in the ECP state machine when the
TTL expires?


> >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.=20
> This field is not used now but could be used if required by users and we=20
> think that we may need a free field for the future use.

That does not answer the question of how to interoperability might
be achieved when there are unspecified additional parameters somewhere
on the fiber.

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

So that's why the diagram on page 4 just trails off.  I thought it was
a mere editoral problem.  It is instead intentional.  Implementors are
supposed to pick whatever length they like and need, and interoperability
be hanged.


Enough of this waste time of time.


Vernon Schryver    [email protected]

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