Re: [Cryptography] Opening Discussion: Speculation on BULLRUN

2013-09-10 Thread Joe Abley

On 2013-09-09, at 12:04, Salz, Rich rs...@akamai.com wrote:

 ➢  then maybe it's not such a silly accusation to think that root CAs are 
 routinely distributed to multinational secret
 ➢  services to perform MITM session decryption on any form of communication 
 that derives its security from the CA PKI.
 
 How would this work, in practice?

Suppose Mallory has access to the private keys of CAs which are in the 
browser list or otherwise widely-trusted.

An on-path attack between Alice and Bob would allow Mallory to terminate 
Alice's TLS connection, presenting an opportunistically-generated server-side 
certificate with signatures that allow it to be trusted by Alice without 
pop-ups and warnings. Instantiating a corresponding session with Bob and ALGing 
the plaintext through with interception is then straightforward.

This would be detectable by Bob by the visible client address, but that could 
be obfuscated (Mallory could exit the session through something tor-like, for 
example, to avoid advertising their topological location; this would just make 
it look like Alice is using tor).

In the case where Alice is presenting a certificate specifically trusted by 
Bob, this wouldn't work so well. But my observation is that many TLS-protected 
streams used by consumers don't use client certificate authentication.

As an aside, I see CAs with Chinese organisation names in my browser list. I 
don't know how to distinguish between enterprises and government from this side 
of the Pacific (so, presumably, assume they are all government). I had always 
assumed that this was already happening at the Great Firewall, as a working 
example of government-sponsored TLS interception with no requirement for 
expensive crunching of large integers.


Joe
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Re: [Cryptography] PGP Key Signing parties

2013-10-11 Thread Joe Abley

On 2013-10-11, at 07:03, Tony Naggs tonyna...@gmail.com wrote:

 On 10 October 2013 22:31, John Gilmore g...@toad.com wrote:
 Does PGP have any particular support for key signing parties built in or is
 this just something that has grown up as a practice of use?
 
 It's just a practice.  I agree that building a small amount of automation
 for key signing parties would improve the web of trust.
 
 Do key signing parties even happen much anymore? The last time I saw
 one advertised was around PGP 2.6!

The most recent key signing party I attended was five days ago (DNS-OARC 
meeting in Phoenix, AZ). I commonly have half a dozen opportunities to 
participate in key signing parties during a typical year's travel schedule to 
workshops, conferences and other meetings. This is not uncommon in the circles 
I work in (netops, dnsops).

My habit before signing anything is generally at least to have had a 
conversation with someone, observed their interactions with people I do know (I 
generally have worked with other people at the party). I'll check 
government-issued IDs, but I'm aware that I am not an expert in counterfeit 
passports and I never feel like that I am able to do a good job at it.

(I showed up to a key signing party at the IETF once with a New Zealand 
passport, a Canadian passport, a British passport, an expired Canadian 
permanent-resident card, three driving licences and a Canadian health card, and 
offered the bundle to anybody who cared to review them to make this easier for 
others. But that was mainly showing off.)

I have used key ceremonies to poison edges and nodes in the graph of trust 
following observations that particular individuals don't do a good enough job 
of this, or that (in some cases) they appear to have made signatures at an 
event where I was present and I know they were not. That's a useful adjunct to 
a key ceremony (I think) that many people ignore. The web of trust can also be 
a useful web of distrust.


Joe

___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography