Live data from Hacker News

Adam Langley's Pond: Secure Async Messaging

pond.imperialviolet.org

21–30 of 43 posts

Re: Adam Langley's Pond: Secure Async Messaging

#21
post #10
post #4

I can not forgive Adam he removed the DANE support from Chrome in spite of fact that he was the author of the draft standard http://datatracker.ietf.org/wg/dane/

Why does Langley need your forgiveness for not supporting DANE? DANE is arguably worse than X.509 CAs.

How is it worse than X.509?

Re: Adam Langley's Pond: Secure Async Messaging

#22
post #10
post #4

I can not forgive Adam he removed the DANE support from Chrome in spite of fact that he was the author of the draft standard http://datatracker.ietf.org/wg/dane/

Why does Langley need your forgiveness for not supporting DANE? DANE is arguably worse than X.509 CAs.

How is it worse than X.509?

Re: Adam Langley's Pond: Secure Async Messaging

#23
post #10
post #4

I can not forgive Adam he removed the DANE support from Chrome in spite of fact that he was the author of the draft standard http://datatracker.ietf.org/wg/dane/

Why does Langley need your forgiveness for not supporting DANE? DANE is arguably worse than X.509 CAs.

How is it worse than X.509?

Re: Adam Langley's Pond: Secure Async Messaging

#24
post #10
post #4

I can not forgive Adam he removed the DANE support from Chrome in spite of fact that he was the author of the draft standard http://datatracker.ietf.org/wg/dane/

Why does Langley need your forgiveness for not supporting DANE? DANE is arguably worse than X.509 CAs.

How is it worse than X.509?

Re: Adam Langley's Pond: Secure Async Messaging

#26
post #10
post #4

I can not forgive Adam he removed the DANE support from Chrome in spite of fact that he was the author of the draft standard http://datatracker.ietf.org/wg/dane/

Why does Langley need your forgiveness for not supporting DANE? DANE is arguably worse than X.509 CAs.

Why? Because DNSSEC can be attacked by the DNS root?

It seemed to be our best attempt to get SSL for every website. CA-based certificates just won't cut it.

Re: Adam Langley's Pond: Secure Async Messaging

#27
post #5

> "Pond seeks to prevent leaking traffic information against everyone except a global passive attacker." My favorite line in the article. It's a nice nod to the fact that this Achilles heel is an issue that he is aware of / takes seriously.

Contrasted with the "forward": |Note: recent events have lead to these topics being in the news quite often in recent weeks. However, Pond is not a reaction to those events - it was started nearly a year ago. Traffic information, of course, isn't the whole conversation, so his wit is appreciated to make light air of the situation, but at the same time he's quite serious about this little project. I'm impressed that i…

There's a paper from the 1990s (https://gnunet.org/sites/default/files/10.1.1.43.4892.pdf I think, Pfitzmann 1991) on building an ISDN MIX for anonymous real-time voice traffic. ISDN gives you two 56kbps or 64kbps channels in each direction for voice, which you can connect to whoever you want. So you just keep these channels open to somebody all the time and keep them full of data, even if it's nonsense. Using fully isochronous streams in this way, assuming a fully connected directed graph, which is overwhelmingly probable, it's impossible for a global passive attacker to determine anything at all about who is actually talking to whom, or how much; the traffic pattern simply is not affected by the communication graph.

A thing I don't know is whether Pfitzmann et al.'s scheme held up to subsequent analysis. I haven't even read the whole paper, actually.

Re: Adam Langley's Pond: Secure Async Messaging

#28

(Or, how to better organise a discreet relationship with the Director of the CIA.) from https://github.com/agl/pond (the source) is a good elevator pitch, for people (like me) who are taking their time getting what this is. also, is code like this https://github.com/agl/pond/blob/master/server/server.go#L15... just extreme defensive programming? or is there some other reason for the check (eg is not everything locked…

I think it's just that nobody knows the answers, mostly. HN is not great for questions that require thought.

Also, btw, I still have your AMOP,a nd it would be awesome to see you again.

Re: Adam Langley's Pond: Secure Async Messaging

#30
post #20
post #19

Earlier quoted context omitted.

Good to know. I knew that I needed to do it, but I'll be sure to add support for this prior to Go 1.2. (The TLS stack doesn't support renegotiation at all, so it's not vulnerable, but a client can't know that unless it echos the extension in question.)

Ah, you're using the Go TLS package? That makes sense ;-). As it turns out the latest version of Firefox still connects to servers which don't indicate secure renegotiation; the parent poster caused the problem by mucking around with the TLS settings in about:config.

Well, it looks like he wrote the Go TLS package.
Post reply on HN