On Sep 14, 2011, at 2:06 AM, SM wrote:
> Hi Yoav,
> At 11:41 13-09-2011, Yoav Nir wrote:
>> Six months ago we would not have thought that Comodo or DigiNotar
>> were easy to hack. In the latter case, the customers of DigiNotar
>> were left out in the cold. Without
>
> "The DigiNotar partners
Hi all,
Unfortunately I didn't finish the new, XMLified rev of the document
today — you raised too many difficult questions. :) It's coming along
though. I might be able to get it to the list tomorrow, but I might
end up dedicating tomorrow to a different (but related) code-writing
effort, hence w
Hi Yoav,
At 11:41 13-09-2011, Yoav Nir wrote:
Six months ago we would not have thought that Comodo or DigiNotar
were easy to hack. In the latter case, the customers of DigiNotar
were left out in the cold. Without
"The DigiNotar partnership has laid down its security policy in
action protoco
Hello dear websec fellows,
to decide on a slot and length for our meeting in November in Taipei,
this time we would like to start a bit earlier asking for presentations,
topics and ideas.
Please send proposals and ideas for presentations to Alexey, Yoav and/or
me, if possible until Sep-25 so
On 13 Sep 2011, at 23:30, Marsh Ray wrote:
>
> Wouldn't they have to acquire a valid cert first? Not saying that's out of
> the realm of possibility, but...
Yeah, but in the case that you've gained control of a domains DNS, which is
what happened, how hard would it be to get a valid DV cert?__
I think that all this pinning stuff works a lot better if there is a
mechanism that allows a return to ground truth.
Since we are developing an Internet protocol, the mechanism for ground truth
should be DNS in my opinion.
It may be impractical to require DNSSEC secured responses in every case.
On 09/13/2011 04:24 PM, davidills...@gmail.com wrote:
On 13 Sep 2011, at 21:35, Chris Palmer wrote:
sites; small sites may have to choose no pinning or potentially
bricking their site (up to the maxAge window). This is not worse than
the status quo."""
What about sites which don't currently
On Tue, Sep 13, 2011 at 7:04 AM, Philip Gladstone wrote:
[ snip questions about revocation — I'm trying to think about and
clarify that stuff next ]
> Does this proposal also support self-signed certificates? I.e. if you
> connect to a site, accept the self-signed certificate, can that site then
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
> mechanism (and nice instructions, thanks) for transition to an emergency
> offline bac
I think we have a potential convergence here between four sets of security
policy data and four delivery mechanisms:
A) Revocation information for certs/roots
B) Security protocol policy 'MUST USE TLS'
C) Security Trust Policy 'use only this CA'
D) Reporting
1) Data baked into the browser
2) Data
On 13 Sep 2011, at 21:35, Chris Palmer wrote:
>
> sites; small sites may have to choose no pinning or potentially
> bricking their site (up to the maxAge window). This is not worse than
> the status quo."""
What about sites which don't currently use https at all? The DNS records for
theregister
That is a good point.
But in the Diginotar case the CA root was revoked so that could be dealt
with by saying that a client should unpin a cert when it has been revoked
(or part of the chain has been revoked).
Another tool that we could use here is to push out an 'unpin' statement in
whatever mec
On Tue, Sep 13, 2011 at 1:06 PM, Marsh Ray wrote:
> Q: What kind of pinning would we recommend to our friend or family member
> who runs his business on the web?
> Right now he has his domain registration and cert from GoDaddy.
They could also buy a cert from StartSSL, and keep it on a USB token
On 09/13/2011 03:38 PM, Gervase Markham wrote:
On 13/09/11 13:06, Marsh Ray wrote:
Or not, like the Dutch government, have the pull to convince Mozilla to
hesitate for a few days to revoke your pwned CA.
That is rather unfair. You make it sound like they asked, and we
complied. In truth, we re
> -Original Message-
> From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On
> Behalf Of Marsh Ray
>
> What if they maliciously pinned you to a floundering CA?
What is they compromised your DNS server and sent out bogus A records with a
crazy long TTL?
I think trying to ma
On 13/09/11 13:06, Marsh Ray wrote:
> Or not, like the Dutch government, have the pull to convince Mozilla to
> hesitate for a few days to revoke your pwned CA.
That is rather unfair. You make it sound like they asked, and we
complied. In truth, we relied on an assessment of the situation from
Gov
On Tue, Sep 13, 2011 at 12:37 PM, Daniel Kahn Gillmor
wrote:
> So certificate pinning isn't bad in this case -- CA Certificate pinning
> is bad.
Not even that, really. Pinning your CA and not having a backup pin
that chains up to a different CA is the bad thing.
_
On Tue, Sep 13, 2011 at 11:41 AM, Yoav Nir wrote:
> Six months ago we would not have thought that Comodo
> or DigiNotar were easy to hack. In the latter case, the
> customers of DigiNotar were left out in the cold. Without
> certificate pinning, they just need to spend money on a
> new certificat
Just thinking out loud here.
On 09/13/2011 01:41 PM, Yoav Nir wrote:
Locking yourself into a CA like that seems like a bad idea. Unlike
the Dutch government and Mozilla, most customers do not have the pull
to force CAs to submit to audits.
Or not, like the Dutch government, have the pull to
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
On Sep 13, 2011, at 9:15 PM, Peter Saint-Andre wrote:
> On 9/12/11 5:53 PM, =JeffH wrote:
>>
>> This is great, thanks for posting this here.
>>
>> I have various comments on it I'll try to get to in the next day or so.
>>
>> During HSTS's gestation, various parties have discussed potential
>>
StPeter said..
>
> On 9/12/11 5:53 PM, =JeffH wrote:
>>> Chris Evans and I work at Google on the Chrome security team. We have
>>> devised this specification for a new extension to Strict Transport
>>> Security to allow site operators to "pin" certificates: UAs will
>>> require that TLS connection
On 9/12/11 5:53 PM, =JeffH wrote:
>> Chris Evans and I work at Google on the Chrome security team. We have
>> devised this specification for a new extension to Strict Transport
>> Security to allow site operators to "pin" certificates: UAs will
>> require that TLS connections be validated with at l
Hi everybody,
Thanks for your comments and questions — good ones! I'll try to
address them in the XMLified draft that I'm working on now, and which
I'll send out today.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
On Mon, Sep 12, 2011 at 4:53 PM, =JeffH wrote:
> I've taken the liberty of re-formatting the document in plain text
> (attached), which will better facilitate discussion hereabouts. A next step
> will be to re-format it as an Internet-Draft and get it submitted (I
> volunteer to help you out with
Of interest given the presentation in Prague...
-- Forwarded Message
From: Thomas Roessler
Date: Tue, 13 Sep 2011 09:05:31 -0700
To: "Aleecia M. McDonald" , Nick Doty
Cc: Thomas Roessler
Subject: Launching the Tracking Protection WG Conference call invitation:
14 September at 8 am Pacifi
On 9/13/2011 8:10 AM, Tom Ritter wrote:
I find the Revocation section very confusingly written.
> "In the event of a mismatch, clients must check whatever revocation
mechanism is available and attempt to discover whether the certificate
with the mismatching fingerprint has been revoked."
Wha
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
I echo Marsh's question. Does a x509 Key Fingerprint include
basicConstraints? I couldn't imagine a scenario where an attacker could get
his own cert signed by a leaf cert of a website - but I also couldn't
imagine New York getting hit by an earthquake ;)
Other observations:
I find the Revocati
Hi Chris and Chris,
I like the idea, too. And would very much second the thought of putting
this down in the form of an Internet-Draft. Especially with the CA
problems we have seen in the last few months, this is important and
could be a great addition to HSTS in the websec WG.
If you cons
On Tue, Sep 13, 2011 at 6:41 AM, James Nicoll wrote:
> I was under the impression that this wasn't a good idea, as periodic
> replacement of the keys was done incase of an undetected compromise?
One typically pins, at least, to a CA which allows a site to rotate
its keys without issue so long as
I was under the impression that this wasn't a good idea, as periodic
replacement of the keys was done incase of an undetected compromise?
Ross
On 13/09/2011 06:53, "Yoav Nir" wrote:
>1. Sometimes certificates are renewed periodically with the same public
>key. This is very common for sub-CAs a
On Tue, Sep 13, 2011 at 1:53 AM, Yoav Nir wrote:
> I can think of two reasons.
You're basically right. Quoting from my
http://www.imperialviolet.org/2011/05/04/pinning.html
"In general, hashing certificates is the obvious solution, but the
wrong one. The problem is that CA certificates are often
33 matches
Mail list logo
