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

Do you have a text suggestion, or does what is proposed here work?

I'd also like to point out that it is strange to anticipate vendors
entirely ignoring normative text like "MUST". Spec violations should be
dealt with by robust error handling, and guidance from the market.

I consider it somewhat out of scope for the document to define, specify and
teach people what "visual spoofing attacks" are.

We'll remove the sentence about "confusion character", you are right that
it doesn't add much.

NEW

6.  Security Considerations

   This document uses UTF-8 encoding for the Shutdown Communication.
   There are a number of security issues with UNICODE.  Implementers and
   operator are advised to review UNICODE TR36 [UTR36] to learn about
   these issues.  UTF-8 "Shortest Form" encoding is REQUIRED to guard
   against the technical issues outlined in UTR36.  This
   specification minimizes the effects of visual syslog spoofing
attacks by limiting
   the length of the Shutdown Communication.

   Users of this mechanism should be aware that unless a transport that
   provides integrity is used for the BGP session in question, a
   Shutdown Communication message could be forged.  Unless a transport
   that provides confidentiality is used, a Shutdown Communication
   message could be snooped by an attacker.  These issues are common to
   any BGP message but may be of greater interest in the context of this
   proposal since the information carried in the message is generally
   expected to be used for human-to-human communication.  Refer to the
   related considerations in [RFC4271] and [RFC4272].

   Users of this mechanism should consider applying data minimization
   practises as outlined in Section 6.1 [RFC6973] as a received Shutdown
   Communication may be used at the receiver's discretion.

Kind regards,

Job

On Wed, 24 May 2017 at 19:53, Adam Roach <adam@nostrum.com> wrote:

> 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> 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
> 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/
>
>
>
> ----------------------------------------------------------------------
> 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
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>