Hi Jeffrey--
I share your concerns about MitM attacks on the web, and I'm also not
happy about the compromises made in HPKP about "locally-installed" trust
roots, fwiw.
But i don't think your arguments are helping.
On Sat 2015-02-21 21:38:20 -0500, Jeffrey Walton wrote:
> You'll have to forgive
On 12/17/2014 03:38 PM, Stephane Bortzmeyer wrote:
> On Wed, Dec 17, 2014 at 11:51:08AM -0800,
> David Keeler wrote
> a message of 47 lines which said:
>
>> Section 11.3 is about when the user agent connects to a host that it
>> previously noted as using HSTS.
>
> OK, so a example case with s
On 11/07/2014 01:56 AM, Xiaoyin Liu wrote:
> So I want to propose a update to RFC 6797 to define a new directive called
> "infinite" (or something else). When a UA sees this directive, max-age
> should be ignored and HSTS should always be enforced until users clear the
> cache or the server send
On 04/28/2014 07:04 PM, Chris Palmer wrote:
> Well, it's hard to draft text that reads well. There are a lot of
> hypotheticals:
>
> * A new version of this spec has been published that specifies BetterHash.
>
> * Separately, SHA256 becomes deemed unsafe.
>
> * Some site operators would rather
On 04/24/2014 03:24 PM, Ryan Sleevi wrote:
> I don't agree that pinning the EE's signer is necessarily good advice -
> CAs regularly rotate their intermediates (eg: for CRL partitioning), so
> it's hard to suggest that's a good, long-term stable solution.
just wanted to give real-world confirmati
On 04/04/2014 06:14 PM, Chris Palmer wrote:
> On Sat, Feb 22, 2014 at 10:49 AM, Daniel Kahn Gillmor
> wrote:
>
>> I also think that (b) (unpinning) is the right answer here, considering
>> the semantics of the decision.
>>
>> Consider it this way:
>>
>
On Sat 2014-02-22 13:49:10 -0500, Daniel Kahn Gillmor wrote:
> 0) if a site operator decides to use more than one hash algorithms in
> the future, do we require that they issue the same set of pins under
> each algorithm? So if i'm pinning keys X and Y and Z, and i'm using
On 03/21/2014 03:49 PM, Hill, Brad wrote:
> WebSec WG members,
>
> The WebAppSec WG at the W3C has recently announced a First Public Working
> Draft for "Subresource Integrity".
>
> http://www.w3.org/TR/SRI/
>
> This specification describes a method to add metadata about the hash
> identit
On 02/27/2014 03:31 PM, Trevor Perrin wrote:
> 1) PKP-RO implements the full PKP semantics (i.e. is stored for max-age,
> is applied to includeSubdomains), but only generates reports instead of
> hard fails. The browser would store PKP and PKP-RO pins in
> separate/parallel stores, for example se
On 02/21/2014 03:58 PM, Tobias Gondrom wrote:
>> (a) ignore it, keeping the old pin, or (b) treat this as unpinning?
> in case of an unrecognised pin-shaX, scenario (a) would result in a
> potentially dangerous situation, that can brick the site, i.e. make it
> unavailable.
> If the new pin is ig
On 01/20/2014 01:57 PM, Chris Palmer wrote:
> On Mon, Jan 20, 2014 at 7:44 AM, Daniel Kahn Gillmor
> wrote:
>
>> In 6125 and the two e-mail drafts above, "pinning" is used to refer to
>> the activity that firefox describes as "adding a security exception&
On 01/20/2014 06:51 AM, Alexey Melnikov wrote:
> http://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/
> http://datatracker.ietf.org/doc/draft-moore-email-tls/
Both of these drafts use the term "pinning" in line with the way it is
used in RFC 6125, which is in contradiction to the way th
On 07/31/2013 11:22 PM, Trevor Perrin wrote:
> If other people want to write their own specs to add data into it,
> that's great - it's a convenient single place for browsers and web
> crawlers to find security policy for a site.
I'm finding myself more and more convinced by the well-known URI
su
On 07/11/2013 03:37 PM, Yoav Nir wrote:
> I would still be able to make a form that would cause a POST. It's just a
> matter of getting the user to click a button, no? I think I could also do it
> in Javascript.
Which is why you need CSRF protection, as i mentioned.
>
> They don't have to. I
On 07/11/2013 02:41 PM, Yoav Nir wrote:
>
> * GET /maingage.html?button=shutdown caused the firewall to power-off.
> * GET /mainpage.html?button=unload caused the firewall to unload
> policy, so that it didn't enforce policy or do IPsec or anything a router
> wouldn't do.
>
> So
On 05/22/2013 06:52 PM, Ryan Sleevi wrote:
> The view is that it's still a legitimate error for the site operator, in
> that any user without HSTS protections (or with expired HSTS) is still at
> risk. While HSTS may be providing protection to the user, the site itself
> is still configured to serv
hi websec folks--
I am wondering what people think the proper intersection is between a
web browser's mixed-content warnings and HSTS.
For example, if https://example.net has asserted
Strict-Transport-Security: max-age=15768000 but the homepage at
https://example.net/ also contains
http://exam
On 03/04/2013 07:57 PM, Ryan Sleevi wrote:
> As discussed during Atlanta, the way that pinning is currently implemented
> within Google Chrome, pinning is only enforced as it relates to so-called
> "public trust anchors" (eg: those shipped by default as part of a browser
> or OS installation, not t
On 09/14/2011 12:44 PM, Phillip Hallam-Baker wrote:
> On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor > wrote:
> I really hate having private keys move off a host.
>
> If people are going to be doing that pattern of hosting I would prefer to
> have keys tied to the virtu
On 09/14/2011 11:13 AM, Daniel Kahn Gillmor wrote:
>> This is why the bogus EFF study came up
>> with the absurd number of 600 CAs. What they have never come clean on is the
>> fact that 150 of those 'CAs' are in fact merely intermediate roots tied to a
>> singl
On 09/14/2011 09:46 AM, Phillip Hallam-Baker wrote:
> It gives you scaling and administrative convenience.
>
> If you have 10,000 hosts in your enterprise network you really do not want
> to have to be managing trust on a per host level.
You're not "managing trust on a per host level" -- you're m
On 09/13/2011 05:55 PM, Chris Palmer wrote:
> On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor
> wrote:
>
>> From my perspective, i see no advantage to pinning any of the CAs -- if
>> your EE is compromised, you're sunk. And since the mechanism provides a
>>
On 09/13/2011 02:41 PM, Yoav Nir wrote:
> the customers of DigiNotar were left
> out in the cold. Without certificate pinning, they just need to spend
> money on a new certificate and their site is working again. With it,
> they are in trouble.
With *CA* pinning, DigiNotar customers are defini
Thanks for publishing this spec, Chrises!
On 09/12/2011 05:56 PM, Chris Palmer wrote:
> (Sites can pin to one or more public keys in end entity, subordinate
> CA, and/or root CA certificates, for flexibility and disaster
> recovery.)
I think more discussion about the relative consequences of pi
24 matches
Mail list logo
