<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 29-Dec-22 19:30, Mark Andrews wrote:<br>
</div>
<blockquote type="cite"
cite="mid:445C7BAA-7F66-4DAE-A6E1-5949471DB0D3@isc.org">Valid
base64 includes spaces and new lines. Poorly written record
parsers reject valid records. <br>
<br>
<div dir="ltr">--
<div>Mark Andrews</div>
</div>
<div dir="ltr"><br>
</div>
</blockquote>
<p><br>
</p>
<p>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".<br>
</p>
<p>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.</p>
<p>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:<br>
</p>
<blockquote>
<p>The data are encoded as described for the base64 alphabet
in RFC 3548. Decoding require compliant input by<br>
default, use --ignore-garbage to attempt to recover from
non-alphabet characters (such as newlines) in the<br>
encoded stream.<br>
</p>
</blockquote>
Sigh.
<p><br>
</p>
<p><a moz-do-not-send="true"
href="https://datatracker.ietf.org/doc/html/rfc3548#page-3"
class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/rfc3548#page-3</a></p>
<pre class="newpage" style="box-sizing: border-box; font-family: var(--bs-font-monospace); font-size: 16px; margin: -1.25em 0px 0px; display: block; overflow: auto; padding: 0px; color: rgb(33, 37, 41); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><span class="h3" id="autoid-5" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0.5rem; font-weight: 700; line-height: 1.2; font-size: 1em; white-space: pre; display: inline;"><a class="selflink" id="section-2.3" href="https://datatracker.ietf.org/doc/html/rfc3548#section-2.3" style="box-sizing: border-box; color: var(--bs-link-color); text-decoration: underline;">2.3</a>. Interpretation of non-alphabet characters in encoded data</span>
Base encodings use a specific, reduced, alphabet to encode binary
data. <u>Non alphabet characters could exist within base encoded data,
caused by data corruption or by design.</u> 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.
<u>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</u>. 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.
</pre>
<br class="Apple-interchange-newline">
<br>
<p></p>
<p><br>
</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<p></p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>