Subject: [dane] Comments on draft-wouters-dane-openpgp-02

From: Rene Bartsch <[email-masked]>
Date: Mon, 28 Jul 2014 13:39:30 +0200

Hello,

I've three suggestions on draft-wouters-dane-openpgp-02:

1. email domain providers MUST provide a secure API/interface to 
customers to provide a personal OpenPGP public key

2. MTAs/SPAM detection systems MUST check if the tupel "sender email 
address" <-> "sender OpenPGP public key" matches and MUST reject the 
email in case it does not match with signed messages to prevent address 
forgery and SPAM.

3. Security considerations: The IANA has control over the DNSSEC root 
keys. As the IANA is bound to US law, US government agencies probably 
have access to the DNSSEC root keys and are capable to manipulate the 
OpenPGP keys signed with DNSSEC.

-- 
Best regards,

Renne

Rene Bartsch, B. Sc. Informatics

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Jul 2014 09:52:09 -0400 (EDT)

On Mon, 28 Jul 2014, Rene Bartsch wrote:

> 1. email domain providers MUST provide a secure API/interface to customers to 
> provide a personal OpenPGP public key

The draft document is the "secure API" to obtain records. The IETF is
not an organisation that can tell domain providers what they must
provide to their customers.

> 2. MTAs/SPAM detection systems MUST check if the tupel "sender email address" 
> <-> "sender OpenPGP public key" matches and MUST reject the email in case it 
> does not match with signed messages to prevent address forgery and SPAM.

These are security considerations that should be discussed for

http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00

Note that I don't agree with the check you propose. I might be using a
different key for my "default email" protection, versus a manually
verified web of trust key. That is, my "default email" key might be
online and auto-decrypt on my own server, while my "web of trust" key
is completely offline- and I might not even want to publish it in DNS
or elsewhere. Although I agree that anti-spam based solutions could
surely taking signing into consideration in their determination of spam
versus ham.

> 3. Security considerations: The IANA has control over the DNSSEC root keys. 
> As the IANA is bound to US law, US government agencies probably have access 
> to the DNSSEC root keys and are capable to manipulate the OpenPGP keys signed 
> with DNSSEC.

There is currently a first attempt at specifying transparancy for
DNSSEC for those who want to audit/track the DNSSEC root or parent
domain holders:

http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Jul 2014 09:53:36 -0400 (EDT)

On Mon, 28 Jul 2014, Rene Bartsch wrote:

> Subject: [dane] Comments on draft-wouters-dane-openpgp-02

Also, please note that draft-wouters-dane-openpgp-02 was adopted by
the working group and is now proceeding as draft-ietf-dane-openpgpkey:

http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00

Paul

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Jul 2014 16:47:12 +0200 (CEST)

> email in case it does not match with signed messages to prevent address 

Terribly bad idea.  Similar to DMARC policies, such behaviour by MTA
would be a true criminal offence when performed by telecommunications
service providers under EU jurisdiction.

This is a check for the receiving MUA to perform.

-Martin

---

From: Rene Bartsch <[email-masked]>
Date: Mon, 28 Jul 2014 16:59:09 +0200

Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see 
how it would help. Consider the following case:

(Forced by secret US law) The IANA secretly hands over the current 
private key of the DNSSEC trust anchor to a US government agency which 
uses the private key to sign forged zones and feeds them to DNS 
resolvers. That way US government agencies would be able to manipulate 
any DNS record including OpenPGP while users would be lulled in a false 
sense of security.

In case I didn't miss any super-security feature users should be aware 
of that fact.

-- 
Best regards,

Renne

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Jul 2014 15:02:31 +0000

> This is a check for the receiving MUA to perform.

Laws aside, PGP is an end-to-end security mechanism, and is generally
the concern of MUAs not MTAs.  A PGP-signed message can be Resent
or forwarded via a list, and the envelope sender need not match
the message author.  Yes, I also find DMARC distasteful on technical,
rather than legal grounds.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Jul 2014 12:14:05 -0400 (EDT)

On Mon, 28 Jul 2014, Rene Bartsch wrote:

> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see how it 
> would help. Consider the following case:
>
> (Forced by secret US law) The IANA secretly hands over the current private 
> key of the DNSSEC trust anchor to a US government agency which uses the 
> private key to sign forged zones and feeds them to DNS resolvers. That way US 
> government agencies would be able to manipulate any DNS record including 
> OpenPGP while users would be lulled in a false sense of security.
>
> In case I didn't miss any super-security feature users should be aware of 
> that fact.

An audit log or reputation system would prevent the user from believing
a signed answer by a different "good" key. For the USG to take over your domain,
for which they do not have the private key, they need to take over the
parent domain and change the key listed there. That change can be
detected by you.

Paul

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Jul 2014 11:43:46 -0500

With CT the attacker has these choices:

 - compromise the target zone and its logs
 - compromise the target zone and be an MITM forever more and hope
that no one notices the logged changes

This is a significant improvement over the current situation, where
the attacker can be an undetected MITM when and as desired once they
compromise the zone.

Nico
--

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Jul 2014 13:12:44 -0400

<chair-hat> 
This discussion is off topic. 
DANE is about how to leverage DNSSEC by applications and conspiracy theories are not within our charter. 

Anyone that does not trust DNSSEC operations is free to ignore distribution of OPENPGP keys via DNS, and continue to 
use the web of trust. 
</char-hat> 

	Olafur

On Jul 28, 2014, at 10:59 AM, Rene Bartsch <[email-masked]> wrote:

> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see how it would help. Consider the following case:
> 
> (Forced by secret US law) The IANA secretly hands over the current private key of the DNSSEC trust anchor to a US government agency which uses the private key to sign forged zones and feeds them to DNS resolvers. That way US government agencies would be able to manipulate any DNS record including OpenPGP while users would be lulled in a false sense of security.
> 
> In case I didn't miss any super-security feature users should be aware of that fact.
> 
>>> 3. Security considerations: The IANA has control over the DNSSEC root keys. As the IANA is bound to US law, US government agencies probably have access to the DNSSEC root keys and are capable to manipulate the OpenPGP keys signed with DNSSEC.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Rene Bartsch <[email-masked]>
Date: Wed, 30 Jul 2014 12:15:08 +0200

Two years ago I would have thought the same. But today we are far beyond 
conspiracy theories. We are facing the biggest coordinated hacker attack 
in history of the internet. After what we've learned in the last year 
the US government has abused the trust of billions of internet users to 
gain control over the internet. We have no clue what other governments 
and intelligence angencies have done or might do. The former director of 
the austrian intelligence agency expects a lot of new disclosures in the 
next half year. Internet users worldwide are furious about the 
situation.

If we sell DANE as magic bullet without mentioning the trust anchor can 
manipulate the whole DNSSEC system and who the trust anchor is users 
will trust DANE blindly. If the trust anchor abuses control over DNSSEC 
this will blow up right into our face and harm the reputation of the 
IETF.

In my opinion we should mention the identity of the DNSSEC trust anchor 
in security considerations and we should mention the DNSSEC trust anchor 
has the possibility to manipulate the whole DNSSEC system.

Regards,

Renne

Am 2014-07-28 19:12, schrieb Olafur Gudmundsson:
> Anyone that does not trust DNSSEC operations is free to ignore
> distribution of OPENPGP keys via DNS, and continue to
> use the web of trust.
> </char-hat>
> 
> 	Olafur
> 
>> any DNS record including OpenPGP while users would be lulled in a 
>> false sense of security.
>> 
>>>> 3. Security considerations: The IANA has control over the DNSSEC 
>>>> root keys. As the IANA is bound to US law, US government agencies 
>>>> probably have access to the DNSSEC root keys and are capable to 
>>>> manipulate the OpenPGP keys signed with DNSSEC.

-- 
Best regards,

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 30 Jul 2014 12:49:26 +0000

Renne,

While it is technically true that the holder of the trust anchor could
alter key material it would be impossible to accomplish unnoticed.  In
order for a trust anchor to change your zone (say by changing an A record)
they would have to create a new private key (and corresponding public key)
then sign the altered RR set.

Your DNS key signing and zone signing keys should be protected with as
much diligence as your private signing and encryption keys.

It is as though a locksmith would have to change the locks on a house in
order to open the door.  Sure they can do it but the homeowner will notice
immediately when their keys no longer work.  My analogy breaks down if you
take it too far, but I hope it conveys the point.

I am far more worried about vectors that can be leveraged passively and
unobtrusively.

I agree that we should be open about DNSSEC/DANE however the holder of the
trust anchor can not manipulate the DNS without being detected.
-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Jul 2014 23:21:06 +1000

> trust anchor can not manipulate the DNS without being detected.

If one can intecept the packets one could fake up a world view.
This would be detectable if you have trust anchors for the parts
of the world being faked.

If one can't intercept the packets it will be almost certainly be
detected.

Maintaining a set trust anchors for all the TLD's would defeat most
of the threat.  A state agency would have to compromise multiple
tlds to pull this off not just the root.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Jul 2014 12:36:59 +0200

> tlds to pull this off not just the root.

I have the following attack in mind:

An attacker (Mallory) with access to the trust anchor keys runs a 
man-in-the-middle attack on sender and recipient. He forges the 
OPENPGPKEY RRs, the ZSK-RRs and KSK-RRs of the sender and recipient 
domains and the TLDs but uses the current origin keys of the trust 
anchor to sign the forged DNSSEC RRs.

Alice gets the OPENPGPKEY 1 of Mallory as Bob's and Bob gets the 
OPENPGPKEY 2 of Mallory as Alice's via DANE.

Alice -> OPENPGPKEY 1 of Mallory -> Mallory -> OPENPGPKEY of Bob   -> 
Bob
Bob   -> OPENPGPKEY 2 of Mallory -> Mallory -> OPENPGPKEY of Alice -> 
Alice

Unless Alice and Bob do not accidentially compare their public OpenPGP 
keys manually they won't realize the attack.

It seems DNSSEC/DANE helps against most hackers and attackers but cannot 
protect from attackers which have access to both the trust anchor keys 
and routing infrastructure.

Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver 
software?

Renne

-- 
Best regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Jul 2014 20:43:50 +1000

In message <[email-masked]>, Rene Bar
> Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver 

Yes.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jul 2014 11:10:36 -0400 (EDT)

On Thu, 31 Jul 2014, Rene Bartsch wrote:

> protect from attackers which have access to both the trust anchor keys and 
> routing infrastructure.

Whom do you trust? "No one" is not a valid answer. The best we can do is
audit/log the KSKs and do some kind of "N of M" verification that such
keys are in the public world view. Of course, that leads to small
outages during rollovers....

> Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver 

Of course. That's not so much a matter of protocol but of local policy.

Paul

---

From: Rene Bartsch <[email-masked]>
Date: Thu, 31 Jul 2014 19:36:34 +0200

Am 2014-07-31 17:10, schrieb Paul Wouters:
>> It seems DNSSEC/DANE helps against most hackers and attackers but 
>> cannot protect from attackers which have access to both the trust 
>> anchor keys and routing infrastructure.
> 
> Whom do you trust? "No one" is not a valid answer.

http://en.wikipedia.org/wiki/Bundesnachrichtendienst#History

In global communication I only trust mathematically proven algorithms. 
But don't worry, I trust people I've known for years personally. ;-)

> The best we can do is
>> Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with 
>> resolver software?
> 

In hierarchical architectures we always have a more or less trustworthy 
anchor. So we should clearly describe the security limitations in the 
security considerations section. Real security has to wait until the 
next evolution step of the internet (maybe blockchains?).

Renne

-- 
Best regards,

---

From: John Gilmore <[email-masked]>
Date: Thu, 31 Jul 2014 11:22:02 -0700

> ...

Yes, not only can anyone distribute the public keys of the TLDs, but
each TLD public key is readily accessible at any time from anywhere on
the Internet, by sending a single DNS request to any of the root servers.
This is one of the improvements that DNSSEC made, over the prior art
of public key infrastructure.

So, not only can resolver software come with a set of TLD keys, but
that software can also compare the built-in set of keys with the set
currently published online.  (And if Mallory has MITM'd Alice, she
will see discrepancies, unless Mallory has also obtained the private
zone signing key of the TLD that Alice is accessing.)

This comparison can be done when the newly installed OS first boots
and joins the Internet.  It can be done every time the OS boots.  It
can be done every time a TLD's key is used in a given day.  It can be
done by comparing keys obtained last month or last year, to keys
obtained now.  It can be done by comparing today's keys to keys
provided by one or several other servers that you personally trust
(e.g. a home machine, or one run by your company), over a connection
secured by crypto known only to you.  You can make the detection
software arbitrarily complex, which will make Mallory's job
arbitrarily complex.  It's all "a simple matter of software".

The challenge is that TLDs are *intended* to roll over their keys,
so there will always be some discrepancies between keys frozen in
a resolver software package from a few months or years ago, versus
the keys used on the live Internet.  That's why we have root keys:
to authenticate the changes in the TLD keys.

So if the root says, "This new TLD key is valid", yet it doesn't match
the local database, is it an attack, or a key rollover?  What does the
software do?  What does the user do?  Making the software pop up a
warning box at that point -- or, more stringently, fail to connect to
the intended destination, as ssh does -- will likely cause Alice to
bypass the warning or to accept the key update.  "Get out of my way,
stupid software!"  Her other option is to decline to connect, until
she can find out what's going on via some other means -- but ordinary
Alices won't do that.

Google Chrome's "key pinning" prints a big ugly message that
encourages the user to report the message to Google tech support.  But
that only works the first few times -- then Mallory learns that he
must not only forge the keys, but also prevent access to Google tech
support (or worse -- Mallory pretends to *be* Google tech support,
accepts the report, and responds with soothing reassurances that all
is well).

So, there are ways to detect key rollover / key compromise.  But
unless you think of something useful to do at that point, there is
little reason to do that work.

As with much of crypto / computer security, it is far easier to detect
and repel mass surveillance than it is to detect and repel tightly
targeted surveillance.  And luckily, this is also in line with most
people's social goals (disallow suspicionless mass surveillance, but
allow targeted surveillance with responsible, e.g. independent
judicial, oversight).  So my suggestion is that if these mechanisms
are built, they should focus on detecting mass surveillance and
reporting that to the public.  Such as IETF's Certificate Transparency
work:

  http://www.certificate-transparency.org/

or EFF's Decentralized SSL Observatory:

  https://www.eff.org/observatory
  https://www.eff.org/press/releases/new-https-everywhere-version-warns-users-about-web-security-holes

	John

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jul 2014 14:29:11 -0400 (EDT)

On Thu, 31 Jul 2014, John Gilmore wrote:

> software do?  What does the user do?
>

That's what transaparancy for DNSSEC is about that is being discussed in
the trans working group now. It's stil in the preliminairy stages, and
likely will take a back seat to the more urgent certificate transparency
which needs an audit log much more than DNSSEC.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 31 Jul 2014 15:29:08 -0400

John,
> of public key infrastructure.
If generic PKIs could assume a single TA, then the same model has
always been possible. DNS has the advantage of having a single
root, and a robust infrastructure supporting distribution of data
about the next tier of the DNS.  This allows DNSSEC to offer the
functionality you describe. it is not an improvement over the prior
art of PKI.

Steve

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Jul 2014 14:44:15 -0500

> which needs an audit log much more than DNSSEC.

And which is a good chance to remind everyone that this topic is
off-topic here.  This should be discussed there [trans].

Nico
--