Reviewer: Kyle Rose Review result: Has Issues 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 has one Issue. Technically, the described protocol is Ready primarily because it describes an existing encoding standardized in ISO/IEC 18004. That said, I can't really help but ask a few things about this encoding: * Why 45? (This is probably really a question for the people who designed QR codes.) 45^3 = 91125 >> 2^16, which means roughly 30% of strings with length divisible by 3 comprising base45 characters are invalid encodings. * Why is Space included as a character? This renders the encoding fragile in many string handling contexts. * Base64 requires padding only to comply with the spec as-written: a minor modification of the spec (let's call it base64') could lose the padding and still produce unambiguous encodings of both content and length: going from 64 to 45 doesn't have anything to do with remedying this. And, by contrast with base45, 64^4=256^3, which means all strings with length divisible by 4 comprising base64 characters would be valid base64' encodings. But the real issue I have with the document (and one that might be technically unavoidable, depending how ISO/IEC 18004 is worded) is that an actual covert channel isn't addressed at all: that of the remaining insignificant bits in encodings of odd-length strings (a problem that would similarly impact base64' from above for encodings of strings with length mod 3 !≅ 0). Taking the example from section 4.4, the final chunk ([33 0]) in the example comes from the 16-bit value 33 (= 33 + 0 * 45). But all that is needed is that 33 ≅ X mod 256 unless the decoder enforces that encodings of length not divisible by 3 have 16-bit values < 256. For example, QED8WEJ6 ultimately decodes to the string "ietf!", or to "ietf!1", or not at all, depending on the behavior of the decoder: ignore non-zero second octet in odd-length strings (quite likely), render it based on the available data (unlikely because, if not special-cased, would result in decoding "ietf!0" in the example from the document), or reject the encoding. The last option is the only valid thing to do from a security perspective. Grammar nit: "For example, it MUST the encoded data" -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
