On 29-Dec-22 19:30, Mark Andrews wrote:
Valid base64 includes spaces and new lines. Poorly written record parsers reject valid records.-- Mark Andrews
True for DNS records; the RFC clearly states that whitespace is allowed in the presentation form's base64 fields of DNSSEC records. And as described, the AWS parser is "poorly written".
Not true in general. In fact, the base64 RFC states the opposite. Of course, confusion results. I often wonder why so much effort goes into writing RFCs when so many people don't read them carefully.
gnu base64 (the command) does what engineers do when there are multiple interpretations - provides an option. See man (1) base64's --ignore-garbage and remarks:
The data are encoded as described for the base64 alphabet in RFC
3548. Decoding require compliant input by
default, use --ignore-garbage to attempt to recover from
non-alphabet characters (such as newlines) in the
encoded stream.
Sigh.
https://datatracker.ietf.org/doc/html/rfc3548#page-3
2.3 <https://datatracker.ietf.org/doc/html/rfc3548#section-2.3>.
Interpretation of non-alphabet characters in encoded data
Base encodings use a specific, reduced, alphabet to encode binarydata._Non alphabet characters could exist within base encoded data, caused by data corruption or by design._ Non alphabet characters may
be exploited as a "covert channel", where non-protocol data can be sent for nefarious purposes. Non alphabet characters might also be sent in order to exploit implementation errors leading to, e.g., buffer overflow attacks._Implementations MUST reject the encoding if it contains characters outside the base alphabet when interpreting base encoded data, unless the specification referring to this document explicitly states otherwise_. Such specifications may, as MIME does, instead state that
characters outside the base encoding alphabet should simply be
ignored when interpreting data ("be liberal in what you accept").
Note that this means that any CRLF constitute "non alphabet
characters" and are ignored. Furthermore, such specifications may
consider the pad character, "=", as not part of the base alphabet
until the end of the string. If more than the allowed number of pad
characters are found at the end of the string, e.g., a base 64 string
terminated with "===", the excess pad characters could be ignored.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
