On Sun, 27 Oct 2013 20:47:14 +
Tobias Gondrom wrote:
The draft I am working on does not really cover this. It is very specifically
about making encrypted email practical in a general sense concerning solving
the 'encrypted email cannot be spam filtered' and similar problems, regardless
of
* Tobias Gondrom wrote:
>The widespread use case of zero-footprint clients, aka webmail:
>if you have no client / your client is a browser window for webmail, you
>have to upload your private key to the server (and must store it there).
>I.e. you would upload your private key to Google and other ma
would at the same time
also retain full access to emails received on full-clients. So while
this might help us against spam, we might in the end not be much better
off against pervasive state-driven surveillance. Or am I missing something?
Best regards, Tobias
Re: [perpass] A proposal for devel
> That is handled by the underlying program you are using to encrypt
> your mail, and so has nothng to do with this proposal directly - it's
> implementation dependent. Out of scope.
I agree that this problem is out of scope, but it is very important
nonetheless. Every time someone hits upon a
The subject is not out of scope if you decide to store the private key blob
in the cloud...
That looks to me like it might be the answer in some cases. I would rather
guarantee that the blob is strongly encrypted and can't be lost than have
the user export them to a USB stick under a weak password
On 10/15/2013 08:46 PM, Mike Demmers wrote:
> On Tue, 15 Oct 2013 17:37:54 -0700 Leo Vegoda
> wrote:
>
>>> They get backed up when they back up their system.
>>
>> You seem to have ignored the word "securely" in that sentence. And
>> anyway, most people don't backup their systems at all.
>
> H
On Tue, 15 Oct 2013 17:37:54 -0700
Leo Vegoda wrote:
> > They get backed up when they back up their system.
>
> You seem to have ignored the word "securely" in that sentence. And
> anyway, most people don't backup their systems at all.
Here is, I hope, a better answer to your question 'How a
On Wed, 16 Oct 2013 02:09:31 +0100
Stephen Farrell wrote:
> On 10/16/2013 01:37 AM, Leo Vegoda wrote:
> > Have you considered documenting your thoughts in a less
> > conversational style?
>
> Good suggestion. And there's time before the I-D
> cutoff too. [1]
You mean, write a draft?
I am new
On 10/16/2013 01:37 AM, Leo Vegoda wrote:
> Have you considered documenting your thoughts in a less
> conversational style?
Good suggestion. And there's time before the I-D
cutoff too. [1]
S.
[1] https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
___
On Mon, Oct 14, 2013 at 04:09:06PM -0700, Mike Demmers wrote:
[...]
> > - how do people securely backup their keys?
>
> They get backed up when they back up their system.
You seem to have ignored the word "securely" in that sentence. And
anyway, most people don't backup their systems at all.
On Sun, 13 Oct 2013 08:25:08 -0700
Leo Vegoda wrote:
> I am not a security expert either but presumably people will need to
> export keys for backup and deployment on other systems. For
> instance, many people have something like a laptop computer, a
> smartphone and a tablet. Presumably, users w
On Sat, Oct 12, 2013 at 11:45:00PM -0700, Mike Demmers wrote:
> On Sat, 12 Oct 2013 19:03:44 +0100
> Leo Vegoda wrote:
>
> > How is key management handled?
>
> Ok, first I want to summarize again, incorporating the changes made after
> Bjoern's commants.
>
> We are now looking at a two level k
On Sat, 12 Oct 2013 19:03:44 +0100
Leo Vegoda wrote:
> How is key management handled?
Ok, first I want to summarize again, incorporating the changes made after
Bjoern's commants.
We are now looking at a two level key exchange, one with a 'public' public key,
and a second with a 'private' publ
On Thu, Oct 10, 2013 at 09:25:04AM -0700, Mike Demmers wrote:
[...]
> How about this:
>
> There are two new standard buttons on the MUA: FRIEND UNFRIEND
>
> Everything possible is set up by the MUA when it is first run - keys, made,
> if they do not exist, questions asked and answered about ke
On Thu, 10 Oct 2013 14:44:45 +0200
Bjoern Hoehrmann wrote:
> Back in the day it did not seem unusual for people to know about things
> like anonymous remailers or how trivial it is to manually deliver mails
> by typing SMTP commands into a console, including spoofing various bits
> of header data
* Mike Demmers wrote:
>If using default deny for encrypted email, they would simply have to
>first send you a non-encrypted email that said something like "I would
>like to exchange email with you confidentially and have added your
>address to my 'allow' list, would you add me to yours?"
>
>Woul
On Thu, 10 Oct 2013 00:00:31 +0200
Bjoern Hoehrmann wrote:
> * Mike Demmers wrote:
> >TThe basic concept of default deny for encrypted emails only seems very
> >'right' to
> >me, because if you are going to the trouble to do this, and handle things
> >like
> >key exchanges, that communication m
* Mike Demmers wrote:
>TThe basic concept of default deny for encrypted emails only seems very
>'right' to
>me, because if you are going to the trouble to do this, and handle things like
>key exchanges, that communication must be pretty special to begin with. Why
>would
>you want 'just anyone' to
Some more thoughts on default deny for encrypted email.
(Sorry about the length, I am known for that).
I am interested in this because I think Ned has it exactly right:
Users are simply not going to put up with encryption that results in (from what
I see on my servers) 100 times or more the amo
19 matches
Mail list logo
