ietf
[Top] [All Lists]

Re: Proposed Proposed Statement on e-mail encryption at the IETF

2015-06-02 10:25:00
Subject: Proposed Proposed Statement on e-mail encryption at the IETF Date: 
Tue, Jun 02, 2015 at 02:44:47PM +0100 Quoting Joe Abley 
(jabley(_at_)hopcount(_dot_)ca):

If the argument that we should use HTTPS everywhere (which I do not disagree 
with) is reasonable, it feels like an argument about sending encrypted e-mail 
whenever possible ought to be similarly reasonable. Given that so much of the 
work of the IETF happens over e-mail, a focus on HTTP seems a bit weird.

++; 

Your e-mail validates perfectly fine. While it does not provide
confidentiality, signing all outgoing e-mail is an excellent dogfooding
mode with immediate benefits;

- You get to build a word-of-mouth cache of keys, 

- Your signing infrastructure gets used, a very good way of keeping it 
  up-to-date, 

- You can with really minor effort upgrade to encrypting email using
  the same cache of keys,

- The multipart MIME signature model works quite nice with mailing lists, 
  as long as one's got a good client. 

- etc. But the major point is keeping things running and current. I've had
  to, on several occasions, wait for people to dig out or regenerate keys,
  or complain over losing private keys/passwords simply because they once
  made the effort to get a key and then bit-rot set in from under-usage.
 
Note that this is not an attempt to start a conversation about whether
PGP is usable, or whether S/MIME is better. I will fall off my chair in
surprise if it doesn't turn into one, though.

The above benefits of signing apply roughly equally well to both methods. 

/Måns, signing all outgoing e-mail. If e-mail from me is not signed,
 something is fishy.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I'm thinking about DIGITAL READ-OUT systems and computer-generated
IMAGE FORMATIONS ...

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>