Subject: Re: [perpass] rough list of concrete stuff from list

From: =JeffH <[email-masked]>
Date: Mon, 16 Sep 2013 18:45:48 -0700

Here's some items not as yet on the "rough list of concrete stuff" AFAICT, which 
perhaps should be, at least from a completeness perspective (YMMV)...

Background/Requirements/Opportunities..

Adam Langley, 2009, W2SP. "Opportunistic Encryption Everywhere". W2SP.
http://w2spconf.com/2009/papers/s1p2.pdf

Andrea Bittau, et al. (2010-08-13). "The case for ubiquitous transport-level 
encryption". 19th USENIX Security Symposium.
http://www.usenix.org/events/sec10/tech/full_papers/Bittau.pdf

Opportunistic encryption (has list of various applicable projects)
http://en.wikipedia.org/wiki/Opportunistic_encryption

Linux FreeS/WAN Project - Opportunistic Encryption
Henry Spencer, D. Hugh Redelmeier.
http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec

examples..

tcpcrypt
http://en.wikipedia.org/wiki/Tcpcrypt
https://tools.ietf.org/html/draft-bittau-tcp-crypt-03

Obfuscated TCP
http://en.wikipedia.org/wiki/Obfuscated_TCP

[tcpm] Faster application handshakes with SYN/ACK payloads
http://www.ietf.org/mail-archive/web/tcpm/current/msg03829.html
http://tools.ietf.org/html/draft-agl-tcpm-sadata-01

IETF rejects Obfuscated TCP  (email thread on tcpm@)
http://comments.gmane.org/gmane.network.peer-to-peer.p2p-hackers/2099

freeS/WAN, Openswan, Libreswan et al.
http://en.wikipedia.org/wiki/FreeS/WAN

HTH,

=JeffH

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Sep 2013 10:10:16 +0100

Hi Jeff,

On 09/17/2013 02:45 AM, =JeffH wrote:
> Here's some items not as yet on the "rough list of concrete stuff"
> AFAICT, which perhaps should be, at least from a completeness
> perspective (YMMV)...

Maybe I need to clarify: I put stuff on that list where I
felt happy that I understood how the end result in the
IETF might look. Its not meant to be a complete list of
relevant stuff, nor most important stuff, just the stuff
that's already concrete enough that if it did end up in
an RFC, I reckon I understand more-or-less what'd be in
that and how we might get it done.

But those links do certainly look relevant and it'd be
good to see some discussion of them (in new threads
please).

I'll start one thread in a minute on tcpcrypt.

Cheers,
S.

> Andrea Bittau, et al. (2010-08-13). "The case for ubiquitous
> transport-level encryption". 19th USENIX Security Symposium.
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Sep 2013 15:25:59 +0300

Thanks for the list, Stephen. I also made a short list yesterday for other purposes. The items not on your list yet were:

HTTP 2.0 security becoming somehow more widely turned on than we have on current HTTP. Curent spec says it is required to implement, see http://tools.ietf.org/html/draft-ietf-httpbis-http2-06#section-9.2 and the topic is also discussed in here: http://tools.ietf.org/agenda/87/slides/slides-87-httpbis-3.pdf

I think I saw a discussion about reducing fingerprinting possibilities for web traffic somewhere.

Did we have a discussion of PFS in TLS somewhere?

And there is a category of actions we could take, but are not technical improvements themselves. For instance, we could more aggressively deprecate algorithms known to have issues. Or we could launch a review of various security mechanisms or even other protocols to find areas that need improvement. 

Jari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Sep 2013 15:34:00 +0300

> Did we have a discussion of PFS in TLS somewhere?

That's part of Yaron's draft.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Sep 2013 13:34:46 +0100

Hiya,

On 09/17/2013 01:25 PM, Jari Arkko wrote:
> Thanks for the list, Stephen. I also made a short list yesterday for
> other purposes. The items not on your list yet were:
> 
> HTTP 2.0 security becoming somehow more widely turned on than we have
> on current HTTP. Curent spec says it is required to implement, see
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-06#section-9.2
> and the topic is also discussed in here:
> http://tools.ietf.org/agenda/87/slides/slides-87-httpbis-3.pdf

Right. I think there may be a draft popping out on that soonish
so I was gonna wait for that. But yes, that's a major topic of
interest so I hope to add an item to the list for that once it
gets a little more concrete.

> possibilities for web traffic somewhere.

The UA string discussion won't result in changes I think. That's
a pity but a) its probably too ingrained in web sites to change
and b) its probably only a minor fingerprinting technique so on
balance we might have to put this one down as nice to have but
not practically changeable.

The gmt time in TLS discussion is similar, but seems much more
like its a change that can be easily done.

> Did we have a discussion of PFS in TLS somewhere?

Yep, that'll be more explicit in Yaron's -01 draft I hope but
is implicitly there now.

> And there is a category of actions we could take, but are not
> technical improvements themselves. For instance, we could more
> aggressively deprecate algorithms known to have issues. Or we could
> launch a review of various security mechanisms or even other
> protocols to find areas that need improvement.

Sure. Different list though.

S.

> 
> Jari
> 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Karl Malbrain <[email-masked]>
Date: Tue, 17 Sep 2013 12:19:07 -0700 (PDT)

I've uploaded a draft on tls strong authentication deployment:
 
http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication
Any comments would be appreciated.

________________________________
 From: Stephen Farrell <[email-masked]>
To: =JeffH <[email-masked]> 
Cc: perpass <[email-masked]> 
Sent: Tuesday, September 17, 2013 2:10 AM
Subject: Re: [perpass] rough list of concrete stuff from list

Hi Jeff,

Cheers,
S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 12:48:00 +0200

> Any comments would be appreciated.

I believe that anything based on DNS is the wrong way forward if your
problem statement involve well funded adversaries.  I think DNS-based
distribution of keying material is a good way to simplify and bootstrap
opportunistic encrypted channels, however, it would not provide strong
authentication in the way that I would like to define it.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Sep 2013 06:29:59 -0600

> 
> I believe that anything based on DNS is the wrong way forward if
> your problem statement involve well funded adversaries.  I think
> DNS-based distribution of keying material is a good way to simplify
> and bootstrap opportunistic encrypted channels, however, it would
> not provide strong authentication in the way that I would like to
> define it.

Agreed.

Unfortunately, it seems that we need to build on more solid
foundations than most of today's Internet provides. I'd include
centralized ISPs in the list of structures that are problematic.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Karl Malbrain <[email-masked]>
Date: Tue, 24 Sep 2013 13:39:33 -0700 (PDT)

I've begun to propose an alternative to DNS/DANE, the PERSPECTIVES project from CMU, in version 01 of the problem statement: http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication.
 
Have you considered what changes to the DNS system would address your concerns?  I've proposed encrypted and authenticated connections in another thread.
 
Karl Malbrain

________________________________
 From: Simon Josefsson <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: perpass <[email-masked]>; Stephen Farrell <[email-masked]> 
Sent: Tuesday, September 24, 2013 3:48 AM
Subject: Re: [perpass] tld strong authentication deployment draft

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 23:11:00 +0200

I believe the perspectives approach is better, but it seems difficult to
implement over the DNS since you can't escape its organizational warts.
I think an approach like Certificate Transparency would be even better.

/Simon

You wrote:

> I've begun to propose an alternative to DNS/DANE, the PERSPECTIVES
> project from CMU, in version 01 of the problem statement:
> http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication.
> Have you considered what changes to the DNS system would address your
> concerns?  I've proposed encrypted and authenticated connections in
> another thread. Karl Malbrain 
> 
> Cc: perpass <[email-masked]>; Stephen Farrell
> <[email-masked]> Sent: Tuesday, September 24, 2013 3:48 AM
> distribution of keying material is a good way to simplify and
> bootstrap opportunistic encrypted channels, however, it would not
> provide strong authentication in the way that I would like to define
> it.
> 
> /Simon

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Sep 2013 17:16:14 -0400 (EDT)

On Tue, 24 Sep 2013, Karl Malbrain wrote:

> I've begun to propose an alternative to DNS/DANE, the PERSPECTIVES project from CMU, in version 01 of the problem statement:

strong authentication in clients will lead to less anonimity. What is
wrong with the model of the (anonymous) client authenticating the TLS
server against MITM, and than on that private channel, do client auth,
eg via basic auth?

I'm not sure what you are trying to solve by moving the client
authentication from the inner protected layer to the outer layer.

I'm also not sure what the draft is supposed to convey....

Paul

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 25 Sep 2013 12:08:37 -0700 (PDT)

I'm sorry for the initial confusion mis-labeling client and server authentication.  Please see the most recent version of the draft where I tried to straighten this out.
 
Yes, strong authentication of servers by clients is the step needed for MITM resistance.  The question raised in the draft about authentication by servers of clients is that it should be occuring where strong authentication is desired -- say by a bank, or government agency, to verify that the server is talking directly to the client.  It's for non-anonymous relationships where the server holds some agency status and legal liability toward the user.
 
The draft is meant to outline a problem statement for a larger audience that addresses not only protocol security improvements, but policy decisions.

________________________________
 From: Paul Wouters <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Simon Josefsson <[email-masked]>; perpass <[email-masked]>; Stephen Farrell <[email-masked]> 
Sent: Tuesday, September 24, 2013 2:16 PM
Subject: Re: [perpass] tld strong authentication deployment draft

Paul