DANE's nice, but it effectively required DNSSEC, no? <br><br><div class="gmail_quote">On Tue, Sep 6, 2011 at 8:15 PM, Robert Malmgren <span dir="ltr"><<a href="mailto:rom@romab.com">rom@romab.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
On 9/7/11 1:36 AM, Larry Seltzer wrote:
<blockquote type="cite">I've never heard of pinning before. There is a
proposed IETF spec for a DNS record to specify an authorized CA: <a href="http://tools.ietf.org/html/draft-hallambaker-donotissue-03" target="_blank">http://tools.ietf.org/html/draft-hallambaker-donotissue-03</a>
<div>
<br>
</div>
<div>Some big names on it, but I'm not sure it's actually gone
anywhere.</div>
<div><br>
</div>
</blockquote>
<br>
Check out the DANE specification<br>
<br>
<a href="https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1</a><br>
<br>
That, maybe together with HASTLS, is another mechanism to allow the
certificate holder to tell the world what they should know about the
original provider/signer of the certificate.<br>
<br>
<br>
<blockquote type="cite">
<div>LJS<br>
<div><br>
</div>
</div>
</blockquote>
<br>
--r<br>
<br>
<blockquote type="cite">
<div>
<div><br>
<div class="gmail_quote">On Mon, Sep 5, 2011 at 7:35 PM, Ian G
<span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
5/09/11 7:23 PM, Gervase Markham wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The thing which makes the entire system as weak as its
weakest link is<br>
the lack of CA pinning.<br>
</blockquote>
<br>
<br>
Just a question of understanding: how is the CA pinning
information delivered to the browser?<br>
<br>
(For those who don't know, I also had to look it up too :)
CA pinning is where a particular CA is the only one
permitted to issue certs for a website. I think, it's a
very new feature, in some browsers only?)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An HSM or smart card that does anything the PC that
it's attached to tells<br>
it to is only slightly more secure than simply
storing the key directly on<br>
the PC. You need to do more to secure a high-value
signing process than<br>
sprinkling smart card/HSM pixie dust around and
declaring victory.<br>
</blockquote>
<br>
This is true, but I'm not sure it's particularly
relevant.<br>
</blockquote>
<br>
Well, what's relevant is whether the security processes
are doing the job. Evidence over the last year says no.
Why?<br>
<br>
What Peter's saying is that there are signs that the
processes are weaker than they appear. One clue is when
they go for expensive solutions rather than smart
solutions, and declare it done.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Who claims<br>
that HSMs are magic pixie dust?)<br>
</blockquote>
<br>
CABForum, in BR15.6. "CA must use a HSM" approx.<br>
<br>
Monkey-see-monkey-do. Which, amusingly, contradicts most
of the rest of section 15 :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lack of breach disclosure requirements for CAs means
that they'll cover<br>
problems up if they can get away with it:<br>
</blockquote>
<br>
Do you think that remains true?<br>
</blockquote>
<br>
We don't know. There is no full disclosure mechanism, so
we don't know what is disclosed and what not. and even
when the full disclosure mechanism is in place, we'll need
20 or so events to gain confidence in it.<br>
<br>
Recall SB1386? It actually didn't do anything until 2
years had passed. Then someone paniced. And attitudes
shifted...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Comodo didn't cover their problems up,<br>
</blockquote>
<br>
Have they released the full report of the issue? Has
Mozilla?<br>
<br>
Or do we just know the headline, and what people have dug
up against their best wishes?<br>
<br>
You saw the chat on mozilla list, another CA declined to
report, dressed up by lots of buts, ifs, maybes, not-us's
and other rantings.<br>
<br>
Non-disclosure is certainly in place.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and are still in business. DigiNotar covered theirs up,
and are not.<br>
Covering up is a massive business gamble, because if
anyone finds the<br>
certs in the wild (as happened here), you are toast.
Particularly given<br>
that browsers are deploying more technologies like
pinning which makes<br>
this sort of attack easier to find, it would be a brave
CA who covered a<br>
breach up after the lesson we had last week. You'd have
to be pretty<br>
darn confident any misissued certs didn't get obtained
by the attackers<br>
- and if they didn't get out, is there actually a
problem?<br>
</blockquote>
<br>
<br>
What is of current concern is that CAs may now be
"disclosing" to the vendors. And calling that disclosure.<br>
<br>
This is of concern for several reasons: firstly, it
likely puts the vendors in a very difficult position, even
to the point of corrupting them. Secondly, it creates a
liability-shifting mechanism: the broken CA can now point
to this as its industry-standard disclosure mechanism
(regardless of utility and user damages) which reduces its
own liability, without a commensurate payment; and the
vendor now has to take on the risk of suits. Thirdly,
it's being done in an ad hoc knee jerk fashion, again in
secret, and there is no particular faith that the parties
involved will be able to keep their interests of the
table.<br>
<br>
(For Mozilla alone, private disclosure goes against their
principles.)<br>
<br>
I'm not denying that disclosure to vendors may help. But
I have no faith in the risk managers at the other side to
analyse that risk.<br>
<br>
If you feel that they can do a good job, post their risk
analysis.<br>
<br>
Right, I thought so, they haven't done one. All vendors
are in breach of BR. Doesn't auger well does it :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
there's nothing protecting the user. Even the most
trivial checks by<br>
browsers would have caught the fake Google wildcard
cert that started all<br>
this.<br>
</blockquote>
<br>
What sort of "trivial checks" are you suggesting?<br>
</blockquote>
<br>
Perhaps CA pinning! But in the browser :)<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Diginotar both passed audits in order to get on the
browser gravy train and<br>
then passed a second level of auditing after the
compromise was discovered.<br>
The auditors somehow missed that fact that the
Diginotar site showed a two-<br>
year history of compromise by multiple hacking
groups, something that a<br>
bunch of random commentators on blogs had no problem
finding.<br>
</blockquote>
<br>
I think there are definitely searching questions to ask
of DigiNotar's<br>
auditors.<br>
</blockquote>
<br>
:) and, any other CA audited by that organisation. And
any CA audited to that standard....<br>
<br>
And ... wait, all of them! Oops!<br>
<br>
Short story -- you won't be able to blame the auditor for
this.<br>
<br>
Sure, you can embarrass them a lot! But, it's pretty
obvious on one reading of webtrust that it's a farce.
It's also pretty obvious reading BR that an audit would
not have picked this up.<br>
<br>
We could do it ten times over and it's still be the same
thing. Audit isn't up to solving this problem, it's only
up to lifting the basic game of low-end CAs to some
reasonable best-practices level at the governance side.<br>
<br>
(Another sign that the processes aren't doing the job is
that CABForum's solution is to add more audits. We're up
to 4, now, right? WebTrust, BR, EV, vendor. Would 5 do
it? 6?)<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
available. There is no fallback. Site owners who are
concerned about the<br>
security of their users can't do anything, because
the browser vendors have<br>
chosen to prevent them from employing any other
option (I can't, for<br>
example, turn on TLS-PSK or TLS-SRP in my server,
because no browsers<br>
support it - it would make the CAs look bad if it
were deployed).<br>
</blockquote>
<br>
Patches welcome? (Or did we reject them already? :-)<br>
</blockquote>
<br>
Yep, I'm afraid that's the case ;)<br>
<br>
It's at the attitude level, not any particular patch.
Patches aren't welcome. E.g., CA pinning was proposed in
the mid-00s and people were told to go away. And take
their code with them...<br>
<br>
I mean, we could be wrong. But who's going to take the
chance and spend a month on code, or a year, only to be
told no? Again? Who's gonna bother to fight through the
human-shield to get to the coders?<br>
<br>
It's up to the vendors, really. We wait and we watch and
we groan.<br>
<br>
<br>
<br>
iang<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote><font color="#888888">
<br>
<br>
<pre cols="72">--
---
Robert Malmgren Encrypted e-mail preferred
E-mail: <a href="mailto:rom@romab.com" target="_blank">rom@romab.com</a> PGP RSA 4096, id: 0x5B979EF5
Cellular: <a href="tel:%2B46%280%29708-330378" value="+46708330378" target="_blank">+46(0)708-330378</a> Fingerprint: DE59 D86C 4CAF 2E59 A64E
Jabber: <a href="mailto:rom@romab.com" target="_blank">rom@romab.com</a> 5476 2360 F1B4 5B97 9EF5</pre>
</font></div>
</blockquote></div><br>