Re: draft-yergeau-rfc2279bis-02.txt for STANDARD

["Steven M. Bellovin" <smb@research.att.com>]

In message <BF61D702-2482-11D7-8818-0003934B2128@cisco.com>, =?ISO-8859-1?Q?Pat
rik_F=E4ltstr=F6m?= writes:
>
>On fredag, jan 10, 2003, at 09:15 Europe/Stockholm, 
>ned.freed@mrochek.com wrote:
>
>>> > (c) Slip in a sentence somewhere (maybe as a security
>>> > consideration) indicating that > 4 bytes is possible in the future 
>>> and
>>> > that programs should not be designed on the assumption that they 
>>> will
>>> > never see more than four bytes.   I.e., interoperability testing at 
>>> <= 4
>>> > is fine, but I'd hate to set someone up for a buffer overflow 
>>> problem.
>>
>>> I think this is not likely to be needed; it should be OK to treat 5+ 
>>> byte
>>> encodings as a protocol error. But I could be wrong...
>>
>> Actually, I think it is preferable to treat them as protocol errors, 
>> due to
>> the need for UTF-16 compatibility.
>
>I still would like to have a wording about this in a security 
>considerations section so we minimize the risk for buffer overflow.
>

>From what others have said -- I know little of UTF -- the proper 
wording would be a warning that the encoding might specify longer 
sequences, even though they're not legal in our context; thus, 
applications should be aware of the possibility and handle it.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)