Subject: Hum theatre

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Nov 2013 18:23:02 -0800

Folks,

An IETF hum is a method of surveying a group for its views. 
Unfortunately the hums that were taken at the end of this week's IAB 
plenary do not permit any meaningful interpretation.

Here's why...

Surveys are extremely sensitive to the phrasing of the questions, the 
phrasing and range of the response choices, the sequencing of the 
questions, and the context of the asking.  Get any of these wrong and 
you can get the wrong information, or even just the appearance of 
information -- that is, misunderstandings -- but nothing actually useful.

A common response to such a concern is "well, at least we'll get some 
answers", but that's like saying "well, at least we'll get some noise." 
  The fact that the noise is misunderstood to be signal does not 
actually make it signal.

The different phrasings of a question can produce very different 
understandings by responders.  The challenge is to formulate a question 
that is likely to be interpreted similarly amongst responders (and the 
person asking.)  It's also a challenge to ask a question that captures 
something that is actually meaningful (and was intended) rather than 
merely sounding good.

The offered response choices can bias the responses.  A set of choices 
like (Good, Excellent) obviously leaves out (Bad, Don't Care, Don't 
Know.)  Or they can have bias in their phrasing by making some choices 
more or less appealing (Could be better, Excellent), rather than 
equivalent vocabulary in tone (Bad, Good).  So it's a challenge to make 
sure that choices cover the proper range and with equanimity to the 
alternative choices.

A sequence of questions also needs to be carefully orchestrated.  For 
example today's questions took as a given that surveillance is an 
attack.  Due diligence might expect establishing that relationship 
explicitly.  And yes, it is possible that some IETF attendees do not see 
it as an attack.  Another example of sequencing is dealing with 
subtleties and complexities.  For example some anti-surveillance 
mechanisms are certain to defeat popular operational management 
mechanisms.  Do we care about the tradeoffs?

Lastly, environmental context can encourage or discourage candor. 
Examples include the genders of the asker and respondent, any 
relationship they might have, or the presence of others.  Would you 
really provide candid answers about possible problems with your sex life 
when being asked with your partner present?  Amongst a group of 
co-workers?  Your parents?

The hums asked at the plenary were problematic along each of these lines.

The first question was theatre, essentially making the context 
political.  By way of example, note the difference between what was asked:

      The IETF is willing to respond to the pervasive surveillance attack?

which has loaded language with 'pervasive' and 'attack', versus a more 
neutral and purely technical question meant to cover the same basic concern:

     The IETF is willing to improve its specifications to be more 
resistant to surveillance?

But this isn't exactly a balanced question either.  By that, I mean that 
the answer really is already known.  A good question is one that has a 
chance of getting some support for each choice.  So perhaps a better 
example would be:

      The IETF is willing to require adding resistance to surveillance 
to all of its protocols?

The questions typically also did not offer "don't know" or "don't care" 
choices.  Some folk probably knew that they don't know enough yet, 
limiting their ability to support the kinds of questions being asked.

The IETF's doing anything privacy-related that is useful is going to 
require considering tradeoffs and some of those tradeoffs might reduce 
the utility of a service. So the actual choices that will be made might 
turn out to be quite different from what was implied by the dominant 
answers to the plenary questions.

And lastly, consider carefully the context of the room and ask whether 
everyone actually felt completely free to give a "no" hum to the initial 
questions.  I suggest that the emotions of the room created a strong 
bias against no's.   Maybe not for you.  Maybe not for me.  But probably 
for many of the folk sitting near you.

We now find ourselves with a set of hums that appears to establish a 
direction but which can't survive even basic analysis, as the later 
postings on the ietf mailing list demonstrate.

Here's what I suggest:  A single, simple, conceptual question that 
supplies all of the 'guidance' we can legitimately offer, at this stage:

      The IETF needs to press for careful attention to privacy
      concerns in its work, including protection against surveillance.

           [ ]  No
           [ ]  Yes
           [ ]  Don't Yet Know
           [ ]  Don't Care

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 02:48:01 +0000

On Nov 6, 2013, at 6:23 PM, Dave Crocker <[email-masked]>
 wrote:

> 
> Here's what I suggest:  A single, simple, conceptual question that supplies all of the 'guidance' we can legitimately offer, at this stage:
> 

Worded like that?  I choose "Yes".

But this has a similar issue to the questions asked in the plenary. It's similar to the questions "do you want to eliminate crime?", "should your government have a balanced budget?", "are NATs bad?". Unless you're in the "get over it" camp on privacy, of course you're going to vote "Yes". 

When such attention comes to specific work items, we get tradeoffs against performance and against ease of deployment. Saying that HTTP/2 will only work with server authentication (as has been suggested) means that you won't be able to just turn on a switch and get the better page-load times of HTTP/2. You would need to get a certificate first, and if your site required a 3-server cluster, you would need to either add several more nodes to the cluster or buy an SSL accelerator box. That's the kind of of trade-off we have to think about when we advocate mandatory-to-use. 

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Nov 2013 18:50:27 -0800

I find hums totally bogus, I have no idea how loud the hum in the room is
when I am humming.

I was reading the BULLRUN documents and came across the description of
HONKER which was an iPhone/Android app with a backdoor that could be
activated and cause an MP3 to be played if the GPS said the phone was in a
particular location. I didn't immediately get the purpose of this scheme
until reading Dave's post. Then I woke up and I was in the admin plenary.

---

From: Tim Bray <[email-masked]>
Date: Wed, 6 Nov 2013 18:50:08 -0800

You’re entitled to your opinion, but I entirely disagree.  I thought each
of those made an important point and highlighted some areas where consensus
is broadly held.  I appreciated Russ’ composition of the issues and think
he deserves our thanks.

 -Tim

On Wed, Nov 6, 2013 at 6:23 PM, Dave Crocker <[email-masked]> wrote:

> Folks,
>
> An IETF hum is a method of surveying a group for its views. Unfortunately
> the hums that were taken at the end of this week's IAB plenary do not
> permit any meaningful interpretation.
>
>
> Here's why...
>
> questions, and the context of the asking.  Get any of these wrong and you
> can get the wrong information, or even just the appearance of information
> -- that is, misunderstandings -- but nothing actually useful.
>
>  The fact that the noise is misunderstood to be signal does not actually
> make it signal.
>
>
>
> something that is actually meaningful (and was intended) rather than merely
> sounding good.
>
> like (Good, Excellent) obviously leaves out (Bad, Don't Care, Don't Know.)
>  Or they can have bias in their phrasing by making some choices more or
> less appealing (Could be better, Excellent), rather than equivalent
> vocabulary in tone (Bad, Good).  So it's a challenge to make sure that
> choices cover the proper range and with equanimity to the alternative
> choices.
>
> example today's questions took as a given that surveillance is an attack.
>  Due diligence might expect establishing that relationship explicitly.  And
> yes, it is possible that some IETF attendees do not see it as an attack.
>  Another example of sequencing is dealing with subtleties and complexities.
>  For example some anti-surveillance mechanisms are certain to defeat
> popular operational management mechanisms.  Do we care about the tradeoffs?
>
> Lastly, environmental context can encourage or discourage candor. Examples
> include the genders of the asker and respondent, any relationship they
> might have, or the presence of others.  Would you really provide candid
> answers about possible problems with your sex life when being asked with
> your partner present?  Amongst a group of co-workers?  Your parents?
>
>
>
> The first question was theatre, essentially making the context political.
>  By way of example, note the difference between what was asked:
>
>     The IETF is willing to improve its specifications to be more resistant
> to surveillance?
>
>      The IETF is willing to require adding resistance to surveillance to
> all of its protocols?
>
> choices.  Some folk probably knew that they don't know enough yet, limiting
> their ability to support the kinds of questions being asked.
>
> require considering tradeoffs and some of those tradeoffs might reduce the
> utility of a service. So the actual choices that will be made might turn
> out to be quite different from what was implied by the dominant answers to
> the plenary questions.
>
> questions.  I suggest that the emotions of the room created a strong bias
> against no's.   Maybe not for you.  Maybe not for me.  But probably for
> many of the folk sitting near you.
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Nov 2013 18:58:43 -0800

> is broadly held.  I appreciated Russ’ composition of the issues and think

the feeling of those present was pretty clear.  i am sure folk with too
much free time on their hands will wrap themselves around process
epicycles 'til the cows come home.  there is a massive amount of work to
do.  let us focus on that.

randy

---

From: Jorge Amodio <[email-masked]>
Date: Wed, 6 Nov 2013 21:08:43 -0600

How many rolls of tinfoil were distributed during the meeting ?

-Jorge

---

From: Ralph Droms <[email-masked]>
Date: Wed, 6 Nov 2013 19:40:38 -0800

http://m.theatlantic.com/health/archive/2012/09/tin-foil-hats-actually-make-it-easier-for-the-government-to-track-your-thoughts/262998/

> On Nov 6, 2013, at 7:08 PM, Jorge Amodio <[email-masked]> wrote:
> 
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 03:43:39 +0000

>     concerns in its work, including protection against surveillance.

I guess that as a technologist I need a little more information.

First, as the questions were asked this morning and as you suggested they might have been reworded, the implication of a "yes" is that we will go back to each protocol we have deployed or in design and "do something" to make it more private, including protection against surveillance. I'm not sure we're likely to, for example, change RFC 791 to make it less available to surveillance, or for that matter RFC 2640. I'm not sure exactly how to change UDP, TCP, SCTP, and so on. Yes, there are some fields that could probably be encrypted, and doing so using IPsec ESP has some value in terms of integrity checking end to end. But I'm not sure that this would have an impact on privacy. ICMP? ARP? ND? OSPF? IS-IS?

So if the question is "all protocols", I'm not sure it is appropriate for all of our protocols to be changed, because I'm not sure that they face threats that we can effectively mitigate.

As we get further up-stack, the application of TLS or DTLS, and anything that would help with pervasive use of OpenPGP-or-whatever, would be a good thing. Where we have protocols that could usefully use TLS/DTLS and don't, we can address that, and I suspect it might be appropriate for the relevant working groups to amend their charters accordingly. In those cases, I would agree that the IETF SHOULD (not "needs to", this is a question of will and direction, not necessity) pay careful attention to privacy concerns in its work, including protection against surveillance.

After that, it's operational. If a site it deploying http and we might prefer it used https, running out and changing the protocol isn't going to fix anything. The operator of the site in question needs to change protocols to https - or something like that.

So, which protocols are under discussion, and what security/monitoring/privacy threats does each face? Where our protocols face legitimate threats, yes, we SHOULD address them. 

I'm not sure feel-good statements say much.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Nov 2013 18:46:54 +1300

> do.  let us focus on that.

Plus several.

Obviously the hums were not aimed at deciding any engineering questions
in need of great precision. They were aimed at getting a sense of the room
on some general principles. As with the two previous occasions I mentioned,
if we want to write them up, there needs to be a draft and a consensus-forming
process. That would be a fine background activity. Meanwhile, I hope progress
on doing the actual work continues in the foreground.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Nov 2013 05:52:45 +0000

On Nov 6, 2013, at 6:50 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Then I woke up and I was in the admin plenary.

How do you know that you were awake?

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 7 Nov 2013 06:00:36 +0000

On Thursday, November 7, 2013, Fred Baker (fred) wrote:

> First, as the questions were asked this morning and as you suggested they
> might have been reworded, the implication of a "yes" is that we will go
> back to each protocol we have deployed or in design and "do something" to
> make it more private, including protection against surveillance.

I think the implication is to be how we do things should change, designing
without considering security is wrong and we need more cross WGs to avoid
future problems, making design simple is ok to do parts but not  full
work/protocol. We need to UPDATE all protocols. The old designers should
admit that there are mistakes no ones perfect.

. I'm not sure we're likely to, for example, change RFC 791 to make it less
> available to surveillance, or for that matter RFC 2640.

May be more options of security techniques not only few security algorithms
which may affect other protocols.

> I'm not sure exactly how to change UDP, TCP, SCTP, and so on. Yes, there
> are some fields that could probably be encrypted, and doing so using IPsec
> ESP has some value in terms of integrity checking end to end. But I'm not
> sure that this would have an impact on privacy. ICMP? ARP? ND? OSPF? IS-IS?

We should be sure, and we should update protocols for the best services to
the world.

>
> So if the question is "all protocols", I'm not sure it is appropriate for
> all of our protocols to be changed, because I'm not sure that they face
> threats that we can effectively mitigate.

 IMHO, We need to update all the Internet transport and
application protocols for security focus.

> As we get further up-stack, the application of TLS or DTLS, and anything
> that would help with pervasive use of OpenPGP-or-whatever, would be a good
> thing. Where we have protocols that could usefully use TLS/DTLS and don't,
> we can address that, and I suspect it might be appropriate for the relevant
> working groups to amend their charters accordingly. In those cases, I would
> agree that the IETF SHOULD (not "needs to", this is a question of will and
> direction, not necessity) pay careful attention to privacy concerns in its
> work, including protection against surveillance.
>
> Agree

> After that, it's operational. If a site it deploying http and we might
> prefer it used https, running out and changing the protocol isn't going to
> fix anything. The operator of the site in question needs to change
> protocols to https - or something like that.

At least we report breaks and possible attacks, and do or best updates for
our users. If operators don't fix and update,we then blame them, the
community of users are very intelligent.

> So, which protocols are under discussion, and what
> security/monitoring/privacy threats does each face? Where our protocols
> face legitimate threats, yes, we SHOULD address them.

Why privacy threats were not addressed before users noticed the attacks and
that the designers failed? The IETF way of work and structure needs to
change, I already suggested it in past. Once an AD suggested more cross
area, but I think it is better to have cross WGs and changing structure of
IETF areas.

> I'm not sure feel-good statements say much.

Yes, It is easy to say or implement but what matters is what happens and
how we work to adapt and develop quicker than our attackers.

AB

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Nov 2013 07:09:21 +0100

In your previous mail you wrote:

>             [X]  Yes

[email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Wed, 6 Nov 2013 23:21:06 -0800

Some folks approached me after the plenary and asked me why I objected 
so loudly to these "taking of hums". Tim's response pretty well explains it:

On 11/6/13 6:58 PM, Randy Bush wrote:

> On 11/6/13 6:50 PM, Tim Bray wrote:
>> You’re entitled to your opinion, but I entirely disagree. I thought 
>> each of those made an important point and highlighted some areas 
>> where consensus is broadly held. I appreciated Russ’ composition of 
>> the issues and think he deserves our thanks. 
>
> the feeling of those present was pretty clear.
>    

Yes, the feeling of those present was pretty clear. And if Russ had only 
asked for the feeling of those present, I probably wouldn't have been 
torqued. I would have, like Dave described it, thought it a bit of 
political theater, but otherwise said "Whatever".

But Russ didn't ask for a "feeling". Russ said that he was asking about 
consensus, and Tim heard that the result of those hums *were* the IETF 
coming to consensus. And that's just bogus. There was no consensus, and 
some of this I think is really damaging to the IETF.

Look at a couple of these:

On 11/6/13 12:41 PM, Russ Housley wrote:
> 1.  The IETF is willing to respond to the pervasive surveillance attack?
>
>      Overwhelming YES.  Silence for NO.
>    

This was "The IETF wants to save the lives of bunnies." Press release 
nonsense. And surely so much mush as not to be consensus. Just let's 
everybody applaud. OK, who cares, but not useful.

> 3. The IETF should include encryption, even outside authentication, where practical.
>
>      Strong YES.  Silence for NO.
>    

So if you sat in perpass, you'll know that the result of this hum was 
rubbish. There were a bunch of people up at the mic in perpass who 
objected strenuously to this. There was no IETF consensus on this point. 
But if you took the result of the bogus hum as consensus, you'd sure 
think so. And that happened because Russ loaded the deck in the way he 
asked the question to make sure that nobody would hum against it. He 
asked it at the end when it was clear there would be no discussion of 
dissent, so that people who might have objected felt comfortable that at 
least they'd have a chance to explain themselves instead of looking like 
idiots humming against motherhood and apple pie. Pure nonsense.

This wasn't about getting consensus. This was about everybody feeling 
good about themselves and being able to applaud. And if anyone tries to 
enforce any of these things as consensus of the IETF (e.g., "Sorry; we 
had a hum and there was consensus that we're doing encryption without 
authentication whether you'd like to or not, so you're in the rough"), 
that should be appealed immediately.

This is vote stuffing in the extreme. It's ignoring (heck, it's actively 
suppressing) minority voices. It makes a joke of coming to consensus at all.

And all that said, since when does the IAB judge the consensus of the 
IETF? Not since 1992, as far as I remember.

I don't disagree with any of the statements per se. As Scott Brim 
pointed out, the statements were incredibly general and left all sorts 
of stuff undefined, so it's hard to know exactly what I'm signing up to 
by agreeing with them. But again, it's motherhood and apple pie for most 
of them. (The second might have been interesting if it weren't buried in 
the middle of the rest.) And it made for fine press. But IETF consensus? 
Bullpucky.

pr
-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Stefan Winter <[email-masked]>
Date: Thu, 07 Nov 2013 09:23:29 +0100

Hi,

>      concerns in its work, including protection against surveillance.

This is not a question.

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 07 Nov 2013 17:38:19 +0900

Hello Fred,

On 2013/11/07 12:43, Fred Baker (fred) wrote:

> First, as the questions were asked this morning and as you suggested they might have been reworded, the implication of a "yes" is that we will go back to each protocol we have deployed or in design and "do something" to make it more private, including protection against surveillance. I'm not sure we're likely to, for example, change RFC 791 to make it less available to surveillance, or for that matter RFC 2640.

I just looked up these two numbers. RFC 791 gives me IP, which makes 
sense. RFC 2640 (http://tools.ietf.org/html/rfc2640) gives me 
"Internationalization of the File Transfer Protocol", which doesn't make 
much sense to me. Are you saying that non-ASCII filenames need different 
protection from ASCII filenames?

Regards,   Martin.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:50:52 +0000

On Nov 6, 2013, at 10:00 PM, Abdussalam Baryun <[email-masked]>
 wrote:

> Why privacy threats were not addressed before users noticed the attacks and that the designers failed?

There are two fundamental reasons. One is that we didn't recognize the issues at the time. The other, in the words of an RFC author who looked me (as IETF Chair) in the eye while I was demanding a reasonable security considerations discussion in his draft, is "my customers will not pay for the extra enhancements and effort that go into a secure solution."

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:52:54 +0000

On Nov 7, 2013, at 12:38 AM, "Martin J. Dürst" <[email-masked]>
 wrote:

> I just looked up these two numbers. RFC 791 gives me IP, which makes sense. RFC 2640 (http://tools.ietf.org/html/rfc2640) gives me "Internationalization of the File Transfer Protocol", which doesn't make much sense to me. Are you saying that non-ASCII filenames need different protection from ASCII filenames?

Oops, sorry, 2460...

> Regards,   Martin.

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Stefan Winter <[email-masked]>
Date: Thu, 07 Nov 2013 10:27:14 +0100

Hi,

> There are two fundamental reasons. One is that we didn't recognize the
> issues at the time. The other, in the words of an RFC author who looked
> me (as IETF Chair) in the eye while I was demanding a reasonable
> security considerations discussion in his draft, is "my customers will
> not pay for the extra enhancements and effort that go into a secure
> solution."

And the reply was, of course, that he was forced to do it anyway before
publication could happen, because the IETF cares about the standards,
and not hypothesized customer complaints made up by an individual
participant. Right?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Nov 2013 01:36:04 -0800

Hey Pete,

Like Randy, I sense a fair degree of process omphaloskepsis here.

A wise person once told me that any consensus is judged at a point in space
and time, and this one sure was.   What you're saying is that it is
impossible for the consensus of the IETF to be estimated in plenary
session, and that it requires some specially anointed person (not of the
IAB) to judge that consensus.  Neither argument seems to me like it would
really sway the outcome of this decision -- I find it highly doubtful that
the outcome would have been different if some member of the IESG had asked
the same question.

These consensus calls seem to have captured the high-level consensus of the
IETF, as gathered in plenary at this meeting.  Yes, there was argument
about more specific details at the PERPASS meeting, but I don't think that
invalidates the more general agreement.

--Richard

On Wed, Nov 6, 2013 at 11:21 PM, Pete Resnick <[email-masked]>wrote:

> Some folks approached me after the plenary and asked me why I objected so
> loudly to these "taking of hums". Tim's response pretty well explains it:
>
>>> is broadly held. I appreciated Russ’ composition of the issues and think he
>>> deserves our thanks.
>>>
>>
> rubbish. There were a bunch of people up at the mic in perpass who objected
> strenuously to this. There was no IETF consensus on this point. But if you
> took the result of the bogus hum as consensus, you'd sure think so. And
> that happened because Russ loaded the deck in the way he asked the question
> to make sure that nobody would hum against it. He asked it at the end when
> it was clear there would be no discussion of dissent, so that people who
> might have objected felt comfortable that at least they'd have a chance to
> explain themselves instead of looking like idiots humming against
> motherhood and apple pie. Pure nonsense.
>
> This wasn't about getting consensus. This was about everybody feeling good
> about themselves and being able to applaud. And if anyone tries to enforce
> any of these things as consensus of the IETF (e.g., "Sorry; we had a hum
> and there was consensus that we're doing encryption without authentication
> whether you'd like to or not, so you're in the rough"), that should be
> appealed immediately.
>
> I don't disagree with any of the statements per se. As Scott Brim pointed
> out, the statements were incredibly general and left all sorts of stuff
> undefined, so it's hard to know exactly what I'm signing up to by agreeing
> with them. But again, it's motherhood and apple pie for most of them. (The
> second might have been interesting if it weren't buried in the middle of
> the rest.) And it made for fine press. But IETF consensus? Bullpucky.
>
> pr
> --

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 07 Nov 2013 11:53:44 +0000

I watched this in surveillance mode from UK. Sadly I found no humming
feature was available for lurkers! So you missed my rendition of "I
can't get no humin' action" The question session was particularly good
at unpicking some detail of what IETF should look at.

Isn't the most important issue around the end to end through middle
boxes path? Also doesn't this implicate PKI model? I was disappointed
that this hum was judged yes but mixed. (I didn't hear the counter hum
online).  Users should know if they are being proxied in networks and by
whom so they can exert responsibilities to secure their communications.
If the monitoring is legal such as part of compliance legislation then
users need to know if something is not being monitored as that normally
fails compliance requirements. It doesn't matter if that is on a LAN or
VPN or Internet.  So this cuts both ways. Users need some confidence in
what is going on between us.

Quantum cryptography might if I've understood the literature (which I am
far from sure I have) have a role in a new class of protocols that can
offer the opportunity for plug and secure services. The ability to know
if something has been interfered with would seem to have application. So
I was interested that no distinctions between different encryption
methodologies was mentioned as something needing to be explored. (There
was a very brief mention of elliptical curve threats but in a non
informative way).

Is that because this stuff is just really really hard to get one's head
around and so needs drafts to explain and buckets of iced water to keep
the towels wrapped around the head cool or that these developments are
not on the table for the work being considered?

It was I thought a great plenary.

Christian

> Randy Bush <mailto:[email-masked]>
> 7 November 2013 02:58
>
> Tim Bray <mailto:[email-masked]>
> 7 November 2013 02:50
> each of those made an important point and highlighted some areas where
> consensus is broadly held.  I appreciated Russ’ composition of the
> issues and think he deserves our thanks.
>
>  -Tim
>
>
>
> Dave Crocker <mailto:[email-masked]>
> 7 November 2013 02:23
> Folks,
>
> answers", but that's like saying "well, at least we'll get some
> noise."  The fact that the noise is misunderstood to be signal does
> not actually make it signal.
>
>
>
> understandings by responders.  The challenge is to formulate a
> question that is likely to be interpreted similarly amongst responders
> (and the person asking.)  It's also a challenge to ask a question that
> captures something that is actually meaningful (and was intended)
> rather than merely sounding good.
>
> equivalent vocabulary in tone (Bad, Good).  So it's a challenge to
> make sure that choices cover the proper range and with equanimity to
> the alternative choices.
>
> explicitly.  And yes, it is possible that some IETF attendees do not
> see it as an attack.  Another example of sequencing is dealing with
> really provide candid answers about possible problems with your sex
> life when being asked with your partner present?  Amongst a group of
> But this isn't exactly a balanced question either.  By that, I mean
> that the answer really is already known.  A good question is one that
> has a chance of getting some support for each choice.  So perhaps a
> better example would be:
>
> The questions typically also did not offer "don't know" or "don't
> care" choices.  Some folk probably knew that they don't know enough
> yet, limiting their ability to support the kinds of questions being
> asked.
>
> the utility of a service. So the actual choices that will be made
> might turn out to be quite different from what was implied by the
> dominant answers to the plenary questions.
>
> everyone actually felt completely free to give a "no" hum to the
> initial questions.  I suggest that the emotions of the room created a
> strong bias against no's.   Maybe not for you.  Maybe not for me.  But
> probably for many of the folk sitting near you.
>

---

From: Arturo Servin <[email-masked]>
Date: Thu, 7 Nov 2013 11:31:03 -0200

+1

Let's concentrate in improve the Internet and not if the hum.

/as

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Nov 2013 05:59:01 -0800

> You’re entitled to your opinion, but I entirely disagree.

I was not offering an opinion.

Survey methodology is an arcane and difficult technical specialty with a 
long, colorful and very problematic history.  Research on its challenges 
is extensive and consistent. By way of a brief example, here's something 
from the survey professionals at Pew:

http://www.people-press.org/methodology/questionnaire-design/question-wording/

 > I sense a fair degree of process omphaloskepsis here.

To the extent that it does not matter whether questions are asked 
ambiguously, responses are interpreted inconsistently and results used 
inappropriately, yes, I suppose these concerns represent idle reflection.

To the extent that we care whether the IETF really does provide an 
environment that supports careful, meaningful consideration of issues, 
encourages the inclusion of differing opinions, and is judicious in its 
interpretation of comments, it is quite basic to the nature of the IETF.

The point behind my including a single, alternative question at the end 
was to note that indulging in the exercise as theatre would have been 
fine if it hadn't purported to do more than that. From many of the 
comments that have been posted, it's quite clear that many folk think it 
was more than a closing bit of theatre.

d/

---

From: Scott Brim <[email-masked]>
Date: Thu, 7 Nov 2013 06:43:06 -0800

On Nov 7, 2013 6:00 AM, "Dave Crocker" <[email-masked]> wrote:
> By way of a brief example, here's something from the survey professionals
at Pew:

The flip side of this is the science of how to phrase questions in order to
subtly skew the outcome the way you want.

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Nov 2013 08:14:59 -0800

> coming to consensus.

i took it as the consensus of the *room*, and it would be taken to the
lists to be nibbled to death by ducks.

randy

---

From: Bob Hinden <[email-masked]>
Date: Thu, 7 Nov 2013 08:24:50 -0800

> do.  let us focus on that.

I agree.  The consensus in the room was very clear and was not at all ambiguous.

Bob

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Nov 2013 08:25:38 -0800

What I heard, to be clear, was primarily a call to action, of mostly
rhetorical (in the formal sense, look it up) effect.  There’s nothing
whatsoever wrong with that.  Few useful human actions are accomplished
without some rhetoric to get things moving.  That includes engineering
actions.

Also, a very useful expression of a sentiment that might be expressed as
“more encryption is good, let’s not let the perfect be the enemy of the
good”, and another that said “there’s going to be a lot of controversy
around end-to-end issues”.

I’m disappointed by this nitpicking over what I found a rather inspiring
moment.

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Nov 2013 08:42:43 -0800

> I’m disappointed by this nitpicking over what I found a rather inspiring

there's them what does the work and there's them what picks nits, has
constitutional crises, etc.  we are known for what we choose to do.

randy

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Nov 2013 08:45:13 -0800

On Nov 7, 2013, at 8:25 AM, Tim Bray <[email-masked]> wrote:

> I’m disappointed by this nitpicking over what I found a rather inspiring moment.

+1, but not surprised. The IETF, where no good deed goes unpunished.

--Paul Hoffman

---

From: Scott Brim <[email-masked]>
Date: Thu, 7 Nov 2013 08:59:39 -0800

> I agree.  The consensus in the room was very clear and was not at all
ambiguous.

I doubt very much that everyone had the same idea of what they were humming
about.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 7 Nov 2013 07:29:40 +0000

Sent from my iPad

> On 6 nov. 2013, at 21:48, "Brian E Carpenter" <[email-masked]> wrote:
> 

Hmm, I am with Dave here. Whereas I agree on the principles and was thus ready to hum along I had in fact a hard time humming on them because I kind of felt dragged into an applause machine, which provokes some automatic sense of rebellion in me. I think the topic at hand is too important to turn into a political correct propaganda machine, it is not fair to cast doubts about the way this was casted as 'process epicycles'.

Klaas

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 7 Nov 2013 17:16:16 +0000

Randy,

> constitutional crises, etc.  we are known for what we choose to do.

I'm sorry, but this is pure harassment of those that don't share your opinion of what happened. Can we disagree without calling into doubt the motives of those that don't agree with you?

One persons inspiring moment is another persons propaganda machine, I'm pretty sure we don't want a thought police in the IETF.

Klaas

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 7 Nov 2013 09:32:41 -0800

On 06 Nov 2013, at 23:29, Klaas Wierenga (kwiereng) <[email-masked]> wrote:

> automatic sense of rebellion

Ha, that is the best summary of the cognitive dissonance I’ve so far.

If the thing turns into a rally of the morally righteous, this will turn off the thinking individuals.

We need to keep the focus on the rational side, on the actual outcomes, economically, socially, technically.

I still think the plenary was a well-deserved celebration of our unanimity in the general direction that needs be taken.  As always, hard work follows, and the devil is in the details.  But that doesn’t take away from the unanimity.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Nov 2013 09:39:31 -0800

> lists to be nibbled to death by ducks.

That's nice.

Does recitation of your personal interpretation mean that it is 
irrelevant that others interpreted differently?   I've already heard one 
senior participant promise to use the results of the hum as leverage for 
working group activity.

Or do you mean that it is irrelevant that it was conducted in a manner 
that /guaranteed/ it would be interpreted differently?  That would imply 
that shared understanding of a strategic position for the IETF doesn't 
matter.

d/

---

From: Pete Resnick <[email-masked]>
Date: Thu, 7 Nov 2013 09:41:37 -0800

> Like Randy, I sense a fair degree of process omphaloskepsis here.

What process do you think is being over-contemplated here? The bit about 
the IAB judging consensus? Fine, ignore that bit. That's not the most 
important bit.

(Dismissing or belittling arguments by characterizing -- or caricaturing 
-- them, be it calling them "naive" or "overwrought" or 
"omphaloskepsis", is often effective, but inappropriate.)

> A wise person once told me that any consensus is judged at a point in 
> space and time, and this one sure was.

Consensus on *what* exactly in this case? Consensus that we should all 
be happy? Consensus that we should all have a pony?

It is true that consensus (rough or otherwise) is a state, and that 
state can always change. But consensus should be on a particular point 
and it must be relatively stable; it shouldn't be claimed on some broad 
platitude for which nobody knows the details, and it shouldn't change 
unless new information is brought into the mix.

> What you're saying is that it is impossible for the consensus of the 
> IETF to be estimated in plenary session and that it requires some 
> specially anointed person (not of the IAB) to judge that consensus.

No, I am absolutely not saying that. I disagree completely with all of 
the above statement.

After a discussion of issues, it is perfectly reasonable for someone 
(anyone) to *estimate* what the consensus of the IETF might be in 
plenary and state that. Sometimes that might even be a good thing.

A hum (or a show of hands, or an applause meter) can give you lots of 
information about the sentiment of the room and it might even give you 
an estimate of what the consensus of the room is. All fine.

But taking a hum, at the end, without discussion afterward, is not a 
reasonable way to *call* consensus. And that's exactly what some people 
heard was going on. And it's hard to interpret what Russ said otherwise.

(As for the "anointed" person: *Calling* consensus -- that is, making an 
IETF decision -- does take someone who the IETF has agreed is 
responsible to do that. Estimating consensus or guessing consensus or 
otherwise sticking one's finger into the wind and predicting consensus 
are all fine -- unless you're doing so to try to shove people into a 
particular position -- but making a final call *is* something that we 
leave for someone in particular. You'll not that when Ted asked for the 
hum, he asked Jari to do it. And again, none of this is the important 
point of my message.)

> Neither argument seems to me like it would really sway the outcome of 
> this decision...

Sorry: What decision exactly?

> These consensus calls seem to have captured the high-level consensus 
> of the IETF, as gathered in plenary at this meeting.  Yes, there was 
> argument about more specific details at the PERPASS meeting, but I 
> don't think that invalidates the more general agreement.

Don't get hung up on the details. This isn't about the details.

Have a hum and applause to make you feel good. Just don't  confuse 
people to think that it means the IETF has come to consensus.

Ask big fluffy political questions that state big fluffy political 
principles. Just don't  confuse people to think that it means the IETF 
has come to consensus.

I know people hate the idea that the IETF can't make grand political 
statements and that we're stuck doing technical work. Making grand 
political statements is fun and gets good press. Tough. Leave grand 
political statements to the IAB and ISOC. Let the IETF do its technical 
work and stop engaging in theatrics. Far less flashy, but significantly 
more useful.

pr

> On Wed, Nov 6, 2013 at 11:21 PM, Pete Resnick 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Some folks approached me after the plenary and asked me why I
>     objected so loudly to these "taking of hums". Tim's response
>     pretty well explains it:
>
>             You're entitled to your opinion, but I entirely disagree.
>             I thought each of those made an important point and
>             highlighted some areas where consensus is broadly held. I
>             appreciated Russ' composition of the issues and think he
>             deserves our thanks.
>
>
>     Yes, the feeling of those present was pretty clear. And if Russ
>     had only asked for the feeling of those present, I probably
>     wouldn't have been torqued. I would have, like Dave described it,
>     thought it a bit of political theater, but otherwise said "Whatever".
>
>     But Russ didn't ask for a "feeling". Russ said that he was asking
>     about consensus, and Tim heard that the result of those hums
>     *were* the IETF coming to consensus. And that's just bogus. There
>     was no consensus, and some of this I think is really damaging to
>     the IETF.
>
>     This was "The IETF wants to save the lives of bunnies." Press
>     release nonsense. And surely so much mush as not to be consensus.
>     Just let's everybody applaud. OK, who cares, but not useful.
>
>     So if you sat in perpass, you'll know that the result of this hum
>     was rubbish. There were a bunch of people up at the mic in perpass
>     who objected strenuously to this. There was no IETF consensus on
>     this point. But if you took the result of the bogus hum as
>     consensus, you'd sure think so. And that happened because Russ
>     loaded the deck in the way he asked the question to make sure that
>     nobody would hum against it. He asked it at the end when it was
>     clear there would be no discussion of dissent, so that people who
>     might have objected felt comfortable that at least they'd have a
>     chance to explain themselves instead of looking like idiots
>     humming against motherhood and apple pie. Pure nonsense.
>
>     This wasn't about getting consensus. This was about everybody
>     feeling good about themselves and being able to applaud. And if
>     anyone tries to enforce any of these things as consensus of the
>     IETF (e.g., "Sorry; we had a hum and there was consensus that
>     we're doing encryption without authentication whether you'd like
>     to or not, so you're in the rough"), that should be appealed
>     immediately.
>
>     This is vote stuffing in the extreme. It's ignoring (heck, it's
>     actively suppressing) minority voices. It makes a joke of coming
>     to consensus at all.
>
>     And all that said, since when does the IAB judge the consensus of
>     the IETF? Not since 1992, as far as I remember.
>
>     pointed out, the statements were incredibly general and left all
>     sorts of stuff undefined, so it's hard to know exactly what I'm
>     signing up to by agreeing with them. But again, it's motherhood
>     and apple pie for most of them. (The second might have been
>     interesting if it weren't buried in the middle of the rest.) And
>     it made for fine press. But IETF consensus? Bullpucky.
>
>     pr
>     -- 
>     Pete Resnick<http://www.qualcomm.com/~presnick/
>     <http://www.qualcomm.com/%7Epresnick/>>
>     <tel:%2B1%20%28858%29651-4478>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Nov 2013 12:48:33 -0500

The sentiment is unanimous

Opinion on how to act on that sentiment remains divided.

One of the reasons that opinion on how to act is divided is that the
discussion of TLS everywhere is focused on the value TLS is designed to
bring to secure Internet protocols rather than the total value proposition
of TLS which was always intended to be wider.

The point of VeriSign Class 3 and later Organization Validation criteria
and the Extended Validation criteria is to establish ACCOUNTABILITY. The
authentication is a means to that end and the encryption is a nice
byproduct.

People have been using TLS with no accountability but authentication. Which
was only bad because the browsers didn't differentiate between the two
until Extended Validation was deployed.

Using crypto is not a problem, telling people that they are safe when they
are not is the problem. At the moment the IETF does not use metrics to
determine how difficult it would be for an attacker to break a system. This
is my effort in the area:

http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

---

From: Jari Arkko <[email-masked]>
Date: Thu, 7 Nov 2013 09:50:58 -0800

All: can we keep the discussion on a neutral tone? There is no reason to add more emotional language to an already otherwise difficult topic. Thanks. -Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 7 Nov 2013 10:09:00 -0800

I wanted to provide my thoughts on this. 

First, in the interest of full disclosure, Russ and I conferred on stage about the questions, and he had my OK to go ahead. 

Now, of course the questions were at a high level, and with full hindsight they could have been more neutrally formulated. At the end of the day, they are what they are. And should be given the value they deserve.

I'd actually like to argue that the IETF position on this topic is something bigger, something where the plenary discussion and hums played a supporting role but they are not the sole determination. Here's my take-away from this week:

"The IETF considers pervasive-monitoring as a security issue and is willing to work to address it."

Nothing more, nothing less. Most working groups that I went to were addressing this topic in one way or the other, going through application by application, doing careful work to understand what options we have to improve security, and weighing the various trade-offs in different designs. The proof of the pudding is in the eating. "We need to address it" vs. "We are putting in the cycles to address it". When I look at the discussions throughout the week, it is very clear to me that we are putting in the cycles. 

As Carsten said:

> As always, hard work follows, and the devil is in the details.  But that doesn’t take away from the unanimity.

And indeed there are a lot of details and trade-offs to worry about. Opportunistic encryption, for instance, has been discussed at length this week and the variants and trade-offs are far from clear.

I think the next steps are what is important. And this is a long term effort. Here are some of the things we should be doing:

- work on the general guidance in this area ("consider it as an attack", "recommended ways to apply opportunistic encryption", "threat model changes", ...)

- work on the specific protocols and application areas (http, xmpp, etc)

Jari

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Nov 2013 10:28:44 -0800

Inline...

> the IAB judging consensus? Fine, ignore that bit. That's not the most

The sense of the room was taken, and expressed agreement with a small set
of sentences.  I don't see much utility in parsing the event beyond that
simple statement of what happened.

> -- them, be it calling them "naive" or "overwrought" or "omphaloskepsis",
> is often effective, but inappropriate.)
>

I apologize for using dismissive language.  But actually, my main concern
here is that we're getting distracted by minutiae from things that have
bigger-picture significance.

> Consensus on *what* exactly in this case? Consensus that we should all be
> happy? Consensus that we should all have a pony?
>
> It is true that consensus (rough or otherwise) is a state, and that state
> can always change. But consensus should be on a particular point and it
> must be relatively stable; it shouldn't be claimed on some broad platitude
> for which nobody knows the details, and it shouldn't change unless new
> information is brought into the mix.
>

Consensus on the three questions that were asked (copying from Scott's
message):
1. Is the IETF willing to respond to pervasive surveillance as an attack?
2. IETF should include encryption even outside of authentication where
practical?
3. The IETF should strive for e2e encryption even when there are
middleboxes in the path?

There are ambiguities there.  There are ambiguities in any sentence written
in human language.  We should have the discussion to sort out the
ambiguities and turn these principles into actions.  But the need for that
discussion doesn't undermine the utility of establishing that we have some
base level of agreement.

> IETF to be estimated in plenary session and that it requires some specially
> anointed person (not of the IAB) to judge that consensus.
>
>
> No, I am absolutely not saying that. I disagree completely with all of the
> above statement.
>
> (anyone) to *estimate* what the consensus of the IETF might be in plenary
> and state that. Sometimes that might even be a good thing.
>
> information about the sentiment of the room and it might even give you an
> estimate of what the consensus of the room is. All fine.
>

I don't think it's reasonable to call a hum at the end unreasonable :)
Just because we're not in the room doesn't mean we can't continue
discussing.  A hum is just a point measurement, whether it comes at the
beginning or the end.  In this case, it was a measurement at the beginning
of the discussion, which seems useful to me for establishing some points on
which there is substantial agreement and some points where we need to have
some discussion.  In that sense, it has clearly worked, as Scott's thread
demonstrates.

Discussion of the content of the hums -- what do these principles we've
agreed on really mean? -- is a worthwhile activity.  Trying to declare the
measurement invalid because of how it was done is not.

> IETF decision -- does take someone who the IETF has agreed is responsible
> to do that. Estimating consensus or guessing consensus or otherwise
> sticking one's finger into the wind and predicting consensus are all fine
> -- unless you're doing so to try to shove people into a particular position
> -- but making a final call *is* something that we leave for someone in
> particular. You'll not that when Ted asked for the hum, he asked Jari to do
> it. And again, none of this is the important point of my message.)
>

I never got the impression that this was what was being done.

> Sorry: What decision exactly?

Poor choice of words.  The outcome of the hum.

>  These consensus calls seem to have captured the high-level consensus of
> the IETF, as gathered in plenary at this meeting.  Yes, there was argument
> Have a hum and applause to make you feel good. Just don't  confuse people
> to think that it means the IETF has come to consensus.
>
> principles. Just don't  confuse people to think that it means the IETF has
> come to consensus.
>

The adjectives "fluffy", "political", and "theatrical" just don't apply to
the questions that were asked.  They're "big", but they're about technical
priorities for design -- what scenarios do we want to address with security
the technologies we're developing?

These are useful and actually surprisingly concrete questions for setting
the overall direction of technical development in the IETF.  They were
already cited in the STIR meeting only a few hours after they were called.
Let's appreciate the value of having agreement on a particular set of
words, even if those words might not have an engineer's preferred level of
precision and clarity.

--Richard

>
> pr
>
>
>   On Wed, Nov 6, 2013 at 11:21 PM, Pete Resnick <[email-masked]
> > wrote:
>
>>>> consensus is broadly held. I appreciated Russ’ composition of the issues
>>>> and think he deserves our thanks.
>>>>
>>>
>> enforce any of these things as consensus of the IETF (e.g., "Sorry; we had
>> a hum and there was consensus that we're doing encryption without
>> authentication whether you'd like to or not, so you're in the rough"), that
>> should be appealed immediately.
>>
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 7 Nov 2013 18:29:46 +0000

Jari,

Well spoken

Klaas

---

From: Pete Resnick <[email-masked]>
Date: Thu, 7 Nov 2013 10:49:02 -0800

Yay! What he said!

(There will be those who now say, "Wait! I thought Pete disagreed. I 
don't understand." Talk to me offline. Trying to explain on the IETF 
list will be less than productive.)

pr

---

From: Dave Cridland <[email-masked]>
Date: Thu, 7 Nov 2013 19:59:54 +0000

On Thu, Nov 7, 2013 at 6:49 PM, Pete Resnick <[email-masked]>wrote:

> Yay! What he said!
>
> (There will be those who now say, "Wait! I thought Pete disagreed. I don't
> understand." Talk to me offline. Trying to explain on the IETF list will be
> less than productive.)

About the only thing that this thread has productively done is helped fill
some hard disk in Utah.

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Nov 2013 00:49:25 +0000

On Nov 7, 2013, at 9:41 AM, Pete Resnick <[email-masked]> wrote:
> It is true that consensus (rough or otherwise) is a state, and that state can always change. But consensus should be on a particular point and it must be relatively stable; it shouldn't be claimed on some broad platitude for which nobody knows the details, and it shouldn't change unless new information is brought into the mix.

Why not?  Claiming consensus on a broad platitude may well be very constructive from the perspective of gaining momentum in actually doing something, not only within the IETF but outside of the IETF.   It's true that it doesn't have much effect beyond that, but just because a thing has only effect A and not effect B does not mean that it has no effect.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 07 Nov 2013 17:31:28 -0800

On 11/7/2013 4:49 PM, Ted Lemon wrote:
> Claiming consensus on a broad platitude may well be very constructive from the perspective of gaining momentum in actually doing something,

Entirely true.  And that's an entirely constructive justification for 
doing the moment of theatre of a hum.

But that's one hum, not 4.  Four looks like something is trying to make 
more elaborate and more meaningful assessments.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Nov 2013 22:16:24 -0500

> About the only thing that this thread has productively done is helped fill

Not true.  It has also proved that subject-line spelling is affected
by travelling to Canada.

-- 
Andrew Sullivan
[email-masked]

---

From: Jorge Amodio <[email-masked]>
Date: Fri, 8 Nov 2013 13:21:38 -0600

Is there a topic ? .... Hum

-Jorge

> On Nov 7, 2013, at 11:50 AM, Jari Arkko <[email-masked]> wrote:
>