Last Call Review of draftietfsfcproofoftransit08
reviewietfsfcproofoftransit08secdirlchuitema2021091900
Request  Review of  draftietfsfcproofoftransit 

Requested revision  No specific revision (document currently at 08)  
Type  Last Call Review  
Team  Security Area Directorate (secdir)  
Deadline  20210928  
Requested  20210914  
Authors  Frank Brockners , Shwetha Bhandari , Tal Mizrahi , Sashank Dara , Stephen Youell  
ID last updated  20210919  
Completed reviews 
Yangdoctors Last Call review of 08
by Martin Björklund
Secdir Last Call review of 08 by Christian Huitema Genart Last Call review of 08 by Stewart Bryant Opsdir Last Call review of 08 by Ron Bonica 

Assignment  Reviewer  Christian Huitema 
State  Completed  
Request  Last Call review on draftietfsfcproofoftransit by Security Area Directorate Assigned  
Posted at  https://mailarchive.ietf.org/arch/msg/secdir/oatRrqmn1SSSqpwxBmTtu9DDYqc  
Reviewed revision  08  
Result  Serious issues  
Completed  20210919 
reviewietfsfcproofoftransit08secdirlchuitema2021091900
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document proposes a security mechanism to prove that traffic transited through all specified nodes in a path. The mechanism works by adding a short option to each packet for which transit shall be verified. The option consists of a random number set by the originator of the packet, and a sum field to which each transit node adds a value depending on public parameters, on the random number and on secrets held by the node. The destination has access to all the secrets held by the nodes on the path, and can verify whether or not the final sum corresponds to the sum of expected values. The proposed size of the random number and the sum field is 64 bits. In the paragraph above, I described the mechanism without mentioning the algorithm used to compute these 64 bit numbers. The 64 bit size is obviously a concern: for cryptographic applications, 64 bits is not a large number, and that might be a weakness whatever the proposed algorithm. The actual algorithm appears to be a bespoke derivation of Shamir's Secret Sharing algorithm (SSS). In other word, it is a case of "inventing your own crypto". SSS relies on the representation of polynomials as a sum of Lagrange Basis Polynomials. Each of the participating nodes holds a share of the secret represented by a point on the polynomial curve. A polynomial of degree K on the field of integers modulo a prime number N can only be revealed if at list K+1 participants reveal the value of their point. The safety of the algorithm relies on the size of the number N and on the fact that the secret shall be revealed only once. But the algorithm does not use SSS directly, so it deserves its own security analysis instead of relying simply on Shamir's work. The proposed algorithm uses two polynomials of degree K for a path containing K+1 nodes, on a field defined by a prime number N of 64 bits. One of the polynomial, POLY1, is secret, and only fully known by the verifying node. The other, POLY2 is public, with the constant coefficient set at a random value RND for each packet. For each packet, the goal is compute the value of POLY1 plus POLY2 at the point 0  that is, the constant coefficient of POLY3 = POLY1 + POLY2. Without going in too much details, one can observe that the constant coefficient of POLY3 is equal to the sum of the constant coefficients of POLY1 and POLY2, and that the constant coefficient of POLY2 is the value RND present in each packet. In the example given in section 3.3.2, the numbers are computed modulo 53, the constant coefficient of POLY1 is 10, and the value RND is 45. The final sum CML is indeed 10 + 45 = 2 mod 53. To me, this appears as a serious weakness in the algorithm. If an adversary can observe the value RND and CML for a first packet, it can retrieve the constant coefficient of POLY1, and thus can predict the value of CML for any other packet. That does not seem very secure. My recommendation would be to present the problem and ask the CFRG for algorithm recommendations.