Subject: IETF88 Technical Plenary hums

From: Russ Housley <[email-masked]>
Date: Wed, 6 Nov 2013 15:41:41 -0500

At the end of the IETF88 Technical Plenary, there were five hums.  This note is to provide the text of the hums and the community response.  The people in the room were asked to hum for YES if they agreed with the statement and hum for NO if they disagreed with the statement.

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

    Overwhelming YES.  Silence for NO.

2. Pervasive surveillance is an attack, and the IETF needs to adjust our threat model to consider it when developing standards track specifications.

    Very strong YES.  Silence for NO.

3. The IETF should include encryption, even outside authentication, where practical.

    Strong YES.  Silence for NO.

4.  The IETF should strive for end-to-end encryption, even when there are middleboxes in the path.

    Mixed response, but more YES than NO.

5.  Many insecure protocols are used in the Internet today, and the IETF should create a secure alternative for the popular ones.

    Mostly YES, but some NO.

Russ

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Nov 2013 14:06:44 -0800

Russ,

I am glad that we all want to do something about this problem.  I also
appreciate that the questions you asked were intended to be
aspirational.  Having said this, I must voice two concerns about how
these hums are taken.  First, they were formed very quickly and in
particular we did not explore at the plenary the last three questions in
any detail.  Had we done so, I would have raised my other concern, which
is that we have at least one very relevant group that has expressed
concern that opportunistic encryption could harm efforts to get
authenticated TLS well deployed.  That may be the right answer in those
circumstances – or not.  The conclusion of that discussion to be as
informed as is possible, especially given its magnitude.

It was enough for us to say that we as a community will take steps to
address pervasive surveillance.  Clearly we are taking steps to address
pervasive surveillance.

Eliot

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 7 Nov 2013 13:01:19 +0000

Hi,

> 5.  Many insecure protocols are used in the Internet today, and the IETF should create a secure alternative for the popular ones.

since a "secure DropBox alternative" was brought up: the pieces for building such do exist, but some exist outside the IETF. For example, SNIA's CDMI (http://www.snia.org/cdmi) could be useful, and on the IETF side we have of course WebDAV. 

In many cases, the reason that such alternatives don't exist probably isn't because there aren't any open protocols available to build them with, it's that the proprietary services have polished clients that are simple to set up, available for many clients, and that they have a robust and well-managed backend. There's not much the IETF can do about these factors.

In the specific case of DropBox clones, several vendors of storage systems (incl. my employer) are making or will shortly be making mobile clients available that use said storage systems as a backend instead of the public cloud. So at least for that particular application, there are alternatives available.

Lars

---

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

I've been playing and deploying instances of
https://www.owncloud.org
http://www.bittorrent.com/sync

> Eggert, Lars <mailto:[email-masked]>
> 7 November 2013 13:01
> Hi,
>
> since a "secure DropBox alternative" was brought up: the pieces for
> building such do exist, but some exist outside the IETF. For example,
> SNIA's CDMI (http://www.snia.org/cdmi) could be useful, and on the
> IETF side we have of course WebDAV.
>
> In many cases, the reason that such alternatives don't exist probably
> isn't because there aren't any open protocols available to build them
> with, it's that the proprietary services have polished clients that
> are simple to set up, available for many clients, and that they have a
> robust and well-managed backend. There's not much the IETF can do
> about these factors.
>
> In the specific case of DropBox clones, several vendors of storage
> systems (incl. my employer) are making or will shortly be making
> mobile clients available that use said storage systems as a backend
> instead of the public cloud. So at least for that particular
> application, there are alternatives available.
>
> Lars
>

---

From: Vinayak Hegde <[email-masked]>
Date: Thu, 7 Nov 2013 19:48:04 +0530

There is Unison[1] which can sync across computers across networks and
across OSes (Windows ,Linux, etc). It is open-source (GPL-licensed ) and
trivial to setup. The transfer connections can be tunneled over encrypted
SSH.

I have been using it for a while and it works well for the set of
requirements you have noted.

-- Vinayak

1. http://www.cis.upenn.edu/~bcpierce/unison/

On Thu, Nov 7, 2013 at 6:31 PM, Eggert, Lars <[email-masked]> wrote:

> > 5.  Many insecure protocols are used in the Internet today, and the IETF
> should create a secure alternative for the popular ones.
>
> SNIA's CDMI (http://www.snia.org/cdmi) could be useful, and on the IETF
> side we have of course WebDAV.
>
> isn't because there aren't any open protocols available to build them with,
> it's that the proprietary services have polished clients that are simple to
> set up, available for many clients, and that they have a robust and
> well-managed backend. There's not much the IETF can do about these factors.
>
> In the specific case of DropBox clones, several vendors of storage systems
> (incl. my employer) are making or will shortly be making mobile clients
> available that use said storage systems as a backend instead of the public
> cloud. So at least for that particular application, there are alternatives
> available.
>
> Lars
>
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 7 Nov 2013 14:37:58 +0000

On 07 Nov 2013, at 6:18, Vinayak Hegde <[email-masked]> wrote:
> There is Unison[1] which can sync across computers across networks and across OSes (Windows ,Linux, etc). It is open-source (GPL-licensed ) and trivial to setup. The transfer connections can be tunneled over encrypted SSH.
> 
> I have been using it for a while and it works well for the set of requirements you have noted.

Yup, but there is no phone/tablet support AFAIK. User desire to access their content on such devices is where DropBox and other services shine.

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Nov 2013 06:29:23 -0800

The IETF is the wrong place to go about design, so here goes.

It seems to me that S/MIME already has the functionality of a dropbox
scheme. What is lacking is what the usability folk call the 'affordance' of
being used in a dropbox fashion and well, usability.

Further, for such a scheme to become widely used it will be better if the
scheme is a protocol that can be supported by existing service providers as
an extension to their current offerings rather than a completely new scheme
that attempts to disintermediate them.

There are two separable forms of authentication required in such a scheme.
First we have the the access controls to the remote mailbox, second we have
the cryptographic controls on the data. My bits may b encrypted but that
does not mean that I want just anyone to view them. And even encrypted bits
typically leak some metadata.

* The recipient will need a public key against which senders can encrypt
their data.

* Senders will require a mechanism that assures them they are using the
correct key. If the parties know each other, a 'strong email address' would
be sufficient, that is a fingerprint of the public key combined with the
destination email address. If the parties do not know each other, a Trusted
Third Party (or parties) will be required to provide an introduction.

* The mailbox provider can map the key identifier to the public key if
necessary.