Subject: [perpass] e-mail security idea: server2server PGP

From: Noel Torres <[email-masked]>
Date: Wed, 23 Oct 2013 19:13:37 +0100

Hi all

I think it would be possible, and even easy for the developers, to 
program an extension to SMTP in which servers use OpenPGP among them, 
independently of any TLS/SSL usage.

Why: It helps stopping spam because the receiver server can trust the 
identity of the sender, and it helps avoiding wiretapping.

This idea I have developed does not help with the Government asking the 
mail provider directly for the e-mail contents, but helps with 
eavesdropping and also with spam, as I said.

Are you interested in reading about it?

Regards

Noel Torres
er Envite

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Oct 2013 14:18:03 -0400 (EDT)

On Wed, 23 Oct 2013, Noel Torres wrote:

> I think it would be possible, and even easy for the developers, to program an 
> extension to SMTP in which servers use OpenPGP among them, independently of 
> any TLS/SSL usage.

That's the point of:

http://tools.ietf.org/html/draft-wouters-dane-openpgp-01

It allows the mail client, or MUA, or MTA, to encrypt a message
during transport.

Commenting on the draft in one of the IETF lists (openpgp, dane or here)
would be useful to show support for this moving forward.

A sendmail/postfix milter implementation is planned.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Oct 2013 14:18:40 -0400

> identity of the sender, and it helps avoiding wiretapping.

Please explain it's superiority over DKIM and SPF and DMARC.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Noel Torres <[email-masked]>
Date: Wed, 23 Oct 2013 19:34:30 +0100

> Please explain it's superiority over DKIM and SPF and DMARC.
Hi Dave

In short, DKIM does not avoid wiretapping on itself, SPF does not, 
either, nor DMARC.

My idea is that server2server communication is signed and ecrypted using 
OpenPGP (which can be done on the fly without great changes to current 
Internet structure). e-mails with bad server signature will be rejected 
before they are transmitted, so we save bandwidth.

Servers will trust other server signatures on a "configured by the 
administrator" basis, so Alice, as Admin of Alice.com, chooses to trust 
Bob.com's key to sign Charles.com key as valid, like in the standard GPG 
Web of Trust. Keys that are not specifically accepted nor signed by a 
trusted party, will cause e-mail to be accepted but marked as 
non-trustable (maybe directly as spam).

I have also developed how it could work on the wire, with a simple 
extension to current SMTP.

Regards

Noel
er Envite

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Oct 2013 14:44:06 -0400

> In short, DKIM does not avoid wiretapping on itself, SPF does not,

You cited the benefit you are seeking as trusting who the 'sender' was. 
  That's an authentication/signature task, not a 
confidentiality/encryption task.

d/

ps. the mere fact of authentication does not vet the trustworthiness of 
the validated identity.

---

From: Noel Torres <[email-masked]>
Date: Wed, 23 Oct 2013 19:56:27 +0100

On 23/10/13 19:44, Dave Crocker wrote:
[...]
Hi Dave

I said that my idea would achieve both authentication and confidentiality.
 > ps. the mere fact of authentication does not vet the trustworthiness of
It depends on the configuration and contents of the Web of Trust.

Regards

Noel
er Envite

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 23 Oct 2013 12:13:51 -0700

> In short, DKIM does not avoid wiretapping on itself, SPF does not, 

Except that we already have STARTTLS... How is this better than
DKIM/SPF/DMARC and STARTTLS?

And don't say it means that spam will be encrypted, because you (and the
spammer) don't care about encryption of a spam message, and any real
email (w/ a valid DKIM, etc) will be sent wrapped in STARTTLS...

And the advantage of STARTTLS is that it only now needs simple
configuration as opposed to having to install a new milter and gpg,
etc...

This doesn't prevent MITM attacks, but w/ DNSSEC + DANE, it could be
addressed...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Oct 2013 14:24:07 -0400

> identity of the sender, and it helps avoiding wiretapping.

No, it doesn't, because you are assuming some kind of trust model which does
not exist.

DKIM can already sign emails, and it's the signing that adds trust for the
sender.

There have been PGP encrypting sendmail plugins for years (decades?)... the
problem is finding and trusting the keys.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Oct 2013 12:47:21 -0700

On Oct 23, 2013, at 11:44 AM, Dave Crocker <[email-masked]> wrote:

> You cited the benefit you are seeking as trusting who the 'sender' was.  That's an authentication/signature task, not a confidentiality/encryption task.
> 
> d/
> 
> ps. the mere fact of authentication does not vet the trustworthiness of the validated identity.

Dear Dave,

As you know, DKIM can not authenticate the sender.  DKIM authenticates some unseen domain signed a portion of the message.  DKIM does not confirm the signing domain intended to send the message to the recipient either.  Nor does DKIM ensure valid message structure where acceptance on the basis of trusted DKIM signatures can be hazardous, contrary to the process described in the DKIM deployment RFC.  In addition, because DKIM can not authenticate the sender, it can never abate email abuse either, nor was that ever described as a supported feature.

StartTLS is not affected by message structure and indicates the intended recipient as well as identifying an accountable sender. StartTLS offers a safe basis for trust, reputation, and acceptance.  DKIM in conjunction with DMARC has very limited applicability and only prevents From header field spoofing but even then allows click-able links to be injected into a spoofed Subject header field.

Regards,
Douglas Otis

ps. DKIM authentication does not vet the message nor the trustworthiness of the signing domain.  DKIM does not validate any identity either.

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 23 Oct 2013 13:02:27 -0700

> As you know, DKIM can not authenticate the sender.  DKIM authenticates some unseen domain signed a portion of the message.  DKIM does not confirm the signing domain intended to send the message to…

What is your definition of sender?  The sender can be many different
entities in this context.. I can be the relay, it could be the domain's
email server or it could be the end user...

>From my understanding, DKIM is basicly a statement from a responsible
domain, that I have done my best to validate that this is a legitimate
email and I don't relay for untrusted people, etc...

> StartTLS is not affected by message structure and indicates the intended recipient as well as identifying an accountable sender. StartTLS offers a safe basis for trust, reputation, and acceptance.…

Maybe I'm missing something, but I'm not sure how STARTTLS (plus presuably
w/ DANE) can authenticate that the client is the sender?  I might be
missing the RFC/standard/etc. that allows server to auth the client cert..

In most cases I've seen, it's only the client/relay authenticating server..

> ps. DKIM authentication does not vet the message nor the trustworthiness of the signing domain.  DKIM does not validate any identity either.

As far as my understanding, nor does STARTTLS...

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Oct 2013 16:06:17 -0400

> email server or it could be the end user...

Please terminate this sub-thread.  It has many years of wasted history 
on many mailing lists.

Really.  The script this thread will follow has been run so many times, 
the pages are tattered.

d/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Oct 2013 14:05:59 -0700

Dear John-Mark,

Good Questions.  See brief comments inline.

> email server or it could be the end user...

Based on whatever definition used, an entity held accountable for sending a message to a recipient not desiring its receipt should be authenticated for having actually issued the message to said recipient.  DKIM can not do this.  It only indicates an unseen signing domain handled the signed portion of the message and nothing more.  

> email and I don't relay for untrusted people, etc...

Responsible for what?  When the DKIM mechanism fails to ensure elements needed to hold domains accountable for unwanted email abusing a recipient, it would be unwise to assume the domain is therefore responsible.  Any such assumption can be easily poisoned. 
  
> missing the RFC/standard/etc. that allows server to auth the client cert..

Normally the critical aspect when submitting a message is to ensure credentials are shared with the intended submission server.  This is where StartTLS is normally used, but StartTLS can also exchange client certificates.  Since client certificates become essential when accepting encrypted email over IPv6, perhaps the presence of a DANE certificate located at the MX could automatically signal a paradigm change.

> In most cases I've seen, it's only the client/relay authenticating server..

You mean StartTLS verifying the domain of the server requesting client credentials?  Then yes.

> As far as my understanding, nor does STARTTLS...

This represents an unused feature that could greatly strengthen and protect all forms of email.  Abuse would drop significantly within a new paradigm that safely permits the establishment of domain reputations, while also enabling services to operate safely from any IP address and from any provider.  Not even Reverse DNS has less overhead when DNS timeouts are considered.

Regards,
Douglas Otis

---

From: Noel Torres <[email-masked]>
Date: Wed, 23 Oct 2013 22:21:35 +0100

On 23/10/13 22:05, Douglas Otis wrote:
[...]

> This represents an unused feature that could greatly strengthen and protect all forms of email.  Abuse would drop significantly within a new paradigm that safely permits the establishment of domain…

Domain reputations are also considered in my idea, but I'm starting to 
think I'm losing time and energy here, since I see only negativity.

Do some of you want to read how do I think it should be implemented?

Them, you can discuss with a basis and not just pre-concepts about other 
methods (STARTTLS/DKIM/whatever)
>
> Regards,
> Douglas Otis
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

Thanks

Noel
er Envite

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 23 Oct 2013 14:35:55 -0700

Noel Torres wrote this message on Wed, Oct 23, 2013 at 22:21 +0100:
> >This represents an unused feature that could greatly strengthen and 
> >protect all forms of email.  Abuse would drop significantly within a new 
> >paradigm that safely permits the establishment of domain reputations, 
> >while also enabling services to operate safely from any IP address and 
> >from any provider.  Not even Reverse DNS has less overhead when DNS 
> >timeouts are considered.
> 

My question is what does your idea bring the isn't already covered by
some combination of STARTTLS/DKIM/SPF/etc?  Assuming small modifications
are made, such as expanding SPF to include the FP of the sender's cert.

---

From: Noel Torres <[email-masked]>
Date: Wed, 23 Oct 2013 22:38:59 +0100

On 23/10/13 22:35, John-Mark Gurney wrote:
[...]
> are made, such as expanding SPF to include the FP of the sender's cert.
Mostly two things:
a) stopping some spam messages before they even are transmitted
b) not being a combination but an idea that naturally addresses both 
wiretapping and spam
Also
c) not being DNS dependant

I will follow a good advice from one list member and will write a 
document with the idea.

Thanks all

Noel
er Envite

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 23 Oct 2013 18:35:53 -0400

Noel,

Great, writing a draft will be helpful and appreciated.  While the comments may have come across as negative, think of them as helpful to possibly improve your idea or to combine with other ideas as appropriate through brainstorming.  What I see is interest in a discussion, that's positive.  

Seeing the full idea may change minds or offer opportunities for you to assist with improvements to existing efforts.  

Kathleen 
(Reading way too much for the diversity work - LOL). 

Sent from my iPhone

---

From: Noel Torres <[email-masked]>
Date: Thu, 24 Oct 2013 19:04:19 +0100

Hi all

The promised rough draft:

Initial Draft about OpenPGP Server-side Signed E-mail (OPSS e-mail)

Intent: To provide a method for server to server SMTP transmission that 
allows both
a) encryption
b) rejection before transmission of a message sent by an unauthenticated 
server

Throughout this work we will use “server” as the SMTP server intending 
to receive e-mail and “client” as the SMTP server trying to send a message.

How it works:
It will work as a standard, plaintext SMTP communication: client starts 
SMTP communication with HELO or EHLO. If client starts with HELO, server 
MUST assume that the client is not capable of authentication, but this 
is not the end of the protocol. If client starts with EHLO, server MUST 
announce OPSS as an available extension, then wait for client to confirm 
its usage. For a OPSS-enabled EHLO client, second command MUST be OPSS 
INIT. If it is, server will try to authenticate client, else server MUST 
assume that the client is not capable of authentication, but this is not 
the end of the protocol.

If a client is not capable of authentication, server MUST try to match 
HELO or EHLO node name with its internal list of known parties. If the 
match succeeds, it means that the server knows that the client hloud be 
able to do OPSS so server will reject the message with a 554 error 
before the message if transmitted and close connection.

If a client gives the OPSS INIT command, server will answer with 250 OK 
OPSS CHALLENGE and a printable random string. Client MUST give the OPSS 
RESPONSE command adding the ASCII-armored OpenPGP signature of the 
random string. Failure to do so means that server will reject the 
message with a 554 error before the message if transmitted and close 
connection. After OPSS RESPONSE server will opss-verify the signature 
(see procedure below) and if it is correct will follow the “Add host to 
known parties list” procedure (explained below) and answer with 250 OK 
OPSS OK announcing willingness to receive a message, while if the 
signature is not opss-verified server MUST reject the message with a 554 
error before the message if transmitted and close connection.

On this point a client MAY request the server's OpenPGP key (procedure 
below).

Now the client MUST do one of the following: MAY use the STARTTLS 
procedures, or MAY issue the OPSS ENCRYPT command. This command will be 
answered by a 250 OK message, after which point the entire commands and 
replies will be OpenPGP encrypted and signed.

How the client knows the server's OpenPGP key
There are four ways for doing this:
a) It is preloaded by the Administrator
b) It is downloaded from an OpenPGP keyserver before starting the 
communication
c) It is present on a DNS record for the server (this method is not 
covered by this document)
d) It is requested by the client on the fly

For requesting a key on the fly the client uses OPSS KEY command, which 
MUST be answered by the server with a 250 OK OPSS KEY answer and its own 
ASCII-armored OpenPGP key.

How the server knows the client's OpenPGP key
There are three ways for doing this:
a) It is preloaded by the Administrator
b) It is downloaded from an OpenPGP keyserver, out of band, while 
crafting, sending, receiving and checking the challenge-response.
c) It is present on a DNS record for the client (this method is not 
covered by this document) which is checked out of band while crafting, 
sending, receiving and checking the challenge-response.

Signature opss-verification procedure
Once the server has the signed response to the challenge, it will 
perform a standard OpenPGP verification (OpenPGP verification is one 
step of OPSS verification). If this fails, the verification fails. If it 
succeeds, server will match the EHLO node name againts its known parties 
list.
If it is found as “verified”, server will check the key also stored 
there against the one used for the response, and if they match, 
verification succeeds and message will be accepted, otherwise 
verification fails and message will not be accepted.
If it is found as “non-verified”, server MAY update the key from an 
OpenPGP keyserver in order to check if further signatures on it makes it 
verified. Anycase verification succeeds and message will be accepted. 
Server MAY also check the key also stored in the known parties list 
against the one used for the response, and add a 
X-OPSS-Signature-not-verified header to the message before delivering it.
Key update from a keyserver may also bring as revoked a previously 
verified signature, or may bring a different key for the same client.

Known parties list maintenance
Administrator can add pairs of EHLO node name-OpenPGP key to the list by 
hand. Also, any new key detected from OPSS RESPONSE commands will be 
added to the list together with the corresponding EHLO node name by 
using the “Add host to known parties list” procedure (explained below). 
If the server tries to update a key from a keyserver and finds a new 
key, this will be added as well, together with the corresponding EHLO 
node name.
A node name-key pair can have one of two statuses: verified and 
non-verified. Verified means that the server administrator manually 
choosed this, or that the trust on the keys signing it justifies to do so.
A node with a verified key can appear only once on the known parties 
list, but a node can have several non-verified keys on it, all of them 
valid.

Add host to known parties list procedure
When a server receives an OPSS RESPONSE command, it must check its 
correpsonding node name on the known parties list. If found as 
“Verified”, it does nothing. If found as “non-verified”, server adds the 
pair node name-key to the list without removing the already present 
pair. If not found, it just adds the pair node name-key to the list.

Web of Trust
The administrator can manually assign a trust level to each key, even 
keys that have an empty node name. Procedures for this are standard 
OpenPGP. If the configured amount of keys with the correct trust level 
are signing a key, that key will be considered verified without manual 
administrator intervention. Security note: An administrator should only 
assign trust to keys belonging to people or server he positively knows 
are conscious of the security implications of signing a key.

Key format
Keys will be standard OpenPGP keys with a corresponding e-mail address 
of OPSS_e-mail@[nodename]

X-OPSS-Signature-not-verified header
A server MAY add this header for a non-verified signature. Format is one of:
X-OPSS-Signature-not-verified: Not found [nodename]
X-OPSS-Signature-not-verified: Key found for [nodename], [key]
X-OPSS-Signature-not-verified: Several keys found for [nodename], [key used]
These can be used for MUA spam checking.

Regards
Noel
er Envite

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Oct 2013 22:23:19 -0700

> Really.  The script this thread will follow has been run so many times, 

Dave, I am well aware of past discussions, but something has changed. We can
certainly agree that server-to-server encryption is not the best way to
provide end-to-end authentication or confidentiality of messages. 

However, if I was running a spying system and if I was in the business of
collecting meta-data, I would love looking at unencrypted SMTP traffic.
Suppose that I tap  a number of big Internet pipe, at exchanges or on the
path to big servers. I can filter out the SMTP traffic with not much effort.
Even if the poor schmucks are using PGP or S-MIME, I will be able to read
the entire set of RFC-822 headers in clear-text. I can use that to create a
database of who sends e-mail to whom, and pretty soon I will have a good
idea of the "social network."

If I was running such a system, I would hate to see SMTP traffic becoming
encrypted. 

In the past, we did not suspect that someone would run such a system. We
were probably naïve. 

-- Christian Huitema

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Oct 2013 07:28:36 -0400

On 10/25/2013 1:23 AM, Christian Huitema wrote:
>> Please terminate this sub-thread.  It has many years of wasted
>> history on many mailing lists.
>>
>> Really.  The script this thread will follow has been run so many
>> times, the pages are tattered.
>
> Dave, I am well aware of past discussions, but something has
> changed. We can certainly agree that server-to-server encryption is
> not the best way to provide end-to-end authentication or
> confidentiality of messages.
>
> However, if I was running a spying system and if I was in the
> business of collecting meta-data, I would love looking at
> unencrypted SMTP traffic.

Christian,

I apologize for being ambiguous.  The "sub-thread" I meant was the
sole-sourced, compulsive attacks on DKIM.  I left the specific reference
off in an attempt to trigger yet-another round of attacks...  sigh.

FWIW, I think "link" (that is, lower transfer layer) encryption is just
fine, much like washing one's hands is good hygiene.

The fact that it won't really provide protection against most/all of the
actual attacks we've been seeing or hearing about doesn't mean we
shouldn't do it, for at least the reason you cite.

But of course it does mean we also need to look at things more broadly, 
for the additional mechanisms that will cover current, typical attacks.

d/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Oct 2013 14:08:24 -0400 (EDT)

> Initial Draft about OpenPGP Server-side Signed E-mail (OPSS e-mail)

I don't understand how this adds anything to STARTTLS with TLSA/DNSSEC,
apart from being able to get a remote server key from a HKP server,
which in itself is completely untrusted without web-of-trust
verification by a human.

In fact, TLS with DHE would be more secure agaisnt a pervasive monitor
that obtains access to a mailserver's private openpgp key.

What would doing openpgp encryption within TLS add security wise?

Paul

---

From: Jacob Appelbaum <[email-masked]>
Date: Sat, 26 Oct 2013 09:24:06 +0000

> What would doing openpgp encryption within TLS add security wise?

Defense in depth. If the StartTLS server uses RC4, for example, I'd want
a different layer for actual protection.

All the best,
Jacob

---

From: John-Mark Gurney <[email-masked]>
Date: Sat, 26 Oct 2013 05:13:04 -0700

> a different layer for actual protection.

If the admin spent the time to configure OPSS, why not configure TLS
properly in the first place?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Oct 2013 13:31:00 -0400

I can't see much point in applying and removing PGP and/or S/MIME at the
start and end of the TLS tunnel. If you are worried about the encryption
strength then fix that. If you are worried about the downgrade attack then
hook a policy layer in.

Message layer security will always cover less than transport on an
individual hop because the message layer encryption can't cover the routing
data.

The advantage of going to message layer security is when the start and/or
end point might be different.

So for example, right now almost nobody is equipped to accept encrypted
email as conveniently as unencrypted. I can only receive encrypted email on
one machine. I don't enable all my machines because it is a hassle and the
keys expire etc.

Sending me a message TLS encrypted, I can only decrypt at the inbound mail
server. A PGP or S/MIME message could be decrypted at the inbound mail
server OR at the mail client depending on what gives the best balance of
performance / security / spam control / compliance and convenience.

The other advantage to using message layer security is that it is possible
to force use of encryption. So for example, let us imagine that I have an
outbound mail server that knows how to resolve key identifiers to public
keys using some protocol (Vcard, WebFinger, WKS, wev). I can poke the
outbound mail server to automatically encrypt messages if the email address
has a particular escape code in it. At the moment I am using a question
mark.

Let us imagine I want to send an email message to Jacob that I want to be
sent encrypted or not at all. I would use the address
?[email-masked] which
tells my outbound mail server 'use whatever resolution services are
available to find a key and if a trustworthy key can be found use it to
send the message, otherwise report a delivery failure.

If I really want to be sure that the key is correct then I would explicitly
specify the key fingerprint:

228F-AD20-3DE9-AE7D-84E2-5265-CF9A-6F91-4193-A197?[email-masked]

The nice thing about this approach is that I can use it with all my
unmodified mail accounts and mail clients. All that I do is to redirect the
outbound mail service through my trusted outbound mail gateway (which is on
127.0.0.1 on most of my machines). I could even send messages through my
Gmail account (but would have to use a non Webmail client to compose and
send).

Receiving mail requires me to either use a mail client with my S/MIME cert
loaded or an S/MIME viewer for WebMail.

At the moment this is a crazy hybrid of S/MIME and PGP approaches. But the
fact is that S/MIME has pervasive deployment while PGP has a userbase. Plug
ins are a hack for testing purposes only, any security scheme that depends
on typical users deploying a plug in is going to fail. It is painful enough
dealing with the vagaries of the platform and application update mechanisms
changing stuff on a daily basis without a layer of plug ins to cope with on
top.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 26 Oct 2013 14:37:47 -0400 (EDT)

On Sat, 26 Oct 2013, Phillip Hallam-Baker wrote:

> I can't see much point in applying and removing PGP and/or S/MIME at the start and end of the TLS tunnel.

Exactly. If you do that, you should encrypt it to the _recipients_
private key, not some random mailserver's private key.

which brings us back to draft-wouters-dane-openpgp-01

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Oct 2013 16:32:06 -0400

On Sat, Oct 26, 2013 at 2:37 PM, Paul Wouters <[email-masked]> wrote:

>> start and end of the TLS tunnel.
>>
>

I don't see much point in trying to couple DANE to PGP.

I don't care about sending mail to  cypherpunks.ca <[email-masked]>, I
care about sending it to Paul Wouters.

Except in very rare instances where an individual controls the domain or if
I am sending to an enterprise, the domain is going to be pretty much
irrelevant to authenticating the key.

Locking down the mailserver key with DANE makes prefect sense. In fact that
is the only reason I can see to do DNSSEC right now.

-- 
Website: http://hallambaker.com/

---

From: [email-masked]
Date: Sun, 27 Oct 2013 22:42:25 -0700 (PDT)

> properly in the first place?

To be fair, that's a bit of a problem right now. The issue is you don't  really
want to flat-out disable RC4 ciphersuites because there may be some clients
that don't have anything else, and RC4 is better than nothing.

But at the same time you don't want to use an RC4 ciphersuite unless there's no
alternative - and there usually is. The problem here is that specifying a
preference order for ciphersuite use is a problem with some implementation
currently. As I noted previously, you want to prefer something with DHE when
possible and AES to RC4.

That said, in terms of standardization, I think the priority should be to
get the SSL/TLS stuff done. And then folks can start beating up on the
implementors to get a better grade of SSL/TLS in place.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Oct 2013 18:23:18 +0100

> a different layer for actual protection.
Let's be careful about that argument.  Defense in depth should actually
add real depth.  Otherwise it's just extra work to send a message.  If
you suggest a new mechanism just to get rid of a bad algorithm, whatever
you replace it with will likely someday be found to have a bad algorithm
as well.  To what depths shall we sink, then?

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Oct 2013 16:11:28 -0700

On Oct 26, 2013, at 1:32 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> I don't care about sending mail to  cypherpunks.ca, I care about sending it to Paul Wouters.
> 
> Except in very rare instances where an individual controls the domain or if I am sending to an enterprise, the domain is going to be pretty much irrelevant to authenticating the key. 
> 
> Locking down the mailserver key with DANE makes prefect sense. In fact that is the only reason I can see to do DNSSEC right now. 

Dear Phillip,

Agreed.  Allow me to expand.  Who is communicating with whom should be considered private, but knowing which domain is sending data does not cause the same level of exposure when contained entities can be associated with different domains.  While the actual entity sending a message might be encrypted, knowing the domain facilitating the exchange is the bare minimum needed to defend the services.  No service can be allowed to issue messages anonymously.  XMPP offers clues about how this is deployable at scale in DNS where dial-back techniques should be disabled:

_xmpp-client._tcp.example.com. 36000 IN SRV 0 3 5222 xmpp.example.com.
_xmpp-server._tcp.example.com. 36000 IN SRV 0 3 5269 xmpp.example.com.

Unfortunately, major providers fail to ensure use of valid certificates and may only offer self-signed certificates where explicit exceptions need to be quietly made. Could this explain why a widely used IM client popular in Europe is likely obtained using HTTP?

Things like DANE offer hope.  Being unable to trust DNS or routing, it seems DANE offers a conceivable solution. I also agree with Albert Lunde about not embedding Turning-complete interpreters.  It is amazing this is not seen as harmful from a security perspective.  Perhaps the IETF could offer buttons and stickers for sale along with DNSSEC and DANE, or would that upset those not wanting to see anything change?  :^)

Regards,
Douglas Otis

There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. But at any rate they could plug in your wire whenever they wanted to. You had to live-did live, from habit that became instinct-in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized.

Excerpt from Chapter One of George Orwell's book _Nineteen_Eighty_Four_