[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HTTPS everywhere!

On Mon, 2014-06-23 at 17:26 +0200, Christoph Anton Mitterer wrote:
> Maybe my understanding of DKIM is too little... but I thought it would
> be only some technique to verify the authenticity of sender addresses?

DKIM, OpenPGP, X.509 - they are all the same thing with different names.
They all compute a hash of a lump of data, and encrypt it using a
asymmetric cypher.  Given that, it just boils down to what data they
encrypt and what crypto they use.  For DKIM the signer gets to select
what he signs - it could be the entire email, and the crypto is
rsa-sha256.  Key size isn't constrained, but is generally 2048 bits.

The only reason I mentioned DKIM is the software is already written.  It
would be a few hundred lines of code, at most, to sign every incoming

> And as I've said... just signing somehow all the single mails that
> arrive at the BTS, which could be verified by clients when they read it
> is not enough.
> That would allow an attacker to easily filter out single messages...
> somehow you need to secure the series of all messages,... and also
> things like negative replies (e.e. "there is no bug for package xyz).
> And since many people interact with the BTS via web (well at least for
> reading) you're anyway obliged to support some https solution.

The usual solution so that is what Debian uses for it's package archive.
It's to sign the index of messages apt-listbugs downloads in order to
find the emails to display.

> Even if you have some pinning technique like CP in place,... than a
> non-Debian rogue CA can simply attack you on your first visit of
> https://whatever.debian.org/ and your CP is useless.

You've lost me.  Whether Debian is a CA or not it irrelevant for the
initial download of software over the net.  It will be done, by
definition, using non-Debian software, which be using the X.509 PKI in
the normal way.  The normal way here implies they will trust every CA
bundled into downloaded software.  Including a Debian CA in that bundle
doesn't help Debian's security in the slightest.

Pinning is just another word for "I don't need to use the X.509 PKI,
because I obtained the Debian certificate via a side channel".  By
definition that means whether Debian is a CA or not is irrelevant -
because being a CA means "I am one of the privileged few whose
certificates are distributed by the X.509 PKI".  So yes, I agree pinning
is useless when you first download the software.  But nothing you have
suggested so far is any better in that case.  As far as I know, nothing
can be any better.

> Again... using CP alone won't make things secure - unless you really
> hard code all the single Debian host certs in all programs that use
> TLS/SSL (or at least with Debian services).

For me "all programs" boils down to 1 - Firefox.  Some others might use
Chromium, which given Chrome supports Google's pinning its own certs
probably could be hacked easily enough to support Debian doing the same

> It's much easier to run our own Debian CA plus:
> - for most non-browser programs that allow to specify which CAs are
> trusted, only add that Debian CA
> - for browsers: hard code that Debian CA as the only one for debian.org|
> net

This looks like pinning under another name to me.  And quoting you
above, in this very same email, you say pinning is too hard because you
have to "hard code all the single Debian host certs in all programs that
use TLS/SSL (or at least with Debian services)".  And yet now you say we
have to do this anyway!

Your insistence that Debian become a CA is now truly mystifying.  There
is only one reason to become CA, and that is so you can have your
certificates distributed by the X.509 PKI.  Yet you profoundly distrust
the X.509 PKI, so much so (and imo with good reason) that you insist we
don't use X.509 PKI at all when interacting with Debian, preferring to
use a pinned Debian cert instead.  So bother becoming a CA in the first

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: