Subject: RE: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 18 Sep 2006 19:12:18 -0700

> From: Brian E Carpenter [mailto:[email-masked]] 
 
> Phill,
> 
> > As a result the IETF is a standards body with 2000 active 
> participants 
> > that produces on average less than 3 standards a year and 
> typically takes ten years to produce even a specification.
> 
> It is well understood that the Internet mainly runs on 
> Proposed Standards, so the appropriate metric is how many 
> Proposed Standards the IETF produces a year. I think you will 
> find that is more than three.

The IETF calls itself a standards body, not a proposed standards body. 

The written process is very clearly not being followed but attempts to change it fall victim to inertia because nobody has a mandate to make changes.

> We are certainly slower than we should be, but I think you 
> will find that the typical time from a 00 draft to a Proposed 
> Standard is significantly less than ten years.
> 
> Let's see - HTTP/1.1 was published as Proposed Standard in 
> January 1997, and draft-ietf-http-v11-spec-00.txt was posted 
> in November 1995.

The first drafts of the spec were submitted in 1992/93 as you know. 

It still isn't recognized as an IETF standard.

We could argue this interminably or you could simply grasp the nettle and align theory with reality. For example declare that henceforth all draft standards will become full standards six months after becoming RFCs.

How the reconcilliation takes place really does not matter. We have a two stage process but for some reason we won't admit it. 

We could do another round of newtrack but that will take another three years and there is no reason to think it won't end up the same way.

Campaigns can be a pain, but they do have positive attributes. People who have to campaign for a position are forced to think about the contribution they intend to make, they have to set out a program of action, they have to communicate it to the electorate.  

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: grenville armitage <[email-masked]>
Date: Tue, 19 Sep 2006 12:40:12 +1000

Hallam-Baker, Phillip wrote:
	[..]
> Campaigns can be a pain, but they do have positive attributes. People
> who have to campaign for a position are forced to think about the
> contribution they intend to make, they have to set out a program of
> action, they have to communicate it to the electorate.

Alternatively, we could come up with a scheme where a randomly selected (and
nominally representative) group evaluates the demonstrated track record of
individuals up for consideration. This would focus attention on 'doers' rather
than 'intenders'. It seems strangely familiar, but I can't quite put my finger
on what such a process would be called....

cheers,
gja

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 19 Sep 2006 00:42:47 -0400

> It still isn't recognized as an IETF standard.

Thankfully, the complete failure known as HTTP 1.1 would never make it
to Proposed Standard under the unwritten process we have now. For
example, it doesn't contain a mandatory, universally interoperable
authentication feature.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Russ Allbery <[email-masked]>
Date: Mon, 18 Sep 2006 22:43:57 -0700

> example, it doesn't contain a mandatory, universally interoperable

That's right, it doesn't, and the lack of that feature is a first-rate
pain in the ass.  To take another example, NNTP is widely deployed and
lacks an interoperable authentication capability, and as a result the
authentication situation for NNTP is horrible.

The IETF requires such things not to scuttle protocols that don't have
them but to get people to go back and add them early when it's still
possible.  The requirement doesn't mean that protocols can't succeed
without authentication; that's obviously wrong.  It's instead about making
the protocol *better* while we have an opportunity to do so.

Both HTTP 1.1 and NNTP are widely deployed and have serious flaws in the
area of authentication.  Both would be *better* protocols had
authentication been addressed up-front instead of patched on retroactively
like we're having to do now.

We've now gone back and done that work for NNTP, in the IETF context, and
the resulting protocol is a significant improvement over what we have now.
It's an open question whether we were too late, whether there is so large
of a deployed base at this point that not enough people will ever
implement a well-specified authentication mechanism.  That doesn't mean
the work doesn't solve a very real problem; it means that the problem was
solved too late and as a result NNTP has become increasingly marginalized.
That's one possible failure mode; another possible failure mode is the one
that HTTP has experienced, where everyone invents their own authentication
protocol on top of it, many of which are not actually secure and most of
which don't even make a passing attempt at being interoperable.  This is
exactly the sort of situation that the IETF rule attempts to head off.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 19 Sep 2006 02:23:33 -0400

On 9/19/06, Russ Allbery <[email-masked]> wrote:
> pain in the ass.

I don't disagree. The IETF might first try to design an authentication
feature worth requiring. None of the current options are at all
satisfactory.

> possible.

I'm sure the latter is the reason it's done, but the result can go either way.

-- 

Robert Sayre

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Sep 2006 09:15:14 +0200

> feature worth requiring. None of the current options are at all

In fact TLS + HTTP Basic Auth is pretty interoperable, secure against 
quite a few attacks, and widely deployed.

The requirements needed to be "satisfactory" depend very much on your 
viewpoint; last week I talked to the guy who implemented Freenigma (PGP 
for web mailers, http://www.freenigma.com), and he commented that "this 
will never get past the security gurus in the IETF because it's so 
simple, people might actually use it".

That says something frightening about the kind of impression we give to 
people who work on making usable security. "Usable" needs to be an 
important component of "satisfactory".

(He's quite aware of the obvious security defects of his scheme, btw. 
It's a tradeoff.)

                   Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Sep 2006 10:51:18 +0200

> We could argue this interminably or you could simply grasp the nettle and align theory with reality.

It was clear in Montreal that there is no community consensus to spend
effort on doing this, so we have closed down this avenue for now.

    Brian

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Sep 2006 10:52:45 +0100

On Tue, 19 Sep 2006, Harald Alvestrand wrote:
>
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure against quite a
> few attacks, and widely deployed.

But mostly ignored, because the user interface is dreadful. Practically
all websites use one of the ad-hoc mechanisms that Russ referred to.

> viewpoint; last week I talked to the guy who implemented Freenigma (PGP for
> web mailers, http://www.freenigma.com), and he commented that "this will never
> get past the security gurus in the IETF because it's so simple, people might
> actually use it".
>
> That says something frightening about the kind of impression we give to people
> who work on making usable security. "Usable" needs to be an important
> component of "satisfactory".
>
> (He's quite aware of the obvious security defects of his scheme, btw. It's a
> tradeoff.)

http://www.links.org/?p=130

Over the last year we've moved all our email users over to secure
authentication (with TLS and SASL, or the old passowrd authentication
alternatives) and the main usability problem is not the protocols as
specified. The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with terrible user
interfaces bristling with options.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Sep 2006 17:12:40 +0200

> effort on doing this, so we have closed down this avenue for now.

I'm sorry, Brian, but this answer is truly unacceptable.  Reality is
that our 3 step process is not functioning as documented.  We thought we
were fixing it in NEWTRK, but you shut down that group.  Please tell me
and the rest of the community what path you expect to correct the
error.  If you don't have a proposal I will have one of my own.

Eliot

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Sep 2006 11:26:42 -0400

I interpreted the microphone and hand-raising in Montreal that people 
were tired of interminable process discussions that consume lots of 
resources and in the end accomplish nothing.

One way to ensure that there are no such discussions is to make all such 
discussions fruitless and interminable.

Another approach is to try to find ways to make quick and decisive 
progress, so that people aren't exhausted and that participation by 
those whose primary interest is technical can be ensured.

For this particular case, I don't think there is a scientifically 
provable right answer, so a reasonable approach is to pick a number (1 
or 2 or 3 steps) that most active participants affected can live with, 
and then put processes in place that actually align reality with goals. 
For example, I'd be very interested in the aggregate opinions of WG 
chairs, since they have to do much of the grunt work to make Draft and 
Standard happen.

In cases of inherent uncertainty, the wisdom of the crowd is probably 
the best one can do. Thus, create a small number of self-consistent 
proposals, and determine a reasonable group of affected individuals, and 
then work through a process of elimination in that group, with a simple 
vote. I don't really care whether this group is a NONCOM-style selected 
random group, all NONCOM-eligible individuals, all ADs + WG chairs or 
all recent RFC authors. Currently, we're getting the opinion of those 
most inclined to come to a process plenary and to step up to the 
microphone, which is not necessarily representative of the affected 
community.

Henning

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Sep 2006 17:33:56 +0200

> error.  If you don't have a proposal I will have one of my own.

I'm not sure that I can say it more clearly than I did the first time.
I do not believe there is enough interest in this problem in the
community to invest effort in fixing it. That is quite distinct from
whether you, I or a number of other individuals believe it needs fixing.

I think you weren't in Montreal. You might want to check
the plenary minutes at http://www3.ietf.org/proceedings/06jul/plenaryw.html
or listen to the audio at
ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ietf66-ch5-wed-plenary.mp3

If you can build a strong constituency for a given proposal,
that might change things. But over the last few years, I haven't
seen more than a few people supporting any given proposal,
including ones that I've made, and that doesn't cut it for
something that affects every single WG.

     Brian

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 19 Sep 2006 13:50:41 -0400

> quite a few attacks, and widely deployed.

Ah, this is the "wink, wink" approach to mandatory authentication.
Specify something no one uses. Here is my bank's web site:
<http://www.chase.com/>. It looks like a phishing attack.

> (He's quite aware of the obvious security defects of his scheme, btw.

Fully agree. Many non-standard schemes are more secure and more usable
than the IETF options, though.

Tony Finch wrote:
> The implementations fail to use the negotiation features to

Negotiation features don't work very well in practice so client
vendors don't rely on them.

-- 

Robert Sayre

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Sep 2006 11:00:00 -0700

> resources and in the end accomplish nothing.

Henning and Brian,

I think you are confusing "accomplish nothing" with "produces a 
consensus result that then gets dismissed by IETF management."

The difference is fundamental.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 19 Sep 2006 14:52:05 -0400

> <http://www.chase.com/>. It looks like a phishing attack.

If you try https://www.chase.com it redirects you to
http://www.chase.com.  How lame.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 19 Sep 2006 20:09:24 +0100

> vendors don't rely on them.

They work just fine in email, which is where Tony is complaining 
about their lack of use.

It's entirely possible to discover TLS support and authentication 
methods, and automatically select the strongest combination, with 
minimal user interaction. I have yet to find any email server (IMAP, 
ESMTP, ACAP, etc) for which the negotiation in-built into the 
protocol fails to the extent that the negotiated features are not in 
fact supported.

Twice, I have seen the negotiated features fail, but only twice, both 
times asa result of bugs in the server, and nothing to do with the 
design of the protocols as such. Both cases are vanishingly rare, and 
one was in unreleased software, so I'm less than convinced that they 
represent an argument that this negotiation does not work very well 
in practise.

Unfortunately, this does not leave many possible explanations for why 
many client implementors make this much more complicated for the user 
than it needs to be.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Sep 2006 15:32:14 -0400

>>>>> "Henning" == Henning Schulzrinne <[email-masked]> writes:

    Henning> For this particular case, I don't think there is a
    Henning> scientifically provable right answer, so a reasonable
    Henning> approach is to pick a number (1 or 2 or 3 steps) that
    Henning> most active participants affected can live with, and then
    Henning> put processes in place that actually align reality with
    Henning> goals. For example, I'd be very interested in the
    Henning> aggregate opinions of WG chairs, since they have to do
    Henning> much of the grunt work to make Draft and Standard happen.

    Henning> In cases of inherent uncertainty, the wisdom of the crowd
    Henning> is probably the best one can do. Thus, create a small
    Henning> number of self-consistent proposals, and determine a
    Henning> reasonable group of affected individuals, and then work
    Henning> through a process of elimination in that group, with a
    Henning> simple vote. I don't really care whether this group is a
    Henning> NONCOM-style selected random group, all NONCOM-eligible
    Henning> individuals, all ADs + WG chairs or all recent RFC
    Henning> authors. Currently, we're getting the opinion of those
    Henning> most inclined to come to a process plenary and to step up
    Henning> to the microphone, which is not necessarily
    Henning> representative of the affected community.

This is one direction we could take.  Nowe all you need to do is build
a consensus that is the direction we wish to take.  Others may for
example believe that doing anything is more harmful than having a
solution that does not enjoy IETF-wide rough consensus.  That's a
valid opinion to have.

So if you cannot get consensus on the solution, it is reasonable to
get consensus on how to make a decision.

However, you must not presume that you will get consensus on how to
make a decision.

Absent consensus on how to make a decsion, perhaps you could try and
get consensus that a decision must be made.  If you have consensus
that decisions must be made and no consensus on how to do it,then well
it kind of sucks but at least you know you have a problem.

However absent even a consensus that a decision must be made you are
not done discussing.

One drawback of the consensus process is that it is not guaranteed to
terminate.  I considered that a feature when I started working in the
IETF.  I'm willing to bet the organization on the assumption that
there is never a case where a decision must be made and we cannot at
least get consensus that such a decision must be made.

--Sam