Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 24 May 2017 17:53 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6AD1204DA; Wed, 24 May 2017 10:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTI5-HqcVC76; Wed, 24 May 2017 10:53:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA821200E5; Wed, 24 May 2017 10:53:43 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4OHre7I074905 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 May 2017 12:53:41 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Robert Raszuk <robert@raszuk.net>, Job Snijders <job@ntt.net>, The IESG <iesg@ietf.org>, idr@ietf.org, draft-ietf-idr-shutdown@ietf.org, idr-chairs@ietf.org, aretana@cisco.com, skh@ndzh.com
References: <149559358944.28506.18362121959782542849.idtracker@ietfa.amsl.com> <CA+b+ERmg33vdOywz=Krw_30vdwWpMYLS_EZRSE+bfrHcS12GUA@mail.gmail.com> <CA+b+ERmamUOaUjnNX2FM0Qh+S7Gz-7f7PVHXiVzczZg2rvMtwQ@mail.gmail.com> <CA+b+ERnyJAU4xe6EiwsER9gG3Np9L6F4aEQWt0ZT405mzYg5wg@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <53c58824-e5fa-88e1-b092-b2e285906514@nostrum.com>
Date: Wed, 24 May 2017 12:53:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERnyJAU4xe6EiwsER9gG3Np9L6F4aEQWt0ZT405mzYg5wg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------922CEE46F90A819CBB5AE461"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VjL5-2xu-nOTGm1bYJdIoouYBXk>
Subject: Re: [Idr] Adam Roach's No Objection on draft-ietf-idr-shutdown-08: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 17:53:46 -0000

I'm putting this back on the relevant lists, as I believe we need to 
have this conversation in the open.

The problem that this text is apparently referring to is preventing the 
spoofing of syslog messages or the output of other CLI tools (which I 
read as similar to the concern Warren raises).

If this is the attack the text in the security section is attempting to 
describe, I think it misses the mark: I can't get from the words there 
to the concept of spoofing syslog messages. This is exacerbated by the 
presence of the clause "due to character confusion" as part of the 
description, as this raises the specter of UTF-8 confusables, which 
doesn't seem to be the related to the concern here.

Concretely, what I'm asking: please be clear in the security section -- 
with an example, if necessary -- so that implementors understand what is 
being prevented. It's perfectly fine to say "don't send more than 128 
bytes," but if implementors don't understand *why*, then they'll do it 
anyway (cf. the prohibition on DNS names starting with numbers, or 
chaining CNAM records in DNS: both are -- or were at a time -- 
prohibited by spec, but widely implemented nonetheless, because the 
explanation about *why* not to do them was completely unclear).

/a

On 5/24/17 1:57 AM, Robert Raszuk wrote:
> Just FYI ...
>
> I raised the exact same point during WG review and we agreed with Job 
> that it is not about spoofing, but "visual attack". Other then limited 
> size of the msg no other means of mitigation are needed by developer.
>
> Cheers
> R.
>
> On May 24, 2017 04:39, "Adam Roach" <adam@nostrum.com 
> <mailto:adam@nostrum.com>> wrote:
>
>     Adam Roach has entered the following ballot position for
>     draft-ietf-idr-shutdown-08: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut
>     this
>     introductory paragraph, however.)
>
>
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     for more information about IESG DISCUSS and COMMENT positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/
>     <https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/>
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     The portion of Section 6 (Security Considerations) that discusses
>     confusable characters is describing a problem that isn't obvious
>     on first
>     reading. As these strings are human-produced and human-consumed,
>     it's not
>     clear what harm would arise through the use of spoofing. If there is a
>     real risk here that the authors are aware of, it should be
>     described in
>     more detail to allow implemetors to more adeptly steer around it.
>     If not,
>     the statement around spoofing should probably be removed so as to
>     avoid
>     implementors scratching their heads regarding what mitigating actions
>     they might take.
>
>
>     _______________________________________________
>     Idr mailing list
>     Idr@ietf.org <mailto:Idr@ietf.org>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>