Subject: [perpass] Fwd: Re: perens-perpass-appropriate-response-01

From: Bruce Perens <[email-masked]>
Date: Sat, 07 Dec 2013 16:09:08 -0800

-------- Original Message --------

Subject:

Re: [perpass] perens-perpass-appropriate-response-01

Date:

Sat, 07 Dec 2013 15:45:49 -0800

From:

Bruce Perens <[email-masked]>

To:

Stephen Farrell <[email-masked]>

On 12/07/2013 05:14 AM, Stephen
Farrell wrote:

The
lack of confidentiality lets the adversary win the race unless
you assume 100% coverage of authenticated JS and 100% validation
of that and that there are no diginotar like entities involved
in the currently non-existent JS authentication infrastructure.

Well, we do have some HTTP uses where encryption that hides the
content won't be allowed, and thus authentication is important.

We can't have encryption when we use HTTP over Amateur Radio in
the US and many other countries. There is self-policing on ham
frequencies that requires that people be able to copy other
people's transmissions, and encryption defeats that. Obviously we
don't put confidential data on those frequencies, that belongs on
your cell phone. So, an authentication-only WiFi protocol is
needed for Amateur Radio, and possibly an authentication-only
version of TLS.

Even when authentication is not available end-to-end, we gain
something by inserting it at the radio gateway.

There are also some situations involving legal minors or prisoners
where there should be monitoring. So an authentication-only
protocol is interesting for that too.

Thanks

Bruce

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 7 Dec 2013 17:57:37 -0800

> We can't have encryption when we use HTTP over Amateur Radio in the US and
many
> other countries. There is self-policing on ham frequencies that requires
that people be 
> able to copy other people's transmissions, and encryption defeats that.
Obviously we
> don't put confidential data on those frequencies, that belongs on your
cell phone. So, an 
> authentication-only WiFi protocol is needed for Amateur Radio, and
possibly an
> authentication-only version of TLS.

I for one cannot see why we would deliberately sabotage the security of the
entire Internet just to enable amateur radio to conveniently use Internet
applications and protocols. 

The amateur radio restrictions are very much the same restrictions that
hampered the security of other Internet links before crypto was deregulated
in the 90's. Governments  used the power of regulation and licensing to
ensure that these restrictions were kept in place for amateur radio. That's
too bad, but we should not make the whole Internet insecure just to please
the radio amateurs.

-- Christian Huitema

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 8 Dec 2013 07:55:50 -0800

On Dec 7, 2013, at 4:09 PM, Bruce Perens <[email-masked]> wrote:
> Well, we do have some HTTP uses where encryption that hides the content won't be allowed, and thus authentication is important.
> 
> We can't have encryption when we use HTTP over Amateur Radio in the US and many other countries. There is self-policing on ham frequencies that requires that people be able to copy other people's transmissions, and encryption defeats that. Obviously we don't put confidential data on those frequencies, that belongs on your cell phone. So, an authentication-only WiFi protocol is needed for Amateur Radio, and possibly an authentication-only version of TLS.

NO!!!!

The reason is downgrade attacks.  A huge problem with the IPSec standard is that NULL encryption was allowed in there, and also known weak modes (single DES, 720b D/H etc).  Its one of the primary reasons why John Gilmore and therefore others feel the IPSec process was sabotaged by the NSA.

To explicitly support downgraded, athuentication w/o encryption is STUPID!  it is DANGEROUS!  

About the only thing that is not a horrid idea is to have the key exchange generate a separate MAC and encryption key, using an encrypt then MAC structure.   Yet that loses out on the benefit of authenticated encryption modes that build the MAC into the communication.

So face it Bruce, your only option should be to have the client leak the session keys keys, and thereby explicitly say "NO SECURITY ON THIS CONNECTION, HAVE A NICE DAY".  

And yes, this means the French can pwn you.  Sorry, use a network that allows encryption.  Or have your session key leaker in UDP, and only 2-3 hops on the TTL, so only locals can pwn you.  [1] 

Anything more built into the protocol to support unencrypted communication represents a sabotage attempt on the rest of the Internet.

[1] I'm just waiting for the Botnet that uses open-WiFi to pwn the fellow computers in the local starbucks.  Its an old idea, but a good one...

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Dec 2013 13:51:25 -0500

This is actually my reason for opposing making http a mandatory

I am fine with the idea of requiring strong TLS

I am fine with the idea of a new mechanism for weakly authenticated http.

But do not weaken TLS so that it can be used as a proxy bypass
strategy without strong crypto

Do it right or write your own. Do not damage the only security
protocol we have so some folk can shave a few msec off latency

Sent from my difference engine

> On Dec 8, 2013, at 10:55 AM, Nicholas Weaver <[email-masked]> wrote:
>
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Dec 2013 20:49:53 +0000

On 12/08/2013 03:55 PM, Nicholas Weaver wrote:
>> people's transmissions, and encryption defeats that. Obviously
>> we don't put confidential data on those frequencies, that belongs
>> on your cell phone. So, an authentication-only WiFi protocol is
> The reason is downgrade attacks.  A huge problem with the IPSec 
> standard is that NULL encryption was allowed in there, and also
> known weak modes (single DES, 720b D/H etc).  Its one of the
> primary reasons why John Gilmore and therefore others feel the
> IPSec process was sabotaged by the NSA.

Really? That makes no sense to me. I've never heard any report of a
use of IPsec that "accidentally" used a NULL or weak cipher. Have
you? And Jeff Schiller I think convincingly repudiated claims that
either the development process for IPsec or the output were
saobtaged in any such way.

I wasn't much involved myself but my impression was that we (the
IETF security community) shot ourselves in the foot a bit via
complexity and various refusals to prioritise progress and
deployment over purity.

We need to carefully balance security and pragmatism here IMO if
our goal is to make for a more secure and privacy friendly Internet.

I also think that throwing "sabotage" into the mix damages that
discussion so should be avoided.

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 08 Dec 2013 22:00:19 +0000

Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us
why the group at that time decided to develop a NULL encryption
mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have
no heard

In context of our discussion on this list the answer will give us a lot
of guidance for the future.  Even 2 years ago I had lots of people
arguing in the OAuth working group that authentication and integrity
protection is sufficient and that we do not need confidentiality
protection. So, I wouldn't be surprised if the same argument showed up
10 years earlier.

We have to look forward, with our knowledge of the changed threat
landscape, so that we make better design choices in ongoing and future
IETF work.

Ciao
Hannes

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 09:53:14 -0500

Hannes,
> mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have 
NULL encryption is offered as an option for ESP to enable ESP to be used 
in contexts
where data integrity, authentication and anti-replay may be required, 
but confidentiality is not desired. AH was designed to offer this set of 
security requirements, but we found that ESP was much more efficient, 
and thus we included NULL encryption as an option for ESP. BTW, the most 
common motivation for not imposing confidentially is a need to perform 
packet inspection in an enterprise environment.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Dec 2013 10:20:19 -0500

Nicholas,
> The reason is downgrade attacks.  A huge problem with the IPSec standard is that NULL encryption was allowed in there, and also known weak modes (single DES, 720b D/H etc).  Its one of the primary…
John's assertions in this context are not informed by participation in
the IPsec WG process at that time, to the best of my recollection.
> To explicitly support downgraded, athuentication w/o encryption is STUPID!  it is DANGEROUS!
Not at all. We already had AH;  we offered ESP with NULL encryption as a 
more
efficient way to achieve the same security goals.
>   About the only thing that is not a horrid idea is to have the key exchange generate a separate MAC and encryption key, using an encrypt then MAC structure.   Yet that loses out on the benefit of…
The use of distinct algs for the distinct security services was 
consistent with the standard alg options of the original time frame. 
Note that combined mode algs, that offer confidentiality and integrity, 
are explciitly accommodated in later versions of the specs, e.g., 4303.

Steve