On 5/16/20 11:59 PM, Benjamin Kaduk wrote:
I guess this begs the question why standards-track isn't appropriate? I
mean, lots of $MEGACORPS might just as well be different organizations
when it comes to interoperability issues. And they certainly have all of
the same problems of each group rolling their own (badly). And of course
standards mean that there's review, which is especially important with
security related stuff.
Standards-track is not out of the question, and could well be appropriate
in some casess. My parenthetical was just meant to provide my unscientific
estimate of what has been done in the past.
I wonder if security related protocols are really a special case. The
one truism is that if you don't get good external review for security
protocols, you will screw it up. Of course we don't want to make IETF a
job shop for everybody's favorite private security protocol to get the
Good IETF Security Keeping seal of approval. Yet there are classes of
problems that really transcend one-off kinds of problems that 1) nobody
wants to roll their own and 2) nobody should be rolling their own in any
case.
Another example along the lines of what i was thinking is, say, digest
authentication (rfc 7616). Nobody actually uses digest auth because the
browser UI is terrible (ditto Basic). There is no reason, however, that
you couldn't implement a client based digest auth with Webcrypto these
days which would allow you to make the UI as pretty as you like. But RFC
7616 is a protocol between server and User Agent (browser), not the
client code itself. Ought there be a standard if people want to move to
digest to reduce passwords transmission? If there were enough demand,
I'd think so -- companies rolling their own with bad transcriptions of
rfc7616 would be a mess. Is this an IETF thing though? That's kind of
what has me stumped.
Mike
