bugtraq - Re: base64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m1A397M-000B1eC@proven.weird.com>
Date: Sat, 27 Sep 2003 03:03:48 -0400 (EDT)
From: "Greg A. Woods" <woods@...rd.com>
To: "Steven M. Christey" <coley@...re.org>
Cc: bugtraq@...urityFocus.com (BUGTRAQ: Full Disclosure Security Mailing List)
Subject: Re: base64

[ On Friday, September 26, 2003 at 16:56:54 (-0400), Steven M. Christey wrote: ]
> Subject: Re: base64
>
> > "Be liberal in what you accept, and conservative in what you send."
> > -- jon
> > RFC-1122 (originates in RFC760)
> 
> Funny you bring up that quote, as I've been thinking about it for a
> while now too.
> 
> I think that's wisdom for a different time, at least security-wise.

I don't think the so-called "Robustness Principle" was ever intended to
trump anything to do with security.

A I understand it the Robustness Principle is meant to guide the design
and implementation of communications protocols in an effort to promote
interoperability between otherwise correct and complete implementations,
and _nothing_ more.

The principle was most certainly not intended to guide the policies
which sites using any given protocol implementation might impose on top
of it.

The Robustness Principle was certainly not meant to allow for the kind
of "speling correction" mechanisms which are causing problems with MIME,
HTML, and similar.  Many people have made this mistake over the years,
and some seem to continue to make this mistake, but it is none the less
a mistake to interpret the Robustness Principle in such a way,
especially when the result may create new risks.

One must still be very careful to never trust unvalidated and
un-authenticated data received from any public network connection.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@...ohack.ca>
Planix, Inc. <woods@...nix.com>          Secrets of the Weird <woods@...rd.com>