Hi Ketan, You asked "whether the responses and draft updates address [my] concerns”. I’d say that while I’m not completely happy about certain things (e.g., I remain unconvinced that the companion IDR doc shouldn’t be a normative reference) I don’t need to continue holding a DISCUSS on them: we’ve had a discussion, we don’t completely agree, these things happen. On point 4 however, I don’t think our discussion has concluded. At least, if you replied to this, I missed it:
> On Feb 16, 2022, at 2:42 PM, John Scudder <jgs=40juniper....@dmarc.ietf.org> > wrote: > >> 4. In §2.1 you talk about the signaling of symbolic names for candidate >> paths. >> Although you are careful to say that such symbolic names are only used for >> presentation purposes, it seems to me they still could be considered a new >> potential source of vulnerability, since a string that has no sanity-checking >> whatsoever applied by the protocol can display literally anything to an >> operator viewing it. Shouldn’t this be addressed in your Security >> Considerations? (For an example of a related Security Considerations, see RFC >> 9003. It’s probably not the best example, but it’s the one I had at my >> fingertips…) >> >> KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I >> am not aware of security issues around printable ASCII - please do point me >> to any references. > > You’re thinking too much like a protocol designer. The kind of concern I’m > thinking about has to do with using the string as a vector to put some words > in front of an operator, as part of a larger social engineering attempt. I > don’t have a detailed attack scenario to paint for you, but a quick sketch is > along the lines of > > - Attacker manages to inject a candidate path with the name > “Big_Bank_Low_Latency” > - ProTip: the candidate path does not actually terminate at Big_Bank > - Attacker then phones NOC, feigns urgency, asks NOC to redirect Big_Bank > traffic onto that path > > You get the idea, I hope. More snipped, but this is the meat of it. In case you haven’t looked at RFC 9003’s security section, here’s a snip from it: 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. (FWIW, I didn’t contribute that text.) Please don’t obsess about “syslog” in the example above, it’s not central to the point, just like UTF-8 vs ASCII isn’t central. The point, again, is that by introducing a way for an attacker to cause a target system to display arbitrary strings, it would seem reasonable to wonder if that creates an opportunity for mischief that doesn’t ordinarily exist in our protocols, involving misleading people looking at the displayed string in a user interface. There are various ways this concern could be mitigated (if we were to come to agreement that it’s even a concern). One would be to remove the “signal arbitrary strings” idea; this is clearly the solidest way to do it. Another would be to mandate (or strongly suggest) that symbolic names gleaned from something other than configuration be displayed in such a way as to make the operator aware of their status. At a minimum, one might add a paragraph or two identifying the concern. I’m sure there are other things that could be contemplated. Regards, —John _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
