On Wed, Sep 14, 2011 at 1:38 PM, Daniel Kahn Gillmor
wrote:
>
> I personally like this approach and i use multiple keys for different
> hosts serving the same domain for at least one domain i administer
> myself. i also note that it is diametrically opposed to your earlier
> stated goal of avoidi
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 virtual hosts such that t
They claimed 600 CAs on the Internet.
Their claim was disproved, the intermediate roots are not under direct
control of the customers.
They did not retract or clarify
That is not how reputable academics do their work. They were making a
political statement using Fox News type tactics.
On Wed,
On Wed, Sep 14, 2011 at 11:13 AM, Daniel Kahn Gillmor wrote:
> 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 pe
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
>> single customer that are managed in the sa
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
One technical point, have you considered the ODI mechanism that we developed
for CAA up to the -01 version when the client enforcement bit got kiboshed?
The name is confuising, but lets say we call it the DIGEST URI type and the
digest data consists of
DIGEST: < Base64 ( + + )
The idea was tha
On Wed, Sep 14, 2011 at 9:15 AM, Daniel Kahn Gillmor
wrote:
> 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.
Or maybe DANE should consider migrating to the WEBSEC approach.
I was pushing for DANE to consider the pinning and 'must be SSL' approach
from the start. The consensus of the group has been that they don't want to
consider those use cases at all. Furthermore the response I have got from
the key co
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
>> mechanism (and nice instructions,
I totally agree that this is a feasible attack. It has been seen on a very
large scale, Russia did a BGP redirect at a country level in their dispute
with Georgia.
DNSSEC on A records alone is practically worthless. There is some value but
not a great deal. Most DNS attacks have been persuading re
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
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
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
On Sep 13, 2011, at 3:54 AM, Richard L. Barnes wrote:
> Hey Chris & Chris,
>
> This seems like a useful near-term approach, but also probably something that
> might want to migrate to DANE over time.
>
> Is there any particular reason you're using key fingerprints instead of cert
> fingerprin
On 09/12/2011 04:56 PM, Chris Palmer wrote:
Hi all,
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
> > Is there any particular reason you're using key fingerprints instead of cert
> > fingerprints? It seems like the latter might be slightly easier to
> > implement, since you don't have to parse the cert.
>
> I assume it's because the certificates public keys are embedded within, in
> practice
rbar...@bbn.com said:
>
> This seems like a useful near-term approach, but also probably something that
> might want to migrate to DANE over time.
sure, tho it's going to take a while (eg before browsers hard-fail on
assurances sourced via Secure DNS). See..
[dane] A browser's myopic view
http
Hi Chris,
At 14:56 12-09-2011, Chris Palmer 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
[snip]
We eagerly anticipate your comments, questions, concerns, et c. As you
Would it be possible for
Hey Chris & Chris,
This seems like a useful near-term approach, but also probably something that
might want to migrate to DANE over time.
Is there any particular reason you're using key fingerprints instead of cert
fingerprints? It seems like the latter might be slightly easier to implement,
> 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 least one of the
> public keys identif
49 matches
Mail list logo
