second round of feedback

[ioerror]

I've reviewed the text and added a bunch of comments, etc.

[nymsio]

Replaced? Or augmented? If you're not removing the web of trust code from PGP
and GnuPG, I suspect you will merely augment it. Be explicit?

Neither replace nor augment actually since Web of Trust is worthless. More
like replace the key authentication which people falsely believe WoT can
accomplish.

To the extent that WoT is a software feature rather than a social convention it
really should be removed from implementation codebases but that's not up to me.

[nymsio]

I suggest a regular re-affirmation of Endorsement - that is to ensure keys
aren't stale - make the signatures expire regularly. This can trigger a refresh
of the key, for example. It can also be scheduled in advance - so there is a
sliding window.

Yes, this is the way revocation is implemented by default. Identity Certificates fall off
the directory if they aren't refreshed with a new endorsement every N (ie N = 30) days. This
simple refresh endorsement will only require something like signing a challenge with the
same private key.

I've also considered requiring a new email verification every N (ie N = 6) months.

[nymsio]

I also think the distribution should be via DNSSEC, HTTPS or other methods.

Distribute which keys from what domains and web servers? Does your suggestion
require every email provider on the internet with users who want to use encrypted email
to build or install new infrastructure in order to accommodate this plan?

[nymsio]

Link to the verification protocol? Expand on other kinds of verification? XMPP?
Email? OTR with other protocols? Pond? What is the scope?

The scope is really only Email right now, but the same call-back verification strategy
could be also used with OTR+XMPP. The important thing that I'm trying to illustrate is
collecting related keys and addresses into a single OpenPGP key set called an Identity
Certificate. These keys and addresses are related because they all belong to a single
pseudonymous identity.

[nymsio]

This requires a threat model that specifically explains why such a two-way
email verification protocol is safe or reasonably safe within certain bounds.

There are two ways to think about this:

1. Compared to what?
2. What are you otherwise going to do?

Currently, nobody does much of anything to validate email addresses in PGP keys.

That includes the keeners who willingly show up at a 'party' where there is
no alcohol, music, or anything else fun. Main entertainment is wandering
around with drivers license in one hand and printed list of hex digits in the
other, squinting at the documents presented by the other participants and
meticulously confirming all information except email addresses which is the
only detail which actually matters. Now go forth and securely send encrypted
email with keys bound only to names printed in passports. At least you tried!

You want me to state a threat model? Ok. Your postman's name is Mallory and he
delivers all your e-mail including the messages exchanged in the verification protocol.
Therefore you always lose because Mallory has already registered false keys
under your email address and intercepts all your encrypted mail and reads it.

I can't prevent this, but I can prevent Mallory from succeeding without
detection and without leaving enough clues to understand exactly how it happened.

However, If Mallory is a weaker attacker than the system administrator of your
email provider then DKIM has some real value here.

[nymsio]

Nearly zero popular email services are actually secure from an active MITM
without pinning, and even then, I suspect the SSL-Added-And-Removed-Here issue
will come up. What stops an attacker who is able to MITM a specific domain? I

The due dilligence on certificates and MX records stops those attackers in as
many cases as possible.

[nymsio]

suspect a few things: one is to connect from Tor to a Tor Hidden Service
published by the service, another is to connect over Tor to reduce the
distinguishers so that a MITM will be harder to execute selectively, yet

The email verification service could retrieve SMTP server certificates the first
time over Tor since it doesn't have a pinned version to compare against.
Is that what you mean?

[nymsio]

another is something like DANE verification for StartTLS - however, we know
that the NSA steals keys - so for active attackers, we're again not doing great
for a targeted attack for the very first lookup/verification.

I can't make every (or any) mail provider implement DNSSEC + DANE but of course
we would use that information if available. Nobody is ever going to depend on
DANE for SMTP certificates though because what are MTAs supposed to do if a cert
doesn't verify correctly? Refuse to deliver mail? Most MTA certificates are
broken so not delivering mail is simply not an option.

[nymsio]

I think this would be a useful time to discuss something like a CT log - why
not have that log be public, for example?

Because it will leak all user addresses and because it's redundant. If the
directories start serving the wrong key, you and your contacts will see it change
when you poll the key.

CT needs to exist because any CA can silently issue a certificate for any domain
and this bogus certificate is invisible until it's used in an attack and even
in that case it's only visible to the victim of the attack.

CT prevents that silent creation of a malicious certificate because if a certificate
doesn't appear in the public log then it's invalid and if it's added to the public log
then it's there forever and Google has the evidence they need to issue the CA death
penalty to the sketchy CA.

[nymsio]

Each Trusted Notary runs a service which signs certificates after verifying them by
sending email to a UID address of the certificate.

What happens when you have multiple UIDs? Eg: I have foo@foo.com and
foo@bar.com on a single key. One cert per UID? One signature per UID?
This needs some clarity for the most common use cases - also it would be nice
as an advanced user to know how to keep my master secret offline, for example,
with this system.

Multiple UIDs exist as before, but for the verification protocol any extra UIDs are
stripped off of the key before submitting it for verification.

As an example - you send an email to verify-me@example.com from your
user@example.com email address - it ensures that you are the correct
user@example.com before signing your key, right?

More like you send an API message to the nyms service for example.com which says:

"Hi, I'm user@example.com, here is my password for you to verify using the example.com
mail user authentication database, and here is my identity certificate for you to sign"

A specific example will help a service provider to understand it - it will also
help users to consider how they might interact with the service provider. To

From the user point of view, they don't have to do anything. They enter their username and
password into a nyms compatible email client, create or import an identity certificate, and
they're done. This is the case both for the email verification protocol and participating
providers. The nyms client agent transparently takes care of registering and publishing the
identity certificate.

also, I suspect that this means at the edge of the network, we'll see a lot of
problems because this part of the system is the most homebrewed.

Only thing that needs to be hand-rolled is integration between provider verification service
and whatever authentication system the mail provider uses.

[nymsio]

This will require everyone to make new keys. That is fine but it is worth
stating that many people have a few UIDs on their key. For new users, it is not
important but for power users, it is telling them what to do. It may make sense
to accommodate them by simply signing each verified UID regardless of where it
is located. It may not matter either.

Nope, you can use your existing gpg key with a dozen email addresses on it. The nyms client
will strip it down before running the verification protocol. You can't publish your key under
any of the other email addresses without running the mail verification protocol on them of course.

[nymsio]

What would an expected change look like?

That's a good question, I was imagining a validly signed certificate chain changing to another validly
signed certificate chain when I qualified that with 'unexpected'.

Really though, any change at all needs to be investigated.

[nymsio]

Is this easy to do? Does GnuPG support such a thing?

Yes, you can even do it from the command line with GPG I think, but we're not using GPG we're using
a low level OpenPGP library so we can do whatever we want.

Notations are just key=value pairs that can be added to any signature.

Also, do you really want
to publish a link between an email, a twitter account, etc? I think it may be
useful but it may also be very harmful.

Yes, this is in fact a key concept in the nyms system. It's very common to want
to communicate (securely) with people you only know from somewhere online. People
who are anonymous or pseudonymous or for whom it really doesn't matter what their IRL identity is.

pseudonymous --> pseudonyms --> nyms

How did you decide you wanted to talk to them in the first place? They might be an IRC nick, and/or
an email address on a mailing list, and/or a reddit account and/or a name on twitter to you. Nyms consolidates identity information so that you can do things like bootstrap from a name on twitter to a secure PGP encrypted email conversation.

Ideally, I'd like a way to get the public key for @nymsuser but as that user,
do I really want people to start to send me email? Do I care if it is
encrypted? I often do not want people who talk to me on twitter emailing me
randomly.

This is what Key Segmentation is for. If somebody looks up nymsuser@gmail.com they get your email key but by default they don't find out about your IM account nymsuser@jabber.com.

but if they already know nymsuser@gmail.com and nymsuser@jabber.com they can download records for both UIDs and verify that they belong to the same master signing key.

If @nymsuser sends a DM to somebody else on twitter and tells them to send encrypted mail to nymsuser@gmail.com that person is now able to confirm that the email address is the correct one and that they have the right keys to encrypt mail.

[nymsio]

How do I know I'm talking to the correct Directory Service? Do they publish
DNSSEC records? Do they publish a .onion where I can reach them to verify the
certificate is the same? Do they require access from Tor (eg: Tor users are
never blocked, etc)?

Similar to how Tor solves the same problem:

• Master keys for trusted notaries hardcoded into clients.
• Notaries periodically (ie every 24 hours) make a status document available for download which is signed by every notary.
• Status document contains things such as the TLS certificate fingerprints, other keys used by the notaries, network configuration variables
• Clients require status document to be signed by n-of-m of the trusted notaries they are aware of.

[nymsio]

Does the network also enforce these checks? It isn't enough to be able to
detect it or to be able to log it - we need a system that will actually detect
them automatically, I think.

The clients automatically refresh keys and detect unexpected changes. This includes users
checking up on their own keys periodically.

Do we also mean Identity Certificate Revocation and Expiration? I think so.

Yes, the only interpretation that make sense here. It's signatures that expire, not
keys.

And those revocation certificate are automatically generated at key creation
time, right?

Yes, but where to store it? One idea I've considered is escrow revocations on the directory
servers (encrypted with passphrase) or IMAP upload them into your email account.

but if mallory steals a revocation, he'll use it to cancel your keys and replace them.

shrug

[nymsio]

How does this compare with STEED for example?

It doesn't have the unrealistic expectation that email providers find a way to publish user
keys into DNS.

Nyms has no expectations at all of email providers.

[nymsio]

Hi, I've reviewed your comments based on your review of my text and commented on your comments. In order to make this as confusing as possible, I've failed to include a reasonable amount of helpful context.

[elijh]

I also think the distribution should be via DNSSEC, HTTPS or other methods

directories should use HTTPS, but I would really like to avoid DNSSEC:

• Only applicable to participating providers
• Difficult for a provider to maintain (need to integrate with their existing DNS system, rather than just running an additional daemon).
• No good way (yet) to protect confidentially of requests
• Much more complicated to write clients for (and can't write in-browser javascript clients for)

[elijh]

Nobody is ever going to depend on
DANE for SMTP certificates though because what are MTAs supposed to do if a cert
doesn't verify correctly? Refuse to deliver mail? Most MTA certificates are
broken so not delivering mail is simply not an option.

Postfix actually has some nice options for this. You can make postfix require actual DANE validation if the DNS records exist (and fail closed if validation fails), but fall back to normal StartTLS if there are no DANE records. This is what we are doing with LEAP.

The next improvement we want to work on is to make the use of DANE a permanent requirement for a particular provider if they have ever published DANE records in the past.

[elijh]

I think this would be a useful time to discuss something like a CT log - why
not have that log be public, for example?

Because it will leak all user addresses and because it's redundant. If the
directories start serving the wrong key, you and your contacts will see it change when you poll the key. CT needs to exist because any CA can silently issue a certificate for any domain and this bogus certificate is invisible until it's used in an attack and even in that case it's only visible to the victim of the attack.

A public CT-style append only log published by the endorsers would be an addition with some benefit, one that can be added later. But not that much benefit.

An append only log does not necessarily need to leak user addresses, as the log could consist of the hash of the address and not the address itself.

An append only log is not redundant. Yes, your client will see the bogus key when it polls for your own key, but this has problems:

1. The first problem is one of timing: without a global view into the history of endorsements, a directory can serve the bogus key for a short period of time and then go back to serving the correct key. The client can't necessarily audit every endorsement.
2. The second problem is that it places too much of a burden on the user's client. Without an append only log, it is really the user's client that is entirely responsible for verifying that no bogus keys are being published for their addresses. What if the user is in jail and can't access their client? Then no verification happens and a bogus key could be published for them with no one the wiser. At least with a log, there is a chance to catch this.

The problem, however, with an append only log is that it probably adds more complexity to the system than is worthwhile given the potential benefits. It would probably add more security with less effort to add a system of "endorser consensus" instead.

[nymsio]

Postfix actually has some nice options for this. You can make postfix require actual DANE validation if the DNS records exist (and fail closed if validation fails), but fall back to normal StartTLS if there are no DANE records. This is what we are doing with LEAP.

If it turns out that DNSSEC has some value to Nyms then we'll take advantage of it but Nyms cannot generally depend on DANE or DNSSEC because then it becomes unusable by users of mail providers which don't publish certificates with DANE. I admit I may not be up to date on status of DNSSEC deployment, but as I understand it the number of email providers which haven't implemented DANE yet is all of them.