Tag: openpgp

OpenPGP Certificates can not be deleted from keyservers

Due to my involvement in sks-keyservers.net I frequently get questions on whether I can remove OpenPGP certificates from the keyservers.

TL;DR; Removal of OpenPGP certificates from a keyserver is not possible.

To start off with, the OpenPGP keyserver network consists of more than 150 keyservers reconciliating their database between the peers. Even if I could delete it from some servers I operate it will be re-added on next re-synchronization with the other servers unless done in a coordinated fashion of all the keyservers in the network, i.e. virtually impossible.

The correct way to flag a key as not being used is revocation.
Revocation require access to the private key or a revocation
certificate generated while having access to the private key; gnupg 2.1 automatically generates revocation certificates when a key is generated for this purpose and places it in ${GNUPGHOME}/openpgp-revocs.d.

Data is by design never removed from keyservers, much like it stays around in a blockchain. One should never validate a public keyblock based solely on email address in UID on a keyserver; But before using a public keyblock it needs proper due diligence verifying inter alia fingerprint, creation type, key algorithm, with the perceived owner of the keyblock out of band before signing (cerifying) and using it as a trusted channel. That several certificates exists for a single email address is, from a cryptographic and security point of view irrelevant, as it is only applicable as a potential issue if people don't follow proper procedure for due diligence.

To make the story even longer;  even if it was technically possible the social protocol is missing. Speaking more generally, there might've been two (or more) people sharing the same name, and email addresses change over time, if the previous user deleted his email, it wouldn't make the certificate any less valid that someone else take over the email address, and if someone could remove the data it would require ways to verify the authentication of the request. Additionally it could make the keyserver operators viable to certain legal liability if incorrectly deleting a key allowing it to be replaced by a MITM cert.

Email: Are you writing emails in a proper etiquette?

Most of us use email rather frequently, however how email is used varies substantially across groups of people. The differences are especially noticeable when it comes to etiquette of quotation and threading of email, that in particular becomes important as the volume of information increase in order to keep track of the various threads.

Some groups are inherently better than others, and some email clients encourage better practices than others, but in the end it all comes down to the user choices being made. Not surprisingly, developers tend to have a better grasp at email etiquette, but what can we learn from this?

HTML emails:

Lets start off with HTML emails. I mean, seriously, disable this at once. Email should be text only, and if that isn't sufficient it likely should be an external reference or an attachment. HTML emails doesn't provide any obvious advantage over text email, but has many downsides, in particular external loading of resources leading to privacy issues and possibility to execute script files leading to security vulnerabilities. Having HTML, in particular in combination with scripting, or allowing external resource loading is as such only negative, not to mention you can't really work and compose a response offline.

If using HTML for the purpose of text formatting there exists common practices for styling plain text emails that removes most of the need for it. The following are a few of the tricks for bold, underlined and italic text that will have effect in sane email clients.

  • *bold text* , the asterisk will be treated to indicate bold
  • _underlined text_ , the underscore character on both sides of the text will be used throught the client
  • /italic text/ , slashes are useful too

bold_underline_italic

Proper quotation

So, once you start writing proper emails in plain text only, the question of quotation comes to mind. Do you ever top-post? if so, why would you do such a silly thing? Wikipedia has some more information on this quoting style, but I prefer to keep to the basic:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Reading in the opposite order does something funky with your brain, doesn't it? Why do you want your readers to suffer like that in order to try to get a context of a conversation, in particular if this is one of 100 different threads they are actually following?

Continuing form that; quotes should be properly nested using the ">" character. That is how it has been done for several decades, and newcomers to email not following the practice are just an annoyance. Proper email clients will interpret this and display it accordingly:

quotation

On that same note, remove information that isn't relevant when responding to an email, reading through non-related information just increases the workload of everyone of your recipient, so just... don't, the few seconds more it takes you to clear out the information that isn't related results in a N times amplification of savings for the readers depending on the number of people involved (and the times the email is accessed).

Threading

Etiquette also comes into mind with regards to threading. In some mailing lists this becomes vital in order to follow the discussion, and if someone is using an email client (such as Google's  Android standard email client that doesn't support In-Reply-To and References). A user that posts a message that breaks the thread can reasonable expect to be cursed upon and told to get a proper email client.

threading

A sub-topic of proper threading is, if you during the course of the discussion create a sub-thread that actually focus on something different from the initial one, for crying out loud, change the subject of the email to reflect this to make it easier to keep track of and look back in the archives.

OpenPGP signature and encryption

I've likely said enough about this topic already, but any post about emails are required to cover the need for proper authentication, integrity and confidentiality of information. So if you don't use OpenPGP / GnuPG / PGP to protect your information (and going forwards, hopefully with a Memory Hole compliant client). Well, don't expect too much positive response from me at least.

How Microsoft once again demonstrates not caring about security

On June 27 Microsoft announced they would stop sending security bulletins by email. The announcement stated:

As of July 1, 2014, due to changing governmental policies concerning
the issuance of automated electronic messaging, Microsoft is
suspending the use of email notifications that announce the
following:

* Security bulletin advance notifications
* Security bulletin summaries
* New security advisories and bulletins
* Major and minor revisions to security advisories and bulletins

In lieu of email notifications, you can subscribe to one or more of
the RSS feeds described on the Security TechCenter website.

This change is speculated to be related to a Canadian anti-spam regulation, although the normal course of action would normally be receiving explicit approval for sending these announcements. Some questions have also been asked about the timing of the announcement, as the regulation was known well in advance. Whatever the reason for suspending these services, on July 3rd, Microsoft reversed its course with the following message:

On June 27, 2014, we notified customers that we were suspending
Microsoft security notifications by email due to changing
Governmental policies concerning the issuance of automated
electronic messaging. We have reviewed our processes and are
resuming security notifications by email commencing with the
release of this monthly Advanced Notification Service (ANS) mailing.

Now, a prudent reader might ask why receiving emails constitute a security relevant matter, after all they offer to keep sending announcements through an RSS feed. That brings us to the more interesting matter. Microsoft, rightly so, use OpenPGP digital signatures for the notification emails to make it possible to verify the authenticity of the sender and verify that the message has not been altered in transit. The OpenPGP signed email communication channel is the only available option provided by Microsoft with these capabilities and in order to grab focus on this property, they include the following in their own bulletins:

The Microsoft Security Response Center (MSRC) uses PGP to digitally
sign all security notifications. However, PGP is not required for
reading security notifications, reading security bulletins, or
installing security updates. You can obtain the MSRC public PGP key
at
<https://technet.microsoft.com/security/dn753714>.

So far so good; Microsoft is using OpenPGP and they are announcing their public key. Other people should do this as well.

Sadly it goes downhill from here: Despite Microsoft announcing a HTTPS website for the acquiring the public key used for these announcements, upon attempting to contact this URL, a HTTP 302 redirect is used with the following Location: http://technet.microsoft.com/security/dn753714 , i.e .without any protection from TLS at all. This opens up possibilities of various man-in-the-middle attacks, hence removing the possibility validating the provided public key.

Of course, this shouldn't normally be an issue, as OpenPGP keys rely on object security which is self-contained together with the key material itself - which is why keys are normally distributed through various keyserver networks. Before using any OpenPGP key the key will have to be validated by the participant, either directly with the owner of the key or through the Web of Trust (WoT).

If we are to trust that we have not been MiTMed just now, Microsoft is linking to public key information presented as a 4096 bit RSA key for Certificate and Signing use with a 4096 bit subkey for Encryption.

And here is the kicker; The key was created on 2014-06-03, i.e. it is a relatively new key, and it does not contain any certifications from any Microsoft employee or signature from earlier keys used for Microsoft Security Advisories as you would normally expect.

To add insult to injury, despite the emails containing references to the aforementioned website and key, the following Microsoft announcements on July 10 and 11 were actually signed by the key 0xF0B7406D which is not referenced as a key used for current Microsoft announcements. This key actually does contain a small number of signatures from external users, but as with 0xA92965F2 none from any Microsoft employee. As to whether the key is authentic your guess is still as good as mine.

So why is it so important that the key used for security announcements is signed by individual Microsoft employees, and in particular the members of the security team?

These employees are the only individuals that can reasonably make an assurance about the use of a team key. Additionally, as proper key validation procedures require ID-checks and a personal assertion about the key ownership, for others to get a trust path to the key in question, these members of the team will need to have their own keys verified by other participants in- and outside of the IT industry.

Users that wants Microsoft to try to get its act together when it comes to communication security (to allow a broader scope is probably utopia) should send messages to them through channels such as Twitter (@msftsecresponse). My own posts have not been answered so far.