Subject: Transparency in Specifications and PRISM-class attacks

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Sep 2013 11:37:31 -0400

One of the biggest problems resulting from the Snowden/PRISM fiasco is that
we now know that the NSA has been spending a significant sum (part but not
all of a $250 million budget) on infiltrating and manipulating the
standards process.

As one of my friends in the civil rights movement from the 60s told me, the
worst thing that we could do now is to have a witch hunt looking for the
informers. Not least because it is not just the NSA that we should worry
about. There are many other governments attempting to influence decisions
in standards process for their own ends.

For what it is worth, I think the mode of influence is likely indirect. If
anyone has seen the movie Breaking Glass, there is the scene where the
record company A&R man tells the manager to stand firm against the band
member's demand for a new rig that he tells the band that their sound
desperately needs.

The issue is not limited to pure security issues either. The biggest
diplomatic storms over the Internet come from the perception that the US is
controlling IP address space and BGP AS numbers. The risk for a foreign
government is that the US could abuse its influence over the institutions
it has created to manage these resources for economic leverage at some
point.

The issue we need to focus on is how to convince our audience that our
specifications have not been compromised by government influence.

Whatever our personal political views on the matter are, the views of our
audience are likely to be different. Most of our audience are not US
citizens, they are not even from the Anglosphere.

Ever since I left MIT to help start VeriSign I have been on notice that
every proposal I make is immediately suspect as it might be an attempt to
bind the Internet to the power of the one CA. That is OK, I don't complaint
about that, I have always understood that anyone who is taking on a
position of extreme responsibility is subject to an equally extreme degree
of proof.

The point I am making here is everyone else needs to think in the same
manner.

One bad habit I think that should stop is trimming requirements before
starting design. If a legitimate use case raises a legitimate requirement,
that requirement should appear in the final requirements document produced
whether it is addressed in the final design or not.

The process I have seen instead is that people argue about whether a
requirement should be included in the requirements document and the final
requirements document is a list of requirements the noisiest people in the
group thought were important rather than what the document should be which
is a tool to determine whether the design is capable of addressing the use
cases.

And yes, I am raising this because I suspect that manipulating requirements
is one of the chief ways that undue and corrupt influence is applied.

-- 
Website: http://hallambaker.com/

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Sep 2013 18:59:28 +0300

Hi Phillip,

I am personally not worried that the standardization work in the IETF 
can be sabotaged by governments since our process is open, and 
transparent to everyone who cares to see what is going on. I could, 
however, see easily how that is a problem with some other organizations 
(without listing any).

I believe it is useful to talk about specific cases instead of abstract 
concerns to see whether there is a problem at all in the IETF. Maybe 
that would allow us to find out whether there is a room for improvement.

Ciao
Hannes

PS: From my work in the IETF I am more worried about security & privacy 
unfriendly ideas individuals and companies come up with. Those obviously 
help the NSA and others to intercept communication more easily.

On 19.09.2013 18:37, Phillip Hallam-Baker wrote:
> One of the biggest problems resulting from the Snowden/PRISM fiasco is
> that we now know that the NSA has been spending a significant sum (part
> but not all of a $250 million budget) on infiltrating and manipulating
> the standards process.
>
> As one of my friends in the civil rights movement from the 60s told me,
> the worst thing that we could do now is to have a witch hunt looking for
> the informers. Not least because it is not just the NSA that we should
> worry about. There are many other governments attempting to influence
> decisions in standards process for their own ends.
>
> For what it is worth, I think the mode of influence is likely indirect.
> If anyone has seen the movie Breaking Glass, there is the scene where
> the record company A&R man tells the manager to stand firm against the
> band member's demand for a new rig that he tells the band that their
> sound desperately needs.
>
> diplomatic storms over the Internet come from the perception that the US
> is controlling IP address space and BGP AS numbers. The risk for a
> foreign government is that the US could abuse its influence over the
> institutions it has created to manage these resources for economic
> leverage at some point.
>
>
> Whatever our personal political views on the matter are, the views of
> our audience are likely to be different. Most of our audience are not US
> every proposal I make is immediately suspect as it might be an attempt
> to bind the Internet to the power of the one CA. That is OK, I don't
> complaint about that, I have always understood that anyone who is taking
> on a position of extreme responsibility is subject to an equally extreme
> degree of proof.
>
> starting design. If a legitimate use case raises a legitimate
> requirement, that requirement should appear in the final requirements
> document produced whether it is addressed in the final design or not.
>
> requirement should be included in the requirements document and the
> final requirements document is a list of requirements the noisiest
> people in the group thought were important rather than what the document
> should be which is a tool to determine whether the design is capable of
> addressing the use cases.
>
>
> And yes, I am raising this because I suspect that manipulating
> requirements is one of the chief ways that undue and corrupt influence
> is applied.
>
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Sep 2013 12:49:04 -0400

On Thu, Sep 19, 2013 at 11:59 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi Phillip,
>
> I am personally not worried that the standardization work in the IETF can
> be sabotaged by governments since our process is open, and transparent to
> everyone who cares to see what is going on. I could, however, see easily
> how that is a problem with some other organizations (without listing any).
>

Really?

Are IESG decisions transparent? Where are the audio recordings of the con
calls? Is the IESG/IAB retreat transparent? The NOMCON process certainly is
not.

I have been in pretty much every standards body in the field and the view
of the IETF from outside the IETF is exactly the same as the one you just
gave of those other organizations. Its the reverse of the grass is always
greener.

Document editors have a huge amount of discretion in what they do or do not
include in their documents. Rather more influence than the Chairs in most
WGs.

The traditional view of an RFC is that it is just a description of the
design. What I am arguing for is that we need to capture both the final
design and the design process. People are not going to go through ancient
working group archives to convince themselves that the design is sound. The
design docs have to provide all the explanation necessary.

> concerns to see whether there is a problem at all in the IETF. Maybe that
> would allow us to find out whether there is a room for improvement.
>

I don't want to talk about specific cases because that leads to the game of
hunt the NSA mole which is a really bad idea.

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Sep 2013 19:41:26 -0400

Right, exactly.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 12:20:26 +0200

I'd like to snippet Phil's suggestion to an abbreviated version of one 
sentence, becaue I think this is right on.

On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
> specifications have not been compromised 

To my mind, the first thing to focus on is making our specs readable, so 
that it's possible to understand that they have not been compromised.

That means that complexity is our enemy.

(Or perhaps the zeroeth thing is actually finishing our specs, so that 
we can worry about whether RFC XXXX is compromised rather than worrying 
about whether deployed equipment has fixed the glitch that was 
introduced in -24 and fixed in -27, but everyone had forgotten about by 
-33...)

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 14:38:07 +0300

> that it's possible to understand that they have not been compromised.

Three questions for you Harald:

1) When you say that our documents have to be "readable" then you have 
to say readable by whom? Of course, most of our documents are tailored 
to those who implement rather than to, let's say, someone who has little 
understanding of Internet technology in general.

2) Are there documents you find non-readable?

3) Do you have any reasons to believe that there are documents that have 
been compromised?

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 15:12:00 +0200

On 09/20/2013 01:38 PM, Hannes Tschofenig wrote:
> to those who implement rather than to, let's say, someone who has 
> little understanding of Internet technology in general.

By those who implement them, and those who try to understand how it 
works to the degree that they feel assured that there are no 
non-understood security risks (intentional or otherwise).

> 2) Are there documents you find non-readable?

 From the stack I'm currently working on, I find the ICE spec to be 
convoluted, but the SDP spec is worse, becaue it's spread across so many 
documents, and there are pieces where people seem to have agreed to ship 
documents rather than agree on what they meant.
I have not found security implications of these issues.

>
> 3) Do you have any reasons to believe that there are documents that 
> have been compromised?
>
I have no evidence that they have intentionally been compromised. I 
think we manage to make specs unreadable without deliberate obfuscation 
- but the reader can't know that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Sep 2013 09:23:46 -0400

> That means that complexity is our enemy.

There are two types of unnecessary complexity. One is caused by having
useless mechanism and the other by insufficient abstraction. It is not
always possible to distinguish one from the other.

The key in my view is to look at use cases and requirements and look to see
if the need for multiple features is driven by a requirement or not.

For example, do we really need 30 different authentication algorithms in a
protocol? Whenever we talk about authentication we end up with a new
framework on the existing frameworks rather than just picking one.

Restricting requirements to those driven by use cases helps cull that type
of complexity. 'Support the SPLUNGE password authentication' might be a
useful requirement or it might not. If there is an existing infrastructure
of SPLUNGE users that we need to interoperate with, then there will be a
use case. If the requirement has been inserted by the academic who designed
SPLUNGE then there is no supporting use case.

The EASA requirements analysis scheme we tried to use at CERN had a
practice that I have adopted in some of my specs of labeling each
requirement with a short form label [R-SPLUNGE] which then allows for
automated checking for consistency to show that each requirement is
supported by at least one use case and show which requirements are met and
thus which use cases.

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Sep 2013 09:34:20 -0400

> that it's possible to understand that they have not been compromised.

Who are you including in "our audience"?  There is no way, whether by
removing complexity or not, to make it possible for the average
network manager or BGP configurer to be certain that a particular
crypto method does not have the insidious influence of some shadowy
organization baked into it.  And if your audience is experts in the
field, then they probably don't see the complexity as complex.
Frankly I don't think Philip's goal is possible except through
non-technical means such as open processes.

---

From: Martin Sustrik <[email-masked]>
Date: Fri, 20 Sep 2013 16:02:13 +0200

On 19/09/13 17:59, Hannes Tschofenig wrote:

> transparent to everyone who cares to see what is going on.

Isn't it the other way round? That exactly because IETF process is open 
it's relatively easy for anyone to secretly introduce a backdoor into a 
protocol?

I mean, NSA does security screenings, holds people legally responsible 
if they defect etc. So, if I have a NSA-devised protocol, I am almost 
sure there's at most 1 backdoor there. If I am afraid of KGB, the 
protocol may work well for me. With IETF standard there can very well be 
several unknown backdoors introduced by different parties, so it's never 
safe.

That being said, wouldn't it make more sense to admit that IETF is not a 
good platform for devising, say, crypto protocols and act accordingly 
(use 3rd party protocols, make it mandatory for new protocols to enable 
pluggable crypto etc.)?

Martin

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Sep 2013 10:15:19 -0400

On Sep 20, 2013, at 9:12 AM, Harald Alvestrand <[email-masked]> wrote:
> From the stack I'm currently working on, I find the ICE spec to be convoluted, but the SDP spec is worse, becaue it's spread across so many documents, and there are pieces where people seem to have agreed to ship documents rather than agree on what they meant.

This sort of thing is a serious problem; people do make efforts to address it by writing online guides to protocol suites, but this isn't always successful, and for that matter isn't always done.   We could certainly do better here.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 20 Sep 2013 10:28:26 -0400

>From my experience, some people not as familiar with the IETF have trouble understanding how to fit RFCs together.  That leads to a readability problem in itself.  Some also don't realize that you can reference part of one RFC and not the whole thing rather than reinventing the wheel or documenting something again.

For MILE, we had several requests to pull together descriptions on how the drafts & RFCs fit together.  We did a short video, but need to get a wiki or something together to assist.  In light of the current thread, I think it is important to include in that the current set of security protections in case they are not adequate and it gets someone's attention who is interested to help improve things (even just through critiques).  We will try to get this together in a wiki soon.  If it helps readability, maybe to would be good for others to consider?

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, September 20, 2013 7:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Transparency in Specifications and PRISM-class attacks

On 20.09.2013 13:20, Harald Alvestrand wrote:
> To my mind, the first thing to focus on is making our specs readable, 
> so that it's possible to understand that they have not been compromised.

1) When you say that our documents have to be "readable" then you have to say readable by whom? Of course, most of our documents are tailored to those who implement rather than to, let's say, someone who has little understanding of Internet technology in general.

3) Do you have any reasons to believe that there are documents that have been compromised?

---

From: John C Klensin <[email-masked]>
Date: Fri, 20 Sep 2013 10:34:40 -0400

--On Friday, September 20, 2013 10:15 -0400 Ted Lemon
<[email-masked]> wrote:

>> From the stack I'm currently working on, I find the ICE spec
>> to be convoluted, but the SDP spec is worse, becaue it's
>> spread across so many documents, and there are pieces where
>> people seem to have agreed to ship documents rather than
>> agree on what they meant. I have not found security
>> implications of these issues.
> 
> This sort of thing is a serious problem; people do make
> efforts to address it by writing online guides to protocol
> suites, but this isn't always successful, and for that matter
> isn't always done.   We could certainly do better here.

Ted,

Based in part on experience with the specs of, and discussions
in, other standards bodies, the problem with guides (online or
not) is 

(1) They may contain errors and almost always have omissions.
The latter are often caused by the perfectly good intention of
simplifying things and making them understandable by covering
only the important cases.

(2) If they are comprehensible and the standard is not, people
tend to refer to them and not the standard.  That ultimately
turns them into the "real" standard as far as the marketplace is
concerned.   FWIW, the same problem can, and has, happened with
good reference implementations.

I don't know of any general solution to those problems, but I
think the community and the IESG have got to be a lot more
willing to push back on a spec because it is incomprehensible or
contains too many options than has been the case in recent years.

   john

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Sep 2013 16:48:52 +0200

> 2) Are there documents you find non-readable?

I'm not sure you aren't mocking us, but...

*Yes*, there are documents in the IETF that are highly non-accessible.

I could name examples from areas other than security, but probably the most glaring example in the security area is the maze of twisty little passages that the TLS spec is.

Many of the specifications that make up TLS are of the form "MMM is almost like [RFCNNNN], except that.".  Of course, RFCNNNN says "NNN is almost like [RFCQQQQ], except that.".  In the end, you need several weeks of analysis, heaping layer over layer of changes, with increasing uncertainty of what the spec resulting from this layer cake really says.  Also when trying to ascertain a specific property, all these changes have to be examined again, and it is really easy to misinterpret one of these changes, coming up with the wrong conclusion.  The whole thing reminds me of the old concept of an "interfiled" loose-leaf service update, except that the new pages are never actually sorted in but you are keeping all the updates around together with the original set to check them in sequence whenever you need a specific page.

I think I understand how the current situation came about, but I think it qualifies for "documents you find non-readable".

Grüße, Carsten

PS.: Harald: The SDP spec is bad in large parts because of the mission creep; SDP was great for its uses in 1993 but is excruciatingly bad for what it is being used for today.  It's a disaster we didn't manage to replace it in time before the complexity ballooned...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Sep 2013 11:28:04 -0400

On Fri, Sep 20, 2013 at 10:02 AM, Martin Sustrik <[email-masked]> wrote:

> I mean, NSA does security screenings, holds people legally responsible if
> they defect etc. So, if I have a NSA-devised protocol, I am almost sure
> there's at most 1 backdoor there.

Absolutely not.

We know that the process failed with Snowden. We do not know where else it
failed.

You will note that I am not criticizing the NSA, I am criticizing the
current management.

> If I am afraid of KGB, the protocol may work well for me. With IETF
> standard there can very well be several unknown backdoors introduced by
> different parties, so it's never safe.
>

If you are working for the Brazilian government then you are probably not
going to be happy with either prospect.

The Web is an international resource. It does not belong to one government
or country.

> good platform for devising, say, crypto protocols and act accordingly (use
> 3rd party protocols, make it mandatory for new protocols to enable
> pluggable crypto etc.)?

Plugable crypto is not a good idea. We are pretty sure we know how to do
algorithms now, our recent failures have come from the plugability
infrastructures.

Plugable trust models is where we need to go. We are not going to have a
ubiquitous email security infrastructure unless we can move past the S/MIME
vs PGP stalemate. One has deployment, the other mindshare. We should have
built one infrastructure capable of supporting both trust models rather
than two competing proposals.

I see PRISM as an opportunity for us. We have a once in a decade
opportunity to revisit our biggest security failure: email. We have two
infrastructures that are 95% there. We do not need to redo that 95%, we
need to remove some stuff thats in the way and add in the missing 10%.

---

From: SM <[email-masked]>
Date: Fri, 20 Sep 2013 09:03:17 -0700

>non-understood security risks (intentional or otherwise).

Yes.

> convoluted, but the SDP spec is worse, becaue it's spread across so 
> many documents, and there are pieces where people seem to have 
> agreed to ship documents rather than agree on what they meant.

I'll quote a message [1] from an ex-IAB member:

   "in IPv4 days:
     - implement and test
     - then write a draft
    or,
     - BSD IPv4 code is there
     - everyone cheated and looked at it
    today:
     - write a draft with pipe dream
     - spam IESG
     - then implement
     - big issue happen
     - go back to 1"

It is an implementor's nightmare to understand a specification when 
it is spread across multiple documents.  The "Updates" and document 
status (label) does not make matters easier.  Some parts will not be 
committed into the tree as it is not simply a matter of writing code; 
there is also the question of who is going to maintain that code.

>contains too many options than has been the case in recent years.

If I recall correctly there was a discussion about a solution in 
1992.  RFC 2026 also considered the problem of too many options and 
offered a path to resolve that.

At 08:37 19-09-2013, Phillip Hallam-Baker wrote:
>Whatever our personal political views on the matter are, the views 
>of our audience are likely to be different. Most of our audience are 
>not US citizens, they are not even from the Anglosphere.

Yes.

>of the one CA. That is OK, I don't complaint about that, I have 
>always understood that anyone who is taking on a position of extreme 
>responsibility is subject to an equally extreme degree of proof.

Yes.

>people in the group thought were important rather than what the 
>document should be which is a tool to determine whether the design 
>is capable of addressing the use cases.

The boundary between use cases and edge cases is not always 
clear.  The requirements document is a long list of stuff to satisfy 
the noisiest and the people considered as important.  Harald 
Alvestrand mentioned "actually finishing our specs".  It's difficult 
to get there when a working group suffers from exhaustion.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ipv6/current/msg07313.html

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 19:59:02 +0300

On 20.09.2013 16:23, Phillip Hallam-Baker wrote:
> For example, do we really need 30 different authentication algorithms in
> a protocol? Whenever we talk about authentication we end up with a new

I don't think that there is something wrong with an authentication 
framework as such. You know why we are not just picking one 
authentication algorithm, one cryptographic primitive, one credential 
type, etc.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 20:03:22 +0300

Martin, I have no clue how you come up with that conclusion. Have you 
ever worked in organizations that are closed to a small number of 
members where decisions are being made behind closed doors? Do you think 
that would help to produce better results?

I think the openness and transparency is the best tool we have, even 
though it might not be perfect since we still need people to speak up 
when they see something fishy and we obviously need reviewers.

If you spot a "backdoor" introduced by someone in the IETF work then you 
should speak up. I have not heard about examples of such backdoors in 
this discussion yet.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 20:18:08 +0300

Hi Kathleen,

you are responding to the question about the target audience* and I saw 
your video. That's an interesting idea to reach out to those who are not 
yet involved in an IETF group.

Of course, our working group pages and the Wikis are not necessarily are 
great way to communicate with people other than our main target audience.

There is indeed something we could improve and I had in fact given a 
presentation about this topic to the IAB at the retreat this year. Here 
are the slides:
http://www.tschofenig.priv.at/IAB_Work_Style.pdf

Ciao
Hannes

PS: I got the impression from Harald's response that he was actually 
thinking about a different audience. Of course, the audience determines 
the content.

On 20.09.2013 17:28, Moriarty, Kathleen wrote:
> From my experience, some people not as familiar with the IETF have
> trouble understanding how to fit RFCs together.  That leads to a
> readability problem in itself.  Some also don't realize that you can
> reference part of one RFC and not the whole thing rather than
> reinventing the wheel or documenting something again.
>
> For MILE, we had several requests to pull together descriptions on
> how the drafts&  RFCs fit together.  We did a short video, but need
> to get a wiki or something together to assist.  In light of the
> current thread, I think it is important to include in that the
> current set of security protections in case they are not adequate and
> it gets someone's attention who is interested to help improve things
> (even just through critiques).  We will try to get this together in a
> wiki soon.  If it helps readability, maybe to would be good for
> others to consider?
>
> Thanks, Kathleen
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig Sent:
> Friday, September 20, 2013 7:38 AM To: [email-masked] Cc:
> [email-masked] Subject: Re: Transparency in Specifications and
> PRISM-class attacks
>
>> To my mind, the first thing to focus on is making our specs
>> readable, so that it's possible to understand that they have not
>> been compromised.
>
> 1) When you say that our documents have to be "readable" then you
> have to say readable by whom? Of course, most of our documents are
> tailored to those who implement rather than to, let's say, someone
> who has little understanding of Internet technology in general.
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 20 Sep 2013 13:24:32 -0400

Hi Hannes,

I would also like to reach developers that may not be familiar with the IETF and find themselves assigned with developing protocols we designed.  I'll see if I (or my co-chair) can get something together in short order.  ENISA was reviewing materials and asked for this type of information.  For our work, they are an important group that have not been attending meetings, but do follow the work.  

Thanks,
Kathleen

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, September 20, 2013 1:18 PM
To: Moriarty, Kathleen
Cc: Hannes Tschofenig; [email-masked]; [email-masked]
Subject: Education and Information Sharing ... was Re: Transparency in Specifications and PRISM-class attacks

Hi Kathleen,

you are responding to the question about the target audience* and I saw your video. That's an interesting idea to reach out to those who are not yet involved in an IETF group.

Of course, our working group pages and the Wikis are not necessarily are great way to communicate with people other than our main target audience.

There is indeed something we could improve and I had in fact given a presentation about this topic to the IAB at the retreat this year. Here are the slides:
http://www.tschofenig.priv.at/IAB_Work_Style.pdf

Ciao
Hannes

PS: I got the impression from Harald's response that he was actually thinking about a different audience. Of course, the audience determines the content.

On 20.09.2013 17:28, Moriarty, Kathleen wrote:
> For MILE, we had several requests to pull together descriptions on how 
> the drafts&  RFCs fit together.  We did a short video, but need to get 
> a wiki or something together to assist.  In light of the current 
> thread, I think it is important to include in that the current set of 
> security protections in case they are not adequate and it gets 
> someone's attention who is interested to help improve things (even 
> just through critiques).  We will try to get this together in a wiki 
> soon.  If it helps readability, maybe to would be good for others to 
> consider?
>
> Thanks, Kathleen
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 20:25:09 +0300

Carsten,

I am not saying all the specifications are great but I wanted to know 
first what target audience Harald is talking about.

You are talking about us, guys who have been in the IETF for a long 
time, as the target audience. If we find specifications difficult to 
read then that's a real issue since it is rather unlikely that anyone 
else will find it a lot easier.

If you talk about regulators as another potential target audience of our 
documents, for example, then you might quickly find out that they find 
all our specifications unreadable.

I also have a number of things I don't like but I personally don't think 
that improving the readability of our specifications will lead to a 
change in the offered security.

Ciao
Hannes

On 20.09.2013 17:48, Carsten Bormann wrote:
> On Sep 20, 2013, at 13:38, Hannes Tschofenig<[email-masked]>  wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Sep 2013 10:27:18 -0400

On Sep 20, 2013, at 10:02 AM, Martin Sustrik <[email-masked]> wrote:
> Isn't it the other way round? That exactly because IETF process is open it's relatively easy for anyone to secretly introduce a backdoor into a protocol?

No, this is exactly wrong.

What is important about openness is not who is allowed to make changes, but who is allowed to see changes being made.   So sure, the NSA could send someone in to try to sabotage a protocol.   But people who want the protocol to be secure are also welcome.  This means that they have a chance to prevent the sabotage, if they can detect it as it is happening, and it also means that we can audit the process later to see if it was sabotaged, and if so, by whom.

By comparison, in a closed process, the NSA is still welcome.  Non-NSA people might well _not_ be welcome. There is no ability to validate the process as it is happening, so sabotage can easily be concealed.   And if sabotage is successful, it is easy both to conceal the fact of the sabotage, and also who is responsible for the sabotage.

When you think about the protection afforded by closed processes, you must always ask, quis custodiet ipsos custodes: who guards those who guard?   If the people acting as gatekeeper are corrupt, or are successfully fooled, then all is lost.   With an open process, everybody is potentially a gatekeeper, so it's much harder to corrupt the process.

In order to have backdoors, the thing in which the backdoor exists must be secret, either because nobody bothered to look, or because nobody _can_ look.   It is true that if nobody bothers to look, you can have a backdoor in any protocol, but we can't do anything about that.   We _can_ make sure that we are at least permitted to look for the backdoor.   And the IETF process very deliberately allows for that.