RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Timothe Litt]

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 binary
    data._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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/2ca5e070/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/2ca5e070/attachment.sig>