Subject: Re: Transparency in Specifications and PRISM-class attacks

From: [email-masked] (Noel Chiappa)
Date: Fri, 20 Sep 2013 11:25:06 -0400 (EDT)

> From: Martin Sustrik <[email-masked]>

    > 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?
    > ...
    > With IETF standard there can very well be several unknown backdoors
    > introduced by different parties, so it's never safe.

Iff enough people are _carefully_ reviewing specs, that ought to find all the
backdoors. An open process does have potential issues, but it's also the one
with the best chance of producing a 'good' product.

    > 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 ...)?

You mean, trust another entity, which might have been suborned? How are they
less likely to have produced something without backdoors than the IETF?

	Noel

---

From: Steve Crocker <[email-masked]>
Date: Fri, 20 Sep 2013 11:28:51 -0400

Are we conflating back doors in implementations with back doors in protocol specifications?  It's certainly a conceptual possibility for there to be a back door in a protocol specification, but I don't recall ever hearing about one.  On the other hand, back doors, both intended and unintended, in the software that implements protocols, are legion.

Steve

---

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

> with the best chance of producing a 'good' product.

It is not necessarily a backdoor.

Maybe it is encouraging the IETF to produce two email infrastructures that
are incompatible rather than just one.

Maybe it is blocking attempts to make the DNSSEC root not a monolithic,
single rooted hierarchy under control of a body that only exists due to a
contract with the US government.

Maybe it is whispering in the ears of both sides in the DNSSEC OPT-IN
debacle to ensure that no compromise was possible.

Maybe it is arguing against allowing PKIX Name constraint extensions that
are not marked critical and are thus compatible with Safari.

Encouraging a stalemate that prevents fixing a security hole in a protocol
might be the way these people are working.

Oh and I spoke to someone who has seen the documents this week. From what
he said it would not surprise me at all for one part of the NSA to be
trying to sabotage a standards effort while other government agencies,
possibly the NSA is attempting to do the opposite.

The right hand does not know what the left is doing. These systems are
heavily compartmentalized and subdivided internally. The result is that
they are operating with little overall knowledge and little accountability.

The Krell had a similar problem with their Great Machine.

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

---

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

On 20.09.2013 18:28, Steve Crocker wrote:
> Are we conflating back doors in implementations with back doors in
> protocol specifications?  It's certainly a conceptual possibility for
> there to be a back door in a protocol specification, but I don't
> recall ever hearing about one.

Of course backdoors in specifications are more subtle than in 
implementations. Instead of thinking about "backdoors" just think about 
how you could weaken a specification from a security point of view that 
is allows interception.

There are obviously a number of ways you could weaken security 
intentionally in the standardization process:

* Choose smaller key size
* Pick algorithms that are weaker than others
* Prefer an protocol architecture that allows intermediaries to inspect 
traffic
* Design lawful intercept into the architecture
* Intentionally avoid the standardization of end-to-end security mechanisms
* Prefer performance over privacy in protocol designs
* Make it very hard to change identifiers
* Design protocols, which make user control an out-of-band feature.
* Choose poor defaults with respect to security and privacy in protocols
* Design protocols that allow correlation and fingerprinting
* Delay the work on secure protocol versions and ship the plaintext 
versions much earlier than
* Prevent certain security standardization from happening.

The last two items are probably most difficult to spot but most effective.

Do any of these things sound familiar to you?

Ciao
Hannes

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Sep 2013 09:49:28 -0700

> with the best chance of producing a 'good' product.

As has been said, the premise of open standards work is that it is 
subject to broad review, as a quality assurance process.  This is 
expected to find errors -- and please forgive me for considering a 
backdoor mechanism to merely be a really bad error.

But this requires that diverse, aggressive, expert reviews do get done, 
with a special eye towards serious errors such as backdoors.

Sometimes we get those, sometimes we don't.  We make the assumption that 
the considerable array of late-stage reviews done now provide the 
necessary assurances, but really they don't.  (The original DKIM spec 
was well and highly reviewed prior to publication.  Imagine my surprise, 
when we started the -bis effort, to discover the a critical algorithm 
was so badly written it didn't work.  The accompanying prose was pretty 
good, but the pseudo-code wasn't.)

So we need to worry about active efforts to get diligent reviews that 
look for certain classes of strategic problems.  This probably requires 
three things:

    *  Ensuring clarity and simplicity in the technology and the 
specification writing make the work more accessible.  Hence we ought to 
seriously consider earlier-stage efforts to ensure that, at least for 
any protocol that carries "interesting" security sensitivities.

    *  Some community agreement about the nature of problems to look for.

    *  For those sensitive specifications, soliciting additional expert 
review, to consider robustness, reliability, and weaknesses such as 
backdoors.

On 9/20/2013 7:48 AM, Carsten Bormann wrote:
 > On Sep 20, 2013, at 13:38, Hannes schofenig<[email-masked]
 > wrote:
 >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.

The IETF approach to specification writing is unusually free-form.  It 
has the considerable benefit of permitting far more pedagogy that most 
other groups use.  This allows the document to establish its context, 
comment on technical choices and comment on use; but that then creates 
challenges for finding balance.

But often it also means that documents are poorly organized and frankly 
poorly written, as folks have been noting.  Such problems make a 
document more obscure and therefore easier for adding hidden 'features'...

On 9/20/2013 8:28 AM, Steve Crocker wrote:
 > protocol specifications?

We certainly need to be careful to distinguish between these.  We have 
direct responsibility for dealing with the latter.  Normally we stay 
hands off of the former.

However for 'sensitive' functions, we might want to press for industry 
effort to ensure that the implementations -- especially the widely 
re-used open systems versions -- haven't introduced essentially systemic 
exposures.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Sep 2013 13:08:55 -0400

I'm glad the process aspects have been brought up again.  When a WG is
finished with a draft, there is still a lot more work to do.  WG last
call is or should be closer to the middle of a draft's development
trajectory than the end.  I would say this is true not just for the
ones that someone close to the draft thinks might be sensitive, since
people close to it will have their own blind spots (and will have done
what they can for the issues they know about already).  We should have
better scrutiny for all drafts, taking our time.

Scott

On Fri, Sep 20, 2013 at 12:49 PM, Dave Crocker <[email-masked]> wrote:
> As has been said, the premise of open standards work is that it is subject
> to broad review, as a quality assurance process.  This is expected to find
> errors -- and please forgive me for considering a backdoor mechanism to
> merely be a really bad error.
>
> But this requires that diverse, aggressive, expert reviews do get done, with
> a special eye towards serious errors such as backdoors.
>
> Sometimes we get those, sometimes we don't.  We make the assumption that the
> considerable array of late-stage reviews done now provide the necessary
> assurances, but really they don't.  (The original DKIM spec was well and
> highly reviewed prior to publication.  Imagine my surprise, when we started
> the -bis effort, to discover the a critical algorithm was so badly written
> it didn't work.  The accompanying prose was pretty good, but the pseudo-code
> wasn't.)
>
> So we need to worry about active efforts to get diligent reviews that look
> for certain classes of strategic problems.  This probably requires three
> things:
>
> seriously consider earlier-stage efforts to ensure that, at least for any
> protocol that carries "interesting" security sensitivities.
>