<div><div dir="auto">Hi Junxiao,</div></div><div dir="auto"><br></div><div dir="auto">I will create several redmine issues based on your report. Thank you so much for providing us with your first hand experience.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Zhiyi</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2019 at 7:05 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Zhiyi</div><div><br></div><div>I figured out what's wrong with the packet from Nov 05: the Interest I'm sending is missing a "CA" name component, so that nobody would answer. After fixing this error, the CA is responding.</div><div>Now I got the full cycle working in my program (packet trace attached). My experience is as follows.<br></div><div><br></div><div><font size="4">different assigned numbers</font></div><div>Some assigned numbers differ between protocol (left) and implementation (right).</div><div>NEW vs _NEW</div><div>CHALLENGE vs _CHALLENGE</div><div>DOWNLOAD vs _DOWNLOAD</div><div>EncryptedPayload: 602 vs 630</div><div>InitialVector: 605 vs 632<br></div><div><br></div><div><font size="4">nonstandard base64</font></div><div>The CA expects a nonstandard base64 encoding format: encoder must insert a newline after every 64 bytes.</div><div>Either the implementation should remove this requirement, or the protocol should specify this requirement.</div><div><br></div><div><font size="4">Signed Interest format mismatch<br></font></div><div>Protocol specifies Signed Interest format from NDN Packet Format v0.3.</div><div>The CA expects 2014 Signed Interest format.</div><div>Either one should change to match the other.</div><div><br></div><div><font size="4">NEW/CHALLENGE statue encoding<br></font></div><div>Protocol specifies "status" field of NEW response is encoded as a number.</div><div>CA implementation encodes it as a string.</div><div>"remaining-tries" and "remaining-time" fields have same problem.<br></div><div><br></div><div><font size="4">reuse ECDH key<br></font></div><div>CA is reusing the same ECDH key for all requests. It should generate a unique ECDH key for each request.<br></div><div><br></div><div><font size="4">ECDH salt encoding</font></div><div>Protocol does not specify how salt is encoded.</div><div>CA implementation generates 8 bytes of random value, interprets it as uint64, and prints in decimal string.</div><div>Protocol does not specify which endianness is used in this conversion.<br></div><div><br></div><div><font size="4">ECDH info</font></div><div>Protocol does not specify what is used as "info" in ECDH.</div><div>CA implementation assumes F0F1F2F3F4F5F6F7F8F9.<br></div><div><br></div><font size="4">hkdf crash</font><div></div><div><a href="https://github.com/named-data/ndncert/blob/aae119aeb9b5387f2fd8f80c56ee8cbfe8c15988/src/crypto-support/crypto-helper.cpp#L170" target="_blank">ECDHState::deriveSecret</a> assumes ECDH_compute_key to return 0 on error, but it actually returns -1.</div><div>Thus, when I provide incorrect ECDH public key, ECDHState::deriveSecret does not detect the error, but assigns -1 to the length field.<br></div><div>Consequently, CaModule::onNew passes secretLen=-1 to hkdf(), which then segfaults.<br></div><div><br></div><div><font size="4">AES 128 vs AES 256</font></div><div>Protocol specifies 128-bit AES, but CA expects 256-bit AES.</div><div><br></div><div><font size="4">AES mode</font></div><div>Protocol does not specify AES mode. It should say "AES-CBC".<br></div><div><br></div><div><font size="4">missing pin-code crash</font></div><div>After selecting "pin" challenge, the next CHALLENGE Interest payload should have "pin-code" key.</div><div>When I misspell it as "pin", the CA crashes because it cannot find "pin-code" key.</div><div><br></div><div><font size="4">negative remaining time</font></div><div>For some reason, CA gives me a negative remaining-time value after I enter a wrong code.</div><div>(these are not original JSON, but console.log output, but nothing is modified)<br></div><div><br></div><b>CHALLENGE request 0</b><br><div>{ 'selected-challenge': 'pin' }<br></div><div><b>CHALLENGE response 0</b><br></div><div>{<br> status: '1',<br> 'challenge-status': 'need-code',<br> 'remaining-tries': '3',<br> 'remaining-time': '3600'<br>}<br><b>CHALLENGE request 1, wrong code</b><br>{ 'selected-challenge': 'pin', 'pin-code': '855899' }<br></div><div><b>CHALLENGE response 1</b><br></div><div>{<br> status: '1',<br> 'challenge-status': 'wrong-code',<br> 'remaining-tries': '2',<br> 'remaining-time': '-2046070806'<br>}<br></div><div><b>CHALLENGE request 2</b><br></div><div>{ 'selected-challenge': 'pin', 'pin-code': '850899' }<br></div><div><b>CHALLENGE response 2</b><br></div><div>{<br> status: '3',<br> 'challenge-status': 'success',<br> 'remaining-tries': '0',<br> 'remaining-time': '0',<br> 'certificate-id': '8930813521911288448'<br>}<br></div><div><br></div><div><font size="4">Purpose of certificate-id<br></font></div><div>I wonder what's the purpose of "certificate-id" field? It's not needed in DOWNLOAD or any other command.<br></div><div><br></div><div>Yours, Junxiao<br></div></div><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2019 at 12:31 AM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Zhiyi</div><div><br></div><div>It seems that the current deployment is not handling ParametersSha256DigestComponent correctly.</div><div><br></div><div>In the attached packet sample, frame 1 is a PROBE Interest generated by ndncert-client from <a href="https://github.com/Zhiyi-Zhang/ndncert/tree/3b9a2501d60e90ec33845e021a500a9820bf9050" target="_blank">https://github.com/Zhiyi-Zhang/ndncert/tree/3b9a2501d60e90ec33845e021a500a9820bf9050</a> .</div><div>The Interest is invalid under Packet Format 0.3, as it contains ApplicationParameters element but lacks ParametersSha256DigestComponent in the name.</div><div>Nevertheless, the CA responded to this Interest in frame 2.</div><div><br></div><div>Frame 6 was generated by a different program. It carries the same JSON object, and have a
ParametersSha256DigestComponent appended to the name. However, the CA is not responding to it.</div><div>Did I generate the packet wrong, or is it a problem with the deployment?<br>
</div><div><br></div><div>Yours, Junxiao<br></div></div>
</blockquote></div></div>
</blockquote></div></div>