Ballot for draft-nottingham-how-did-that-get-into-the-repo
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
Section 1. Typo. s/ike CSRF/like CSRF/ Section 4. Easy to find tokens will cut both ways. This URI scheme would make it trivial (with likely an acceptable false positive rate) for a CI system to trigger on the presence of a token in a repo. It would also be worth mentioning that adoption of this scheme would also further lower the bar for attackers when scanning for these tokens too – even less semantic parsing of source code would be required.
Section 4: "prevent accidental disclosure" seems a little strong. Perhaps "reduce the incidence of accidental disclosure" would be better.
Section 1 Per the comment in the shepherd writeup, RFC 6750 has a passable definition of "bearer token". Section 2 Perhaps an example Authorization header field (a la RFC 6750) would demonstrate the "required for later access" aspect? Section 4 The token ABNF rule allows tokens as small as one character. This is not recommended practice; applications should evaluate their requirements for entropy and issue tokens correspondingly. I feel like we have some more concrete guidelines regarding token entropy floating around. BCP 106 is the obvious candidate, though its emphasis is different than I would prefer. I guess Section 8 is tolerable. If it is difficult to correctly handle secret material, or unclear as to what the appropriate handling is, users might choose to obfuscate their secret tokens in order to evade detection (for example, removing the URI scheme for storage). Clear guidelines and helpful tools are good mitigations here. What would those "clear guidelines" be?
It's not clear to me whether or not this will truly help, but I don't see it causing any harm to the internet, and I think that it is good to try to mitigate against folk who either accidentally commit security tokens or deliberately commit them without any awareness of the consequences.