<div dir="ltr"><div>Hi Junxiao,</div><div><br></div><div>I am addressing your comments. I have some questions inline.</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: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>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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.</div><div> </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></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></blockquote><div><br></div><div>Sorry, could you elaborate on this? I think previously Ashlesh and Alex met a similar problem before.</div><div>Are you saying the ECDH key base64?</div><div>I checked the code at CA server. I didn't add or require any newlines when parsing base64. I used the base64 API from ndn-cxx:</div><div><br></div><div>```</div><div><div style="color:rgb(0,0,0);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;line-height:18px;white-space:pre"><div style="line-height:18px"><div><span style="color:rgb(0,0,255)">uint8_t</span>*</div><div>ECDHState::deriveSecret(<span style="color:rgb(0,0,255)">const</span> std::string& peerKeyStr)</div><div>{</div><div> <span style="color:rgb(0,0,255)">namespace</span> t = ndn::security::transform;</div><br><div> OBufferStream os;</div><div> t::bufferSource(peerKeyStr) >> t::base64Decode() >> t::streamSink(os);</div><div> <span style="color:rgb(0,0,255)">auto</span> result = os.buf();</div><br><div> <span style="color:rgb(0,0,255)">return</span> <span style="color:rgb(0,0,255)">this</span>->deriveSecret(result->data(), result->size());</div><div>}</div></div></div></div><div> ```</div><div><b>TODO: </b>solve the problem in a later commit.</div><div><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><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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.</div><div> </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><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></blockquote><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>"remaining-tries" and "remaining-time" fields have same problem.</div></div></blockquote><div> </div><div><div>Addressed in the latest protocol Wiki page.</div></div><div><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></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></blockquote><div><br></div><div>This is truly a problem.</div><div><b>TODO: </b>I will move ECDH state to each request state.</div><div> </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></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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.<br></div><div> </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></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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.</div><div> </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></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></blockquote><div><br></div><div><b>TODO: </b>I will solve the problem by correcting the comparison.<br></div><div> </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></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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.</div><div> </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><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></blockquote><div><br></div><div>Addressed in the latest protocol Wiki page.</div><div> </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></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></blockquote><div><br></div><div><b>TODO: </b>I will solve the problem by having a try block.<br></div><div> </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><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></blockquote><div><br></div><div><b>TODO: </b>I will solve the problem.</div><div> </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></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></blockquote><div><br></div><div>It's not needed in any commands.</div><div>The original purpose of certificate-id is to tell the client what's the expected certificate-id after the DOWNLOAD command.</div><div>After the client fetches the cert, it can check whether the last component of cert is equal to certificate-id, though this is not implemented and may not have real sense.</div><div>Yes, I think I could simply remove this.</div><div><br></div><div>This has already been removed in the lastest Wiki page.</div><div><b>TODO: </b>I will remove this in the implementation soon.<br></div><div><br></div><div>Best,</div><div>Zhiyi</div><div><br></div><div> </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></div><div><br></div><div>Yours, Junxiao<br></div><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>