Hi Kyle - I read this while working on my Genart review. Some thoughts
inline.
On 2/7/22 4:26 PM, Kyle Rose via Datatracker wrote:
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.
If you didn't see the exchange between Carsten et.al. on this point, it
is compelling.
See https://mailarchive.ietf.org/arch/search/?q=draft-faltstrom-base45
* Why is
Space included as a character? This renders the encoding fragile in many string
handling contexts.
Well, it also requires encoding of buffers that contain nulls, so
fragility abounds.
* 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.
Show your math (or at least reading of the logic in the draft) a bit
more? It seems dead obvious to me from the draft that any base 45 [c d]
such that a = c + 45*d > 255 is an invalid encoding. In other words, the
draft requires the last option. What am I missing?
Grammar nit: "For example, it MUST the encoded data"
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
