Re: negotiation and consensus-finding styles

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Dec 16, 2015 at 1:22 AM, Phillip Hallam-Baker
<[e-mail]> wrote:
> On Mon, Dec 14, 2015 at 8:04 AM, Jari Arkko <[e-mail]> wrote:

> That is why consequences are important. A tenfold increase in
> data volume is a serious consequence and should be accepted as
> justification for a red line. The fact that the browser market is
> driven by competition to optimize page load latency gives
> rise to consequences.
>
> In general, a red line is not a personal constraint, it is an external one.

Another way to identify a genuine red line from a bluff is what
happens afterwards.

Right now we have a situation in which CABForum rules for managing the
WebPKI deliberately and intentionally violate a MUST in RFC 5280 Sec
4.2.1.10.

According to RFC 5280, a name constraint MUST be marked critical. The
industry explicitly rejected that approach and the CABForum has an
override that allows the CA to decide.

This is not an abstract dispute, conforming with RFC5280 causes a lot
of real world systems to break which is of course the sole point of
the critical flag. The only reason for marking an extension critical
is when the desired behavior is for relying parties that do not
understand the extension to reject the certificate.

The industry has decided that wherever possible, name constraints
should be used to limit the exposure of a CA or intermediate in the
case of breach or compromise. Marking the certificates critical would
have rendered them unacceptable.


There has been one positive outcome from the situation though. I did
use it in a private discussion with a former senior NSA employee as an
example of an instance where the disclosure of the NSA BULLRUN program
has materially damaged cyber security efforts. That person has
subsequently changed their position on crypto backdoors to oppose
them.

Even if it is the case that the opposition was not driven by a covert
NSA program, the suspicion that it might be is obviously damaging and
corrosive. My personal theory is that that particular set of slides
was actually written by a Major trying to make Colonel who was trying
to explain how his cyber-defense activities fit into a mandate for
cyber-attack.


I think that there is a need for some mechanism to correct the
situation in cases like these where a group in IETF came to a
particular decision and the actual users of the specification came to
a different decision and acted on it. No useful purpose is served by
insisting that the specification reflect a Working Group consensus
that has been rejected in the defacto Industry standard.

More generally, I see a rather important distinction between 'the
consensus is that we shall all do X' and 'the consensus is that you
must do X'. There is a particular style of 'consensus based' standards
making where a small group decide what they want to do and then use
some very sharp elbows to eliminate folk who might have a different
idea from the conversation. This is a particular problem with some of
the people who peddle consulting in 'IETF process' and whose metric
for success is speed to get their client's proposal published as an
RFC rather than establishing the industry support necessary to get the
proposal widely used.