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

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 14:44:47 +0100

Hi all,

All this "HTTPS everywhere" mail collided for me this morning with a similar avalanche of press about Facebook's freshly-announced use of PGP:

https://www.facebook.com/notes/protecting-the-graph/securing-email-communications-from-facebook/1611941762379302

Mail to public mailing lists can already be signed (like this one is). It'd be nice if mailman didn't MITM the signed content, so that the signature can be validated. (Perhaps it will; I will find out after I hit send.) There's lots of other mail from individuals to closed groups like the IAB and the IESG and from IETF robots to individuals that *could* be encrypted, or at least signed. There is work here that *could* be done.

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.

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.

Joe

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 2 Jun 2015 13:55:30 +0000

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Joe Abley
> Sent: Tuesday, June 02, 2015 9:45 AM
> To: IETF Discussion Mailing List
> Subject: Proposed Proposed Statement on e-mail encryption at the IETF
> 
> Hi all,
> 
> All this "HTTPS everywhere" mail collided for me this morning with a similar
> avalanche of press about Facebook's freshly-announced use of PGP:
> 
> https://www.facebook.com/notes/protecting-the-graph/securing-email-
> communications-from-facebook/1611941762379302
> 
> Mail to public mailing lists can already be signed (like this one is). It'd be nice if
> mailman didn't MITM the signed content, so that the signature can be
> validated. (Perhaps it will; I will find out after I hit send.) There's lots of other
> mail from individuals to closed groups like the IAB and the IESG and from IETF
> robots to individuals that *could* be encrypted, or at least signed. There is
> work here that *could* be done.
> 
> 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.
> 
> 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.
> 
> 
> Joe

Are the IETF mail servers configured to use opportunistic TLS? I haven't checked. To me this would be a good first step down the mail encryption path.

Mike

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Jun 2015 10:07:18 -0400

Joe:

Some mail lists are configures to add a suffix to the message.  Others, like this one, do not.

Adding a suffix changes the content, and that action is guaranteed to break a signature.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Tue, 2 Jun 2015 17:10:36 +0300

Server-to-server TLS would indeed be a useful thing to have been turned on.
We will find out what the situation is. Stay tuned.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 15:11:35 +0100

Hiya,

On 02/06/15 14:44, Joe Abley wrote:
> Hi all,
> 
> All this "HTTPS everywhere" mail collided for me this morning with a
> similar avalanche of press about Facebook's freshly-announced use of
> PGP:
> 
>  Mail to public mailing lists can already be signed (like this one
> is). It'd be nice if mailman didn't MITM the signed content, so that
> the signature can be validated. (Perhaps it will; I will find out
> after I hit send.) 

A lot of signatures do survive our lists. I think most bad
PGP signatures I see on IETF mail happen when someone forwards
or quotes and my MUA tries to be a bit too clever. Most s/mime
signatures seem to show as bad, I suspect because they chain
up to an enterprise CA, but I've not checked.

Someone with interest could do a study about that that'd be
interesting and informative. (Hint for anyone with cycles
and interest:-) One could even imagine creating a useful
database of public keys used by IETFers and automating the
refresh of that. If there were such a thing that fed into
engimail/gpg or the s/mime support in common MUAs that'd
be excellent.

> There's lots of other mail from individuals to
> closed groups like the IAB and the IESG and from IETF robots to
> individuals that *could* be encrypted, or at least signed. There is
> encrypted e-mail whenever possible ought to be similarly reasonable.

I think that's not unreasonable but has additional barriers to
being tractable. In particular, in my case, I'd need to ensure
I could decrypt email on multiple devices (I currently just do
that on one) and I'd want (but probably not have) a way to mirror
information I store on public keys across those devices too. I
think that's all doable for me, but it'd be a bit of work.

I doubt I'm alone in either of those respects.

I'd also wonder if MUAs would be up to handling all the kinds of
forwarding we do, but that's something it'd be useful to find
out.

> Given that so much of the work of the IETF happens over e-mail, a
> focus on HTTP seems a bit weird.

Well, putting the initial focus on HTTP(S) is probably correct
given that we can more easily do more there, but if you read the
proposed statement it does say that it applies across the board
(modulo pragmatism of course).

> 
> 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.

We have a list for such discussion [1] if folks feel the need.
And I know PHB has an interesting idea to try to merge the two
in terms of message formats. I'm not sure that's feasible but
discuss on [1] if you feel the need. And please don't have that
discussion here unless there's a reason for it to be here and
not there:-)

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/endymail

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 2 Jun 2015 10:22:20 -0400

From: [email-masked]
To: [email-masked]
Subject: RE: Proposed Proposed Statement on e-mail encryption at the IETF
Date: Tue, 2 Jun 2015 10:02:55 -0400

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Subject: RE: Proposed Proposed Statement on e-mail encryption at the IETF
> Date: Tue, 2 Jun 2015 13:55:30 +0000
> 
> 
Yes. I just checked. mail.ietf.org supports STARTTLS with a quite good configuration (TLS 1.2, forward secrecy, and AEAD). Xiaoyin

---

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 2 Jun 2015 10:22:45 -0400

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 15:29:00 +0100

Hi Russ,

> Some mail lists are configures to add a suffix to the message.  Others, like this one, do not.

Yep, I'm aware of why it happens. My point was more that there is at least the potential for some work to be done on the IETF end, not just on the IETF participant end, which suggests that some kind of decision from leadership could be useful.

> Adding a suffix changes the content, and that action is guaranteed to break a signature.

Sure, unless the suffix is added in a separate, unsigned MIME section, which is behaviour I have seen on some lists (my mail client shows me a signed section in the mail, and gives me a warning that not all of the message is signed).

Joe

---

From: Hector Santos <[email-masked]>
Date: Tue, 2 Jun 2015 10:40:55 -0400

> On Jun 2, 2015, at 9:44 AM, Joe Abley <[email-masked]> wrote:
> 
> Hi all,
> 

You should see the convolution being developed with DKIM V1/V2 Dual Signatures;  V1 strong on the first path leg (submission), a new V2 weaker derivative on the second path (mailing list distribution).  Why?  Mail folks wanting to avoid the DNS folks (requirements) for the most part. 

Rhetorically , Whats the point about worrying about anything security related when we break our own protocols and seem more interested in fast tracking less quality work, albeit pertinent  to some market leader but not as a IETF community whole work?  

> 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 re…

It does seems weird.  if you in a market where it is required, i.e. PCI,  some applications do need it to be out of the box.  But not all applications and data exchanges need this overhead and there remains many legacy markets, mission critical too, that are not able to implement it, especially on the client side. It's a market niche for my company.

> 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.

Thanks for the laugh. 

--
Hector Santos
http://www.santronics.comi

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Jun 2015 10:59:09 -0400

> discussion here unless there's a reason for it to be here and

Actually merge the two as far as the user is aware.

Obviously, the more components are shared, the easier things become for
implementations. But adding message formats is not the hard part. I'll
probably have something for endymail next week.

The bigger issue for me is 'mailing list'. I can easily write a protocol
for an end to end secure collaborative forum as a Web Service but there is
no way that I expect to do anything useful with legacy SMTP infrastructure
as the transport.

SMTP sucks as a mailing list protocol.

What we need is a return to something that is a bit more like NNTP which
began life as an attempt to make mailing list interactions more efficient.

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 16:01:59 +0100

> no way that I expect to do anything useful with legacy SMTP 

For what it's worth, the lists where I see encryption happening right 
now publish a public key for the list address and make the corresponding 
private key available to the mailing list software, which encrypts 
towards individual participants. So it's not end-to-end, it requires 
some centralised key management and the plain text of any encrypted 
message is exposed on the mailing list server.

Joe

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 2 Jun 2015 17:24:32 +0200

> 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 re…

++; 

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 ...

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2015 16:47:49 -0000

>Mail to public mailing lists can already be signed (like this one is). It'd be nice if mailman didn't MITM the signed content, so that the signature can be validated.

The last time I checked, Mailman is pretty good about wrapping MIME parts when it
adds a header or footer, so if you send multipart/signed, that will be part of
the resulting message.

I also found that the way MUAs treat partially signed mail ranges from
mediocre (Thunderbird) to bad (Outlook and Alpine) to nonexistent (all
of the usual web mail.)

But I have to ask, what problem are we trying to solve?  The issues
here are roughly the same as the ones that came up when we were
designing DKIM, and some people insisted that mailing lists had to
preserve DKIM signatures.  (This was before last year's DMARC fiasco.)

As far as I could tell, the threat model was that bad guys were
flooding lists with forged mail, list operators were asleep at the
switch and did nothing about it, so recipients had to do retroactive
spam filtering.  While everyone agreed this model was silly, nobody
could come up with anything else other than to insist that it was
obvious which to me, at least, it was and is not.

There is a fairly popular list manager called Sympa which can
apparently do end to end S/MIME.  Contributors can provide an S/MIME
key when they sign up, it can verify signatures on the way in and
derypt mail encrypted to the list's key, then re-encrypt mail to each
recipient's key.  I say apparently because it's in the code and the
manual, but I can't find anyone who actually uses it so I don't know
if it works.

I wouldn't suggest the IETF switch from Mailman to Sympa, but if
people are interested in some code sprintage, they might hack on
Mailman to provide a way for subscribers to register S/MIME and PGP
keys, check signatures on the way in and annotate the mail to say what
it found.  We already do DKIM signatures on the way out which should
be adequate to protect the annotations.  Then once we see how that
works, we might add features to reject or at least make insulting
comments on unsigned mail from people who've provided keys.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2015 16:53:55 -0000

>We will find out what the situation is. Stay tuned.

According to my mail logs, all my mail from the IETF arrives via IPv6,
negotiates a TLS1.2 connection, and the messages are DKIM signed.

I think that's about the best we can hope for.  Well done.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jun 2015 10:15:54 -0700

Ignoring the "signed" part...

> 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 re…

This is a terrible idea. If the IETF mailer thinks it knows my PGP encryption key, and I don't because I have lost it or invalidated it, then I cannot read the mail from the IETF mailer and will thus lose valuable information. Maybe we can develop some interface that allows a user to specify their encryption key and remove it at will, but I've never seen such an interface before and suspect that its design will have all sorts of pointy edge cases.

Proposal: if you actually want this, develop an interface for telling the server your key first. Get buy-in from others active in the IETF, if possible. If you can pull this off, it will benefit much more than the IETF.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 12:48:32 -0500

On Tue, Jun 02, 2015 at 10:15:54AM -0700, Paul Hoffman wrote:
> > 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.

There's no point to encrypting (to subscribers) posts to *public*
mailing lists!

There's also no point to doing anything more than DKIM as far as the
mailing list processor goes.

Users should be (and are) able to sign their posts if they like, but I
don't think there's much point to requiring them to.

As to SMTP, see below.

> This is a terrible idea. If the IETF mailer thinks it knows my PGP
> encryption key, and I don't because I have lost it or invalidated it,
> [...]

I agree, but SMTP should still get confidentiality protection,
opportunistically and with DANE.  The reason for this being that sending
MTAs can't know whether some message they are transmitting is going to a
public list -- they must assume that confidentiality is desired in SMTP.

MUAs should also demand confidentiality in SUBMIT, of course.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Jun 2015 12:59:07 -0500

> > e-mail, a focus on HTTP seems a bit weird.

There is no point to PGP encryption when posting to *public* mailing
lists, not even if done by the list processor (which is the only way
that makes sense).

SMTP, however, should use TLS, opportunistically or with DANE, as they
don't know whether a destination of a message they are transmitting is
a public list.

MUAs really must use TLS for SUBMIT as well.

> encryption key, and I don't because I have lost it or invalidated it,

Yes, but if we limit this to just SMTP, of course the ietf.org MTAs
should support TLS, and they should have TLSA RRs for DANE.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Jun 2015 14:03:24 -0400

On Tue, Jun 2, 2015 at 1:15 PM, Paul Hoffman <[email-masked]> wrote:

> encryption key, and I don't because I have lost it or invalidated it, then
> I cannot read the mail from the IETF mailer and will thus lose valuable
> information. Maybe we can develop some interface that allows a user to
> specify their encryption key and remove it at will, but I've never seen
> such an interface before and suspect that its design will have all sorts of
> pointy edge cases.
>
> Proposal: if you actually want this, develop an interface for telling the
> server your key first. Get buy-in from others active in the IETF, if
> possible. If you can pull this off, it will benefit much more than the IETF.
>

Well I think the original point here is 'eat the dog food' and you are now
pointing out that the dog food is inedible. Which is of course correct.

The problem I find with both S/MIME and OpenPGP is they both lack a
mechanism for receivers to tell senders

1) Whether they want encrypted mail

2) Which encryption key to use.

The first is really important for me because IETF mailing lists are all
public and I read them using the gmail webmail interface. I have absolutely
no interest in having email sent in a format that I can't read on my device
and no interest in using a different device for no other reason than to
support end-to-end encryption of public data.

I want to be able to read my IETF mail on every one of the machines I use
on a daily basis, these are three desktops, two laptops, a phone and a
tablet. Unless I can read my IETF mail on all seven platforms, it is not
going to be acceptable.

The second is important for a similar reason. OpenPGP and S/MIME are NOT
end-to-end email encryption systems. they are systems that give the OPTION
of end-to-end. That is not an option I want to make available to people
that I have not vetted previously by which I mean 'have whitelisted them'.
to do otherwise is an invitation to be spammed to death.

Now I can demonstrate ways to make whitelisting really easy and automatic.
But there is going to have to be a fallback which is either 'plaintext' or
encrypt under some non-end-to-end key.

So yes, let us make encrypting email end-to-end an eat the dog food goal,
but the point of eating the dog food is to make sure it is edible, not to
prove that we are masochists.

Like virtually every other IETF protocol there is a little bit of missing
glue which is the bit where someone can specify what their security policy
is. That is the little bit extra I would like to add in a format that makes
it usable for both S/MIME and OpenPGP.

And now I am going back to working on adding it.

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 19:11:03 +0100

> There's no point to encrypting (to subscribers) posts to *public*

Yes, I know. Hence "wherever possible". If you have an expectation that 
the contents of e-mail conversations are public (e.g. in archives) then 
that's not possible. So that's not what I am talking about.

> mailing list processor goes.

Sure.

> don't think there's much point to requiring them to.

All agreed.

Perhaps you didn't read my original e-mail, and are just responding to 
quoted fragments of it; I was talking about all the e-mail that doesn't 
involve public lists. The example I gave was based on an imagined desire 
of someone to say something to the IAB as a closed group, not on a 
public list, and desiring some privacy in their communications. There 
are surely other examples.

Joe

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 19:08:15 +0100

On 2 Jun 2015, at 18:15, Paul Hoffman wrote:

> then I cannot read the mail from the IETF mailer and will thus lose 
> valuable information.

Right. So let's not do that.

> Maybe we can develop some interface that allows a user to specify 
> their encryption key and remove it at will, but I've never seen such 
> an interface before and suspect that its design will have all sorts of 
> pointy edge cases.

I can think of lots of interfaces that let users specify settings for a 
particular service. Mailman is surely one of them. Again, I'm not 
talking about encrypting public list traffic, but it seems like a fair 
bet that anybody who wants to exchange non-public-list traffic with the 
IETF has a mailman account already.

And before anybody jumps on that particular idea, it's just an example. 
I may be the only one, but I'm actually not trying to design a solution 
here, just suggesting that e-mail not be overlooked as we look for ways 
to s/mouth/money/ when it comes to privacy.

> Proposal: if you actually want this, develop an interface for telling 
> the server your key first. Get buy-in from others active in the IETF, 
> if possible. If you can pull this off, it will benefit much more than 
> the IETF.

I don't think anybody wants *me* to develop anything :-)

But agreed, if the IETF was able to show that its work conducted by 
e-mail could incorporate cryptography in such a way that it was a 
benefit to all concerned rather than a headache, I think that would be 
great.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Jun 2015 11:12:01 -0700

On Jun 2, 2015, at 11:03 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> Well I think the original point here is 'eat the dog food'

We fully disagree that that was the "original point". The original point was that encrypted email from the IETF is good. Joe specifically requested that we not get into a dogfood discussion so that he doesn't fall off his chair.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 02 Jun 2015 18:59:30 +0100

Sure.

All agreed.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Jun 2015 14:40:05 -0400 (EDT)

> Proposal: if you actually want this, develop an interface for telling the server your key first. Get buy-in from others active in the IETF, if possible. If you can pull this off, it will benefit mu…

IETF could run openpgpkey-milter (or successor) to do exactly that.

Paul

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 2 Jun 2015 22:11:14 +0200

Subject: Re: Proposed Proposed Statement on e-mail encryption at the IETF Date: Tue, Jun 02, 2015 at 07:08:15PM +0100 Quoting Joe Abley ([email-masked]):
 
> benefit to all concerned rather than a headache, I think that would
> be great.

I think we have achieved this in one way; we now accept and deliver
e-mail via SMTP using TLS. Everyone should do this, as long as they
don't risk ending up in jail for doing it. (for those cases and for
RFC 854 debugging, we keep the downgrade option. Reluctantly. Building
an interceptor that strips the TLS offers from the SMTP dialogue and
effects a downgrade attack is trivial. More often than not this device is
"the firewall". QED.)

Another way we've dogfooded in this area is by signing email. (And that
might be done via any of the unuseable protocols. I pretend I don't care,
to keep Joe on his chair.)  There are operational, direct advantages
from signing email today.  Everyone who some day might want to send a
sensitive e-mail over any network ought to think very hard about climbing
on the mechanical bull known as "getting PGP to work in my email setup
(and with some security at that)." Signed email is not "au contraire" to
the open nature of IETF lists. It serves as verification and reassurement.

I somewhat keep repeating myself.  But we can do, and actually do,
this, today. Now, getting DANE data for the IETF SMTP TLS certs going,
and perhaps working on fetching that data into the validation process
of some well-known MUAs, that would be a good step.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I am a traffic light, and Alan Ginzberg kidnapped my laundry in 1927!

---

From: Matt Mathis <[email-masked]>
Date: Tue, 2 Jun 2015 14:50:07 -0700

BTW you can see encryption stats here:
https://www.google.com/transparencyreport/saferemail/?hl=en#search=ietf.org
 .

Or for that matter, look up your own favorite domains.   The per region
stats are pretty alarming.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Tue, Jun 2, 2015 at 1:11 PM, Måns Nilsson <[email-masked]>
wrote:

> Subject: Re: Proposed Proposed Statement on e-mail encryption at the IETF
> Date: Tue, Jun 02, 2015 at 07:08:15PM +0100 Quoting Joe Abley (
> [email-masked]):
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Jun 2015 13:22:01 +1200

On 03/06/2015 03:24, Måns Nilsson wrote:
...
> /Måns, signing all outgoing e-mail. If e-mail from me is not signed,

In some contexts, that really matters. In the IETF where all discussion
is public and we don't count votes, it's the technical content of the
message that really matters. With all due respect, if a message
purporting to be from Måns Nilsson is technically correct but happens
to be forged, it doesn't really matter: it's the content that counts.

Of course that argument doesn't apply to forged consensus calls
that are not really from WG Chairs, or forged IESG Statements, etc. So
I'm not saying that signing is a bad thing (er, must look into
enigmail). Just that we should not let it blind us to what we are
doing here.

     Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jun 2015 07:46:31 -0400

On Tue, Jun 2, 2015 at 2:12 PM, Paul Hoffman <[email-masked]> wrote:

> We fully disagree that that was the "original point". The original point
> was that encrypted email from the IETF is good. Joe specifically requested
> that we not get into a dogfood discussion so that he doesn't fall off his
> chair.
>
> --Paul Hoffman

What he actually did was ask us not to have an S/MIME vs OpenPGP editor
war. Which is fine as neither works well enough.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jun 2015 09:41:48 -0400

> should support TLS, and they should have TLSA RRs for DANE.

The ietf.org MTA does support TLS:
wkumari$ dig +short MX ietf.org
0 mail.ietf.org.
wkumari$ echo -e 'EHLO example.com\nquit' | nc mail.ietf.org 25 | grep START
250-STARTTLS

There also is a DANE record:

wkumari$ dig +short TLSA _25._tcp.mail.ietf.org
3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B566 64C5D3D6

(thanks to Glen and Matt for having set this up, and Viktor for all of
his work helping with the TLSA record and getting DANE support into
Postfix)

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Hector Santos <[email-masked]>
Date: Wed, 03 Jun 2015 15:14:14 -0400

On 6/2/2015 11:24 AM, Måns Nilsson wrote:
> 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. 

But if you are not signing the mail yourself, its already "fishy." Or 
do you mean sign by some trusted 3rd party and wish for others to 
trust as well?

--
HLS

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 3 Jun 2015 22:01:20 +0200

Subject: Re: Proposed Proposed Statement on e-mail encryption at the IETF Date: Wed, Jun 03, 2015 at 03:14:14PM -0400 Quoting Hector Santos ([email-masked]):
> But if you are not signing the mail yourself, its already "fishy."
> Or do you mean sign by some trusted 3rd party and wish for others to
> trust as well?

I'm sorry. I perhaps was unclear. I'm suggesting that people sign what
they send. Not that some middleware identity like a mail list manager
software does it.  The fact that whatever I am  is  signing every mail
supposedly coming from me simply is an indication that the same individual
did originate these messages. Nothing more than that, and that does not,
by itself, look like much, but there are enough benefits in doing that,
not only for me (I'm not likely to forget my pass-phrase if I'm using
it all the time)  but for others -- they for instance can filter on my
signature for whatever purpose they see fit. Including filing to the
loonies folder.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Everybody is going somewhere!!  It's probably a garage sale or a
disaster Movie!!

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Jun 2015 03:45:08 -0400

- --On Wednesday, June 03, 2015 15:14 -0400 Hector Santos
<[email-masked]> wrote:

>> 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. 
> 
> But if you are not signing the mail yourself, its already
> "fishy." Or do you mean sign by some trusted 3rd party and
> wish for others to trust as well?

Hector, I assume he meant "signed by some mechanism, including
key
certification, that most recipients would have reason to trust".
Now that
raises a lot of issues, some of which interact with claims that
HTTPS
provides significant data integrity protection.    I wish that,
at least as
a demonstration matter, more MUAs made it easy to create a
security-based
whitelist for incoming mail to particular mailbox or folders,
e.g., to
reject anything that was not signed in a key that was either
stored and
certified locally or that was certified by a CA that the user
had chosen to
trust.  In addition to allowing some noise-free (as well as
merely
spam-free) folders, it would help the broader community
understand the
limitations of such approaches.  For example, we could not use
it for the
IETF list and preserve the position that anyone could post and
that
pseudononymous postings were ok.

I also note that "PGP key signing parties" used to be a regular
feature at
almost every IETF meeting.  If we were serious about secure
communications
(not just email) within the IETF community, we would reinstitute
those,
review signing criteria and create some guidelines, and make
sure we could
get X.509 certs issued/signed too, if necessary in an IETF or
ISOC tree.

If we were trying to make good demonstrations for the wider
community, we
would move in those sorts of directions.  We might also pick up
on Måns's
"if it isn't signed, it isn't from me" assertion and modify our
various
protocols for domain-based assertions about mail to allow "if
something
claims to come from this domail and its content isn't digitally
signed
using method X, it is bogus" assertions.

Lots of things we could be doing.   Or we can contribute to the
repertoire
of security theater and make our lives harder in the process.

regards,
   john

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 04 Jun 2015 16:10:04 -0400

> get X.509 certs issued/signed too, if necessary in an IETF or

For what it's worth, I am willing to volunteer for this. If there's a 
room and a timeslot available, I could do it in Prague, even. I've done 
lots of these in the past (although none at the IETF).

I believe I am (still) a CACert assurer of some kind, too, although it 
has been long enough since I've done anything with that that I would 
need a refresh (both on the procedures and documentation required, and 
on current interest CACert) to incorporate that into the mix.

While we're getting ahead of ourselves, if there was an ISOC or IETF CA 
that was fed and watered sufficiently well that it was worth using in 
some glorious future, incorporating that (them) seems like a lovely idea 
too.

Rewinding to reality, perhaps there are other PGP and/or CACert 
enthusiasts who would like to join in and talk about at least some level 
of PGP fumbling in Prague.

Joe

---

From: Glen <[email-masked]>
Date: Thu, 4 Jun 2015 14:10:36 -0700

> Rewinding to reality, perhaps there are other PGP and/or CACert
enthusiasts who would like to join in and talk about at least some level of
PGP fumbling in Prague.

Since I'm more-or-less technically a "vendor" for the IETF, I try to stay
out of the way as much as possible.

But I have a deep passion for encryption, and especially email encryption.

So perhaps in my role as "keeper of the [email-masked] PGP key", I will
be permitted to sneak past my vendor status this one time, and participate
in your key signing party in Prague?  I would love to attend.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)