Re: [precis] I-D Action: draft-ietf-precis-7564bis-09.txt

[Sam Whited <[e-mail]>]

On Mon, Sep 18, 2017, at 08:21, Peter Saint-Andre wrote:
> Until we can get to the bottom of this, I'm going to ask the RFC Editor
> to "pause the presses" for a few days. I'll try to find time later today
> to propose a sentence or two that we can add to the introduction or
> security considerations or both.

Thanks. Let me try again to clarify why the current state of the RFCs
makes me so nervous, and why I think the solution isn't as simple as
adding more copy:

We cannot address every security concern in every RFC. This brute force
method (adding a new paragraph to the security considerations section)
doesn't scale, and we'll never find all the specific issues. Instead, we
have to write standards in such a way that it actively difficult to make
a mistake that will lead to a security flaw (not that we shouldn't
document any potential gotchas that we can't get rid of, but we should
also make them hard to do in the first place). One way we do this is
with consistency. Right now, the nickname profile is the *only* profile
that is non-idempotent, this is inconsistent.

The reason this matters is that most developers won't read the RFC
carefully (or possibly, at all). There is nothing we can do about this,
and when developers don't read the RFC we should not blame them for the
flaws that result. Reading an RFC is a huge amount of work, so naturally
most people won't. Instead we need to write specs in such a way that
they won't break it if they just look at the examples, or just skim the
sections that sound like they're related to what the dev is trying to
do. 

When I implemented PRECIS I did read the core RFC, built tables, added
rules, built an API for composing those rules into profiles, and then
went to create the profiles. I did *not* read the profile RFCs (until
later when reviewing them for this process, but that's not something
most devs will do). Instead, I skipped down to the section that listed
the rules for enforcement, saw case mapping, width mapping, etc. and
threw those the existing transformers I'd written together in the order
specified and called it a day. If I had not been on this mailing list I
would never have known that the nickname profile was non-idempotent.
This is how most developers will probably do things. Adding more text to
address security concerns won't help, since they never saw what was
there already. If they didn't get the message from X pages of text,
they're even less likely to get it from X+n pages.

Even if I did notice that the nickname profile is non-idempotent, there
are pressures against a correct implementation: multiple passes over the
data makes an already expensive operation even more expensive (2–3 times
more in the naive case) and it's just more work to do the right thing
(whereas it's easy to pass that work onto the application developers
using your implementation and assume they'll take care of it and iterate
properly).

All this means that, by default, the RFCs make it easy to leave the
nickname profile non-idempotent (either by mistake, or intentionally due
to the pressures against fixing it). The question then becomes: "is that
a problem?" In the case of the non-idempotency of the nickname profile,
I think the answer is "yes".

For a somewhat concrete example, imagine a multi-user chat room. If a
user connects and sets their nickname, a single iteration of the
nickname profile is run on it, and it *should* match another user in the
room but doesn't because of this issue, that user can use the nickname
and is allowed into the room. This may be fine, we expect this to happen
anyways on occasion because we're using the freeform class. Now,
however, the user sends a query to the server that is handled by a third
party system; maybe it's a file upload that is delegated to another
server which stores the file at /files/<nickname>/myfile. This second
application applies the nickname profile again, however, this now makes
it identical to the original users nickname (because the fileserver got
a nickname that the chat server already enforced) and their files get
stored in the same place, meaning the new user whos nickname is slightly
different can overwrite the first users files and use that to send
malicious files to the original chat participants friends even though as
far as the chat system is concerned they are separate users. This is a
silly contrived example, and maybe the administrators shouldn't have
been using the nickname profile for their filenames in the first place
in this case, but any time there are two systems that might both enforce
the nickname profile you end up with a possible inconsistency like this,
and I'm sure there will be one where it feels perfectly reasonable to
use the nickname profile, but where the actual vulnerability comes from
the fact that you don't expect the nickname to end up being different
between the two systems. Note that in this example that it only matters
that the chat server used a broken implementation that did not iterate
multiple times, the file server could be using a perfectly correct
implementation and the issue would still exist.


—Sam