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

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 19:39:49 -0700

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.

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 12:53:40 -0500

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" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-idr-shutdown/>
>
>
>
>     _______________________________________________
>     Idr mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/idr
>     <https://www.ietf.org/mailman/listinfo/idr>
>
>

---

From: Job Snijders <[email-masked]>
Date: Wed, 24 May 2017 18:15:26 +0000

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 <[email-masked]> wrote:

> I'm putting this back on the relevant lists, as I believe we need to have
> this conversation in the open.
>
> spoofing of syslog messages or the output of other CLI tools (which I read
> as similar to the concern Warren raises).
>
> 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
> description, as this raises the specter of UTF-8 confusables, which doesn't
> seem to be the related to the concern here.
>
> 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
>
>
> 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" <[email-masked]> wrote:
>
> [email-masked]
> [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 13:44:12 -0500

On 5/24/17 1:15 PM, Job Snijders wrote:
>
> I consider it somewhat out of scope for the document to define, 
> specify and teach people what "visual spoofing attacks" are.
>

So, the problem here is that "visual spoofing attack" actually does have 
a meaning that some implementors are likely to be familiar with (see, 
e.g., google results for searching for that phrase: 
<https://www.google.com/search?q="visual+spoofing+attacks">), and -- as 
a term of art, at least -- it refers to homoglyphs and confusables. As I 
initially mentioned, the impact of homographs and confusables on 
human-to-human communication is not immediately obvious, and -- 
especially based on this...

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

...not what you actually mean. So if you're using the phrase "visual 
spoofing attacks" in a way that runs counter to the well-established 
meaning used by that phrase as a term of art, then I *do* think it is 
incumbent on you to clarify what you mean, since it is likely to diverge 
from what readers interpret those words to mean.

I understand your request for me to send text, but I'm still slightly 
perplexed about the exact issue you are trying to highlight, so I'll 
probably get it somewhat wrong. Here's an attempt:

1) Completely remove this text:

    However, the visual
    spoofing due to character confusion still persists.  This
    specification minimizes the effects of visual spoofing by limiting
    the length of the Shutdown Communication.

2) Between the first and second paragraph, add the following:

"As BGP Shutdown messages are likely to appear in syslog output, there 
is a risk that carefully formed Shutdown Communication fields might be 
formatted by receiving systems in a way to make them appear as 
additional syslog messages. To limit the ability to mount such an 
attack, the mechanism described in this document limits the length of 
BGP Shutdown Communication fields to 128 octets in length."

To be clear, I don't believe the mitigation proposed is a particularly 
good solution to the problem. I'm just proposing this text as my 
interpretation of what you seem to be claiming the existing text is 
supposed to say. If you can verify that the text I propose above is an 
accurate representation of the concern, then we can open a discussion 
around whether the mitigation is appropriate.

/a

---

From: Job Snijders <[email-masked]>
Date: Thu, 25 May 2017 11:08:20 +0200

Dear adam,

On Wed, May 24, 2017 at 01:44:12PM -0500, Adam Roach wrote:
>    However, the visual spoofing due to character confusion still
>    persists.  This specification minimizes the effects of visual
>    spoofing by limiting the length of the Shutdown Communication.
> 
> "As BGP Shutdown messages are likely to appear in syslog output, there is a
> risk that carefully formed Shutdown Communication fields might be formatted
> by receiving systems in a way to make them appear as additional syslog
> messages. To limit the ability to mount such an attack, the mechanism
> described in this document limits the length of BGP Shutdown Communication
> fields to 128 octets in length."
> 

I accepted your suggestion & slightly rewrote the sentences for
readability flow within the context of this document. Thanks!

As to your belief on whether the mitigation proposed helps, the shutdown
communication concept could've been defined in such a way to allow the
communication to fill up to the maximum BGP message size (4000 octets,
so with marker, type, etc a bgp shutdown communication perhaps could've
been ~ 3979 octets). I believe that putting a limit in is useful: with
3979 octets someone can fill up a terminal screen, with 128 you can't.
128 could've been 127, or 129 - it is an arbitrary small value.

The 128 number comes from earlier implementations where there was no
Length field, in later versions of the document on the length field was
added, but the effective shutdown communication message size was not
changed. To keep things byte-aligned a 8 bit length field was used.
"hysterical raisins" :)

BTW, if you want to open an discussion, I don't understand why you cast
your ballot as "no objection". And what outcome are you targetting? It
seems unlikely at this point for the on-the-wire format to change.

Attached is a rfcdiff HTML file to show the differences.

NEW:
--------

       against the technical issues outlined in UTR36.

       As BGP Shutdown Communications are likely to appear in syslog output,
       there is a risk that carefully constructed Shutdown Communication
       might be formatted by receiving systems in a way to make them appear
       as additional syslog messages.  To limit the ability to mount such an
       attack, the BGP Shutdown Communication is limited to 128 octets in
       length.

-------

Kind regards,

Job