On Fri, 24 Aug 2012 23:51:27 -0400
Ryan Kirk wrote:
> You're definitely on track, although I was referring to D.J.
> Bernstein's recent slides: http://cr.yp.to/talks/2012.06.04/slides.pdf
>
Thanks, I'll take a gander.
> In these, he does bring up the same problems again that his DNSCURVE
> purp
You're definitely on track, although I was referring to D.J.
Bernstein's recent slides: http://cr.yp.to/talks/2012.06.04/slides.pdf
In these, he does bring up the same problems again that his DNSCURVE
purported to solve, about weak algorithms, signing (or lack of),
forgeries, and UDP amplification
> However,
> this would require DNSSEC to be secure (which itself seems to be mired
> in controvery lately, not to mention the slow rate of adoption)
Do you have a reference for that. I know of the controversy around
DNSCURVE before DNSSEC even arrived but haven't seen any of late. Is it
to do wit
On 08/23/12 20:05, Ted Unangst wrote:
> On Thu, Aug 23, 2012 at 13:12, Ryan Kirk wrote:
>> One thing I've never understood is that if you're MITM'd, what good is
>> a cert revocation going to do? The proxying individual can easily
>> block access to the revocation lists, and your browser be none th
On Thu, Aug 23, 2012 at 13:12, Ryan Kirk wrote:
> One thing I've never understood is that if you're MITM'd, what good is
> a cert revocation going to do? The proxying individual can easily
> block access to the revocation lists, and your browser be none the
> wiser.
hahaha, I've seen exactly one p
On Thu, Aug 23, 2012 at 12:08 PM, Ted Unangst wrote:
people designing the protocol never got that far.
>
> Anyway the workaround du jour is certificate pinning. Your browser is
> supposed to remember the cert used for the previous connection and
> warn if it changes, which reduces the window of o
On Thu, Aug 23, 2012 at 01:37, Justin N. Lindberg wrote:
> So why isn't there a good way for an end user to strictly limit trust
> in, for example, a "Google Internet Authority" to those domains that
> are actually owned by Google, and conversely, not to trust any other
> authority to sign certs
On Sun, 12 Aug 2012 13:29:57 -0400
Nico Kadel-Garcia wrote:
> Such certificates have already been stolen. They're dependent on the
> security of the intermediate key owners, and the are demonstrably
> unsecure: Check this URL for more details on the release of rogue SSL
> signing certificates thr
On Thu, Aug 9, 2012 at 3:22 PM, Justin N. Lindberg
wrote:
> On Thu, 09 Aug 2012 09:18:00 +0200
> Moritz Grimm wrote:
>
>> You always put trust into the whole chain (that's why you need
>> intermediate certs in the first place), starting with your trusted
>> root. If that trust turns out to be mis
On Thu, 09 Aug 2012 09:18:00 +0200
Moritz Grimm wrote:
> You always put trust into the whole chain (that's why you need
> intermediate certs in the first place), starting with your trusted
> root. If that trust turns out to be misplaced in any one of the
> components (root, intermediate, server),
Moved from tech@ to misc@ ...
On 08/09/12 06:27, Justin N. Lindberg wrote:
> I do believe this would allow me as a client to validate certs signed
> by the intermediate certs with no problem, and in fact I seem to recall
> actually doing the same thing before with self-signed certs for my own
> u
11 matches
Mail list logo
