Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Dec 2011 09:01:04 -0500

Agreed that 80% of the benefit without the practical difficulties is much
better.

What happens in Sovereign keys when someone makes a mistake and either
loses their key or discloses it? 'Be careful' is not an acceptable answer
when non-specialized entities are meant to do this.

Where I think the security world has gone wrong over the past few decades
is making access control the be all and end all of security and
ignoring accountability as a tool.

An access control scheme cannot have more than 0% false positives which
means that you have to tolerate a much higher degree of false negatives
than you would like. Consider the Wikileaks situation where a low level
clerk had access to half a million cables because he might have a plausible
need to look at any one of them.

Accountability does not block the bad action but combined with access
control you can block what you know must never happen while still placing
limits on what is allowed.

the useful contribution in sovereign keys seems to me to be the idea of
having an unalterable audit log. Which is an opportunity to remind people
once again that the Harber and Stornetta catenate cert patent has expired
and now would be a good time to do something interesting there.

A general purpose notary protocol would have much wide application.

On Mon, Nov 28, 2011 at 8:49 AM, Miller, Timothy J. <[email-masked]>wrote:

> I really don't see a heck of a lot of conceptual difference between this
> proposal and several current and past proposals.  Functionally this is
> just pushing the name binding back to a separate  level from the CA, only
> now I need to trust both the CA and the Registrar to run things correctly.
>
>
> Personally I think client-side incorporation of continuity-of-use data
> into trust management--either individually or supported by independent
> inspection points (see Perspectives, Convergence, or even Google's
> Certificate Catalog,
> http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-
> security.html)--probably nets 80% of the benefit and will be much easier
> to accomplish in the decentralized Internet.  Yes, there  are observed
> issues with current practices at server-side (ref. the SK proposal
> Appendix A.3 and the cited blog from Andy Steingruebl), but if a
> continuity-type model gains traction operational practice *will* change
> and those false positives resolve themselves.
>
> Finally this statement bugs me:
>
> """
> Generalising from the above problem, Perspectives and Convergence rely on
> parties other than the domain holder to characterise what state the
> domain's operational deployment /should/ be in
> """
>
>
> This ignores (common?) situation where site owner and domain owner can be
> different entities.
>
> -- T
>
> On 11/21/11 6:25 PM, "=JeffH" <[email-masked]> wrote:
>
> >Of possible interest...
> >
> >
> >Subject: [SSL Observatory] Sovereign Keys: an EFF proposal for more secure
> >       TLS authentication
> >From: Peter Eckersley <[email-masked]>
> >Date: Fri, 18 Nov 2011 14:31:42 -0800
> >To: [email-masked]
> >
> >For quite a while at EFF, we've been pondering different possible
> >solutions to
> >the structural insecurities that are present in PKIX (and, to a lesser but
> >still quite significant extent, DNSSEC).
> >
> >This year, our thinking solidified around an idea for using append-only
> >data
> >structures to store keys.  We are publishing this proposal for the first
> >time
> >today:
> >
> >https://eff.org/sovereign-keys
> >
> >On that page you can find links to a high level overview and detailed
> >design
> >docs.  The design has a number of nice features, including very strong
> >resistance to server impersonation attacks and automatic failover to
> >secure
> >routing methods (ideally, Tor hidden services) when server impersonation
> >occurrs.
> >
> >It should be read as a long-term, moderately ambitious proposal.  Even if
> >the
> >Internet community likes this design or something similar, less systematic
> >solutions (various forms of pinning, Perspectives/Convergence, the
> >Decentralized SSL Observatory) will certainly remain necessary and
> >important
> >for at least a number of years.
> >
> >--
> >Peter Eckersley                            [email-masked]
> >Technology Projects Director      Tel  +1 415 436 9333 x131
> >Electronic Frontier Foundation    Fax  +1 415 436 9993
> >
> >
> >
> >_______________________________________________
> >pkix mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/pkix
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Dec 2011 09:16:13 -0500

> A general purpose notary protocol would have much wide application.

And, although it is probably superfluous, with a lead-in like that I
could hardly not mention Certificate Transparency, even in an inchoate
state: http://www.imperialviolet.org/2011/11/29/certtransparency.html

Cheers

AGL

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 9 Dec 2011 14:52:16 +0000

>state: http://www.imperialviolet.org/2011/11/29/certtransparency.html

You may want to rethink the approach, or at least your arguments for it.

Your 10-second summary is functionally equivalent to a second CA that
signs atop certificates issued by other CAs.  We can pursue this course ad
infinitum and the same problems exist at all levels, so I really don't see
the point.

Additionally, while your definition of side-channels is fine as it stands,
you ignore approaches like OCSP stapling which similarly eliminate
side-channels under your definition.  So criticizing current practice for
requiring side-channels (as you define them) is inappropriate.

-- T

---

From: Ben Laurie <[email-masked]>
Date: Fri, 9 Dec 2011 15:34:59 +0000

> infinitum and the same problems exist at all levels, so I really don't see

Then you need to read the full paper, because it is _not_ equivalent
to a second CA.

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Dec 2011 10:49:56 -0500

> infinitum and the same problems exist at all levels, so I really don't see

As Ben says, it's very different from being another CA because it's
doing a different job. A CA attests to a relationship between an
identity and a public key, while a log is simply a notary, and a
notary can be audited by its clients to ensure that it doesn't sign
non-public information. Being a log is much easier than being a CA and
we can achieve stronger properties of logs.

> side-channels under your definition.

OCSP stapling does not count as a side-channel under my definition.
OCSP stapling (suitably enhanced with the ability to staple for
several certificates and then required by clients) would be a great
way to solve the revocation problem. But CT doesn't aim to solve the
revocation problem and, unlike requiring OCSP stapling from all sites,
I believe that CT can reasonably be deployed.

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Fri, 9 Dec 2011 15:30:05 +0000

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 9 Dec 2011 17:32:12 +0000

>Then you need to read the full paper, because it is _not_ equivalent

I have, and I said *functionally* equivalent, not *operationally*
equivalent.

Look at it this way:  The CA tells a user "I say this name is bound to
this key."  Your notary basically says "Yeah, what he said."  The words
are different but the message is the same.

Note that the only way you can support detection of a colluding notary is
to use what you've defined as a side channel.  The client needs to check
with the notary's public list to show that a server-provided proof set
isn't valid--a fact you recognize in the paper but not on the summary.
This is part of the "reconsider your arguments" comment.

Also, you missed a fraud case in your discussion.  What happens if a CA
fraudulently issues a cert *and* registers it with a non-colluding notary?
 The notary has no interaction with the entity the cert identifies, and
can only take the CA's word for it. So the cert goes on the viewable list,
the proof set goes to the fraudulent user, and the user gets spoofed.

Finally, IMHO you place undue faith in the ability to "untrust" a notary;
if the notary list comes from the browser makers--who by your own argument
have a *proven* inability to manage roots of trust--then why should the
notary list supplied and updated by the same source be somehow more
trustworthy?

On a side note, these aren't personal comments.  You placed the work in
the public sphere in what appears to be a solicitation for comments and
criticism.  I'm not particularly invested other than just trying to help
improve the work.

-- T

---

From: Ben Laurie <[email-masked]>
Date: Fri, 9 Dec 2011 17:47:49 +0000

> isn't valid--a fact you recognize in the paper but not on the summary.

The summary says "clients check these proofs".

> fraudulently issues a cert *and* registers it with a non-colluding notary?

The legitimate owner notices and takes action.

> the proof set goes to the fraudulent user, and the user gets spoofed.

Correct. However, this fact is detected.

> notary list supplied and updated by the same source be somehow more

Because their current inability is thrust upon them, not caused by
incompetence or unreliability.

> criticism.  I'm not particularly invested other than just trying to help

Indeed, we are happy to receive comments, thankyou for your interest.

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Dec 2011 12:57:21 -0500

> are different but the message is the same.

Rather than "what he said", we intend the log to assert "this
statement has been published".

That doesn't stop a user from being compromised, as you point out. But
it means that it's possible to answer the question: "what's the
current set of valid certificates for example.com"? Only example.com
can really decide whether a certificate for example.com is correct or
not and, once certificates are public, we envision services that let
them sign up for updates. In the event of a problem, there's proof, in
the logs, of misissuance by a CA. Indeed, anyone can watch the logs
and, perhaps, notice that a small CA is suddenly issuing certificates
for sites that one wouldn't expect them to.

I don't claim that this is perfection, but I'm suggesting that it's an
improvement, and one that we can reasonably deploy.

> This is part of the "reconsider your arguments" comment.

That's probably the result of sloppy wording by myself. The problem is
with blocking side-channels: requests to third-parties that are
required before a connection can be established. OCSP lookups should
fall into this category but, due to practical concerns, common
browsers don't actually block, thus mostly eliminating the
effectiveness of revocation checking.

We're trying not to repeat that mistake. However, non-blocking
side-channels in general are essential: they're how we push updates
for one and without any updates you quickly end up with unpatched
vulnerabilities. An attacker who can partition a victim from the
Internet for an unbounded amount of time can win.

> notary list supplied and updated by the same source be somehow more

The correct working of notaries can be established much more easily
because they're asserting something that's easy to check. You're
absolutely correct that we need a plan in place to be able to revoke
and replace a log without incurring costs similar to revoking a CA.
The exact form of that remains to be seen but it likely involves
requiring only n of m trusted signatures.

Cheers

AGL

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 9 Dec 2011 21:08:32 +0000

On 12/9/11 11:57 AM, "Adam Langley" <[email-masked]> wrote:

>current set of valid certificates for example.com"?

Actually, not so much.  Since the selection of notaries is potentially
random, an inspection of some m of n notaries only yields a probability
you have to interpret, not an actual answer.  Further, this confidence
score is proportional to the cardinality of the set of notaries, and since
the set of notaries is unbounded this is going to be a problem.

You can require example.com to specify which notaries are authorized to
vouchsafe for example.com certificates, but now you have the problem of
communicating this to the user.  You can't do it in-band because the
attacker will simply supply his own list of colluding (or duped) notaries.
 This is almost exactly the problem you were trying to solve, but removed
to a different level.

>improvement, and one that we can reasonably deploy.

Overall I still think it's easier to have the notary (keeping in mind that
the user can be his own notary) observe what example.com publishes by
simply observing example.com directly, then communicate this to the user.
There are fewer moving parts, the code will be simpler, and the assurance
is nearly the same.

-- T

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Dec 2011 16:21:18 -0500

On Fri, Dec 9, 2011 at 4:08 PM, Miller, Timothy J. <[email-masked]> wrote:
> random

No it's not. The set of notaries is globally known. See the "It's easy
on the server operator" section of
http://www.imperialviolet.org/2011/11/29/certtransparency.html or the
PDF for more details.

> There are fewer moving parts, the code will be simpler, and the assurance

See "Why not Convergence":
http://www.imperialviolet.org/2011/09/07/convergence.html

Cheers

AGL

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 9 Dec 2011 21:38:28 +0000

>http://www.imperialviolet.org/2011/11/29/certtransparency.html or the

I think you mistake my meaning.  Is there a canonical list of notaries,
who maintains this list, and how do I trust that entity?  If there is no
such list, how does the user know which notaries to inspect when he
chooses to inspect them in order to verify suspect notary authenticators?
If the user is supplied with the notary or notaries in-band, how does the
user know that the notary is not in collusion with (or duped by) the site
to which he connects?  If the realization of collusion is *after the
compromise event* how is this better than current practice?

>http://www.imperialviolet.org/2011/09/07/convergence.html

You omit the case where the user is his own trust notary (e.g. Certificate
Patrol).  This resolves the internal server issue, and potentially the
captive portal.  This case reduces the sharing of situational awareness
among otherwise non-communicating users, but that doesn't impact the
routine use case where a user has a relationship with a site the already
exists *at the time the attack is executed*.

I'm not looking for perfect here, I'm looking for good enough.  You've put
together a system with a number of new moving parts, requires an entirely
new infrastructure, a new trust model, an new behavior model, and at first
analysis doesn't seem like it offers a really compelling advantage.

-- T

---

From: Adam Langley <[email-masked]>
Date: Fri, 9 Dec 2011 17:11:06 -0500

On Fri, Dec 9, 2011 at 4:38 PM, Miller, Timothy J. <[email-masked]> wrote:
> Is there a canonical list of notaries,

Yes. Since server operators include the audit proof in their TLS
reply, the set of logs is known.

> who maintains this list, and how do I trust that entity?

Browsers maintain this list in the same fashion as root CAs. You trust
your browser because you have to - it mediates everything you do on
the web. The browsers can reasonably maintain such a list because the
job of a log is much easier than a CA, therefore misbehaviour can be
detected and is clearly a failure. And because it will be possible to
revoke and replace a log, as opposed to a large CA.

> If the realization of collusion is *after the compromise event* how is this better than current practice?

Because right now our detection is terrible. Having a global view of
all certificates would be a huge improvement.

> Patrol).

Certificate Patrol is great for people like us. But it's terrible for
the average user, whom we cannot reasonably ask to evaluate
certificates or to even understand what they are.

Cheers

AGL

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 12 Dec 2011 13:21:29 +0000

>reply, the set of logs is known.

That's not quite what I was asking.  How does the browser know that the
list of notaries provided with the proof are the "correct" notaries for
the site?  This question should be rhetorical, because given only the
information available in-band the answer is obviously "it doesn't."  The
browser must implicitly trust that the proofs come from the set of
notaries chosen by the site, not the set of notaries chosen by the
attacker.  

This is the exact same problem the browser currently has when deciding
whether a fraudulently obtained cert from CA X presented by an attacker is
"correct" (instead of the properly obtained cert from CA A).

>revoke and replace a log, as opposed to a large CA.

You keep going on about how it's easier for a browser because it's easier
to be a notary than a CA, but there really is no such connection.  The
maintenance of a trust list on the browser side of this equation is no
different whether that trust list is a list of CAs or a list of notaries.

It may be true that it's easier to be a notary under your scheme than a CA
under X.509, but really, I'm not sure I see much of a difference.  This
isn't an indictment of your scheme so much as a lamentation of the corners
being cut in current X.509 CA practice.  :)

>all certificates would be a huge improvement.

Now we arrive at the kernel of your concept.  You¹ve improved detection,
but only detection after the fact.  I posit that the average user wants
detection before the fact.  My experience is users really want assurance
that their personal information is not misused, and what providers really
want assurance that customers are not misusing others' personal
information.  Recall the modified CIA triangle:  Confidentiality,
Integrity, and Authenticity.  This is a core tenet of information
assurance.

Simply put, detection after the fact is one instant too late.

>certificates or to even understand what they are.

You misunderstand what Certificate Patrol means to the user.  Certificate
Patrol tells the user "This is the site you've connected to in the past,
which you trusted previously."  This is what the user really wants to
know.  The fact Certificate Patrol uses site certificates to identify
sites is relevant to the function but not relevant to the user interface.

Further, in re: usability: I'm sorry, but at least some research on this
specific topic (and admittedly there isn't much) directly contradicts you.
 E.g., I refer you to:

Simson Garfinkle. "Johnny 2: A User Test of Key Continuity Management with
S/MIME and Outlook Express". Talk or presentation,  9, September, 2005.

-- T

---

From: Carl Wallace <[email-masked]>
Date: Mon, 12 Dec 2011 08:36:20 -0500

>the site?  

This sort of gets at a different question.  Why does a browser need to
always operate with a broad trust posture?  Folks know when they are
banking and could easily indicate that intent to the browser, without
needing to have the ability to authenticate their favorite shoe shop,
doctor, etc. during that session.  This selection could be implemented as
a selection of notary (or a temporary reduction of the TA store, or a
temporary usage of name constraints, etc.).

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 12 Dec 2011 13:54:28 +0000

>temporary usage of name constraints, etc.).

Browsers operate with a broad trust posture because trust anchor choice is
in the hands of the site, not in the hands of the user.  E.g., I have no
way to enforce my preference for, say, Verisign over Entrust when
connecting to my bank's web server.

Similarly with notaries under the proffered scheme; the bank chooses the
notaries it wants to work with and then tells me.  I have no say in that
matter, and have to trust the list offered to my browser actually
represents the intention of the real corporate entity that owns the site.

If you want to modify the scheme where I tell the bank I only trust
notaries X, Y, and Z, then I have a say in the decision.  But the result
of this would be requiring the bank to register with *all* notaries, since
there may very well be no common subset of acceptable notaries among all
the bank's patrons.  You might try to do real-time registration, but I
have no ideas on how you'd make that work within the timeliness required
by the connection protocol and still maintain some semblance of trust.

-- T

---

From: Carl Wallace <[email-masked]>
Date: Mon, 12 Dec 2011 09:39:48 -0500

>connecting to my bank's web server.

I understand why a broad posture is required, just not why it must always
be used (I think you missed the word always above).  There was no
suggestion that a preference be expressed in terms of favoring one
certificate mill over another.  A browser mode similar to site specific
browsing (with a corresponding narrowing of trust) is closer to what I was
thinking about than you suggestions below.

---

From: Adam Langley <[email-masked]>
Date: Mon, 12 Dec 2011 10:43:29 -0500

> list of notaries provided with the proof are the "correct" notaries for

There isn't a different set of notaries for each site. The browser
knows and trusts a set of notaries. An attacker can choose the
notaries that it gets to sign a certificate and, if it gets a quorum
of notaries, then it has broken the system.

> detection before the fact.

Yes, I agree. But we're not proposing such a scheme because we don't
want to do better, but because we don't realistically think that we
can achieve anything stronger.

We're claiming that this is a real improvement on the status quo. A
counter argument may be to suggest that limited resources would be
better spent elsewhere. That means showing that CT is better than all
the alternatives, which we believe that it is. You have a specific
example of a possible, better path below...

> S/MIME and Outlook Express". Talk or presentation,  9, September, 2005.

I'm always happy to see actual UI research :) But it's very unclear if
KCM/TOFU translates to the web.

Everything's fine until a key changes, and keys certainly change in
the real world. In personal interactions, there are always
possibilities to query to key change. Indeed, folks in the study tried
a form of this, even though they couldn't phone/talk due to the
constraints of the study: "Some settled on a form of Email Based
Identiﬁcation and Authentication[2]: they sent an email message to the
attacker’s apparent campaign address to see if the attacker could read
and reply to such messages."

But KCM on the web means that we end up asking users the question:
"The key for www.bankofamerica.com has changed. Trust yes/no?". We
have numbers from opt-in Chrome users which suggests that people click
through our big, red interstitials at a very high rate. But let's
assume that they phone Bank of America and manage to get confirmation
of a fingerprint. (That would be a pretty stunning achievement in
itself!)

But websites are complex, what happens when a subresource fails and we
ask the user: "The key for tc50.akacdn.com has changed..."?

Cheers

AGL

Cheers

AGL

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 12 Dec 2011 17:30:56 +0000

>of notaries, then it has broken the system.

If the set is closed, who manages the set?  Are you proposing an ICANN
model, where a single corporate entity gets to say who's a notary and who
isn't?  Do you have a plan to reach a consensus on who and how to control
this?  It would seem a big gap to me.

If you're not proposing a closed set of notaries, then the set is open,
and any given site owner gets to choose which notaries it contacts with
from that set.

There are no other alternatives here.

>We're claiming that this is a real improvement on the status quo.

I'm not entirely disagreeing, but whether your scheme is an improvement or
not depends on your point of view.  From a law enforcement perspective,
I'd agree.  From the user perspective, not so much.

>KCM/TOFU translates to the web.

Certificate Patrol is explicitly a translation of KCM for the web.

>of a fingerprint. (That would be a pretty stunning achievement in

KCM's weak point has always been key introduction (key changeover is a
special case of key introduction).  The best solution is to go out of band
(e.g., SMS messages, snail mail notification, even robocalling), which was
prohibited in Simson's study (though as you note the participants tried to
emulate OOB verification using in-band methods).  IMHO this is a solvable
problem but not in the general case; it's up to each community of interest
to solve it with a method most appropriate to that community.  For
example, I'd allow my employer to send me an internal mail notification,
my bank to send me an SMS alert, and my favorite forum to post a notice on
the landing page.

Key changeover is trivially solvable using in-band transmittal of the
successor key signed by the predecessor key, but we don't have a protocol
or extension for that.

The current interstitials fail in large part because they don't actually
mean anything to the user.  There are a lot of CAs out there and there's
simply no way to capture them all.  As a result, virtually all users are
being mal-trained at some point or another, and carrying that training
over to places where it's inappropriate.

In re: subresources, that's an exposure of internals that probably
shouldn't be happening anyway.  User experience could drive correction
over time.

-- T

---

From: Rob Stradling <[email-masked]>
Date: Tue, 13 Dec 2011 09:56:48 +0000

> On Fri, Dec 9, 2011 at 9:52 AM, Miller, Timothy J. <[email-masked]> 
wrote:
<snip>
> > Additionally, while your definition of side-channels is fine as it
> > stands, you ignore approaches like OCSP stapling which similarly
> > eliminate side-channels under your definition.
> 

Adam, please explain how you reached this conclusion.

If "requiring OCSP stapling from all sites" cannot reasonably be deployed, 
then surely we cannot expect ubiquitous support for _any_ new TLS extension?

If I understand your paper correctly, _every_ TLS server would ultimately be 
required to send an audit proof during each (initial) TLS handshake.  If we 
cannot expect TLS extensions to be supported ubiquitously, then we cannot rely 
on them for CT.

This leaves us with the possibility of sending audit proofs using an "...extra 
certificate, containing the Merkle signature, in the certificate chain presented 
by the server..."
Earlier this year I suggested a similar "extra certificate" idea [1], although 
my intended payload was multiple OCSP Responses rather than an audit proof.  I 
found that whilst most common browsers simply discarded the extra certificate, 
it did cause problems in a few cases.  (You might like to tell Ben that 
OpenSSL was one of those cases ;-) ).
I "solved" a few of the problems by violating the TLS RFC's rule that "Each 
following certificate must directly certify the one preceding it", but I 
couldn't get either of these approaches to work with old versions of Android.

So when you say that "most existing verification code will ignore it", you are 
correct.  However, I concluded that "most" was not good enough.

[1] 
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9b09a0d97ef8be52/28b508b67dfefc55?lnk=gst&q=another+different+idea#28b508b67dfefc55

[2]
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/9b09a0d97ef8be52/091f20438aecaeb6?lnk=gst&q=another+stapling+hack+idea#091f20438aecaeb6

> AGL

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Dec 2011 11:00:09 -0500

On Mon, Dec 12, 2011 at 12:30 PM, Miller, Timothy J. <[email-masked]> wrote:
> Do you have a plan to reach a consensus on who and how to control

Yes, the set of logs is known to the browser. The consensus needs to
be reached with other browser vendors. We haven't discussed it with
them yet.

> shouldn't be happening anyway.  User experience could drive correction

I agree that interstitials are terrible, but I can't see that we can
avoid them in this situation. In the event that a key changes (and a
signature of the new key, by the old, isn't included), we have to do
something. A hard fail will simply encourage users to flush the
browser caches and start over.

We could request that the user contact the institution in question and
make them enter a suitably encoded fingerprint into the interstitial
in order to proceed. I don't know if normal people would actually cope
with that, but maybe they would.

But the problem with subdomains is a big one. Due to CDNs, same-origin
security etc, there are lots of subdomains in the average page. If a
page includes some Twitter Javascript, then the correct action is to
phone Twitter, but the user may have no relationship to Twitter and
the bank probably don't have a clue that Twitter is doing a key
rotation.

Also, if KCM involves storing fingerprints on disk then we have to
flush them on user request. But it's not too hard to get people to
flush browser caches when something goes wrong because sites don't
always get caching right and so folks have trained themselves to flush
caches in initial triage. As an attacker, causing "something goes
wrong" isn't too hard.

But, although I worry about usability problems with KCM on the web, I
would point out that these schemes are not mutually exclusive. There's
nothing stopping KCM atop of PKIX used as an introduction mechanism.
You may criticize us for being insufficiently aggressive, and maybe
that's fair, but we are openly only trying to get an incremental
improvement here.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 13 Dec 2011 11:05:52 -0500

> then surely we cannot expect ubiquitous support for _any_ new TLS extension?

I agree. In additional to the requirement to support a TLS extension,
OCSP stapling requires constant, fresh data making it even harder. But
I agree that requiring every server on the Internet to support a new
TLS extension isn't going to be viable for some time.

> correct.  However, I concluded that "most" was not good enough.

Yep, if we can't wedge the extra data in anywhere then we're in
trouble. But the sooner that we start working on making it possible,
the better things will be.

This is not something that we expect to be done next year, it's going
to take many years to deploy.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Dec 2011 10:21:12 +0000

On Tuesday 13 Dec 2011 16:05:52 Adam Langley wrote:
> > If "requiring OCSP stapling from all sites" cannot reasonably be
> > deployed, then surely we cannot expect ubiquitous support for _any_ new
> > TLS extension?
> 
> OCSP stapling requires constant, fresh data making it even harder.

Fair point.  CT Audit Proofs don't have this "even harder" requirement, of 
course, since they will be static data.

<snip>
> > So when you say that "most existing verification code will ignore it",
> > you are correct.  However, I concluded that "most" was not good enough.
> 

I've thought of a couple of other ways of wedging the data into the TLS 
handshake, although these methods would require more collaboration from the 
CAs than you've thus far intended to require (or perhaps expected).

IDEA 1 - PUT THE AUDIT PROOF INSIDE THE END-ENTITY CERTIFICATE:
When a CA is about to issue a certificate, it publishes the "ToBeSigned" 
certificate data to the Public Log.  The Public Log generates an Audit Proof of 
the "ToBeSigned" data and returns this to the CA.  The CA encapsulates the 
Audit Proof in a certificate extension, appends this extension to the 
"ToBeSigned" certificate data, and recalculates ASN.1 tag lengths as necessary.  
Then the CA signs the certificate and provides it to the certificate applicant.
Browsers would recognize the Audit Proof certificate extension and would have 
code to strip this extension and reconstruct the original "ToBeSigned" 
certificate data, so that the Audit Proof can be verified.
Since the Public Log is involved prior to certificate issuance, the Public Log 
could conceivably check CAA records, the Google Safebrowsing blacklist, etc, 
etc, and refuse to generate an Audit Proof if any problems are encountered.

IDEA 2 - CERTIFICATE INSIDE A CERTIFICATE:
A certificate is issued and added to the Public Log in the manner your doc 
describes.  Then, the CA issues a second certificate, which contains (in a 
certificate extension) the Audit Proof and the first certificate's signature and 
serial number.  The second certificate's Subject, Issuer, Validity Dates, 
Extensions, etc, must exactly match those of the first certificate.
The site owner configures their TLS Server to send the second certificate.
Browsers would recognize the new certificate extension and would have code to 
pull apart the second certificate, reconstruct the first certificate, and verify 
the Audit Proof.
Since the first certificate would never be seen by legacy Browsers, its 
signature could use SHA-2.  The second certificate's signature would probably 
use SHA-1 whilst there remain a significant number of legacy Browsers that 
don't support SHA-2.
Certificate serial numbers are meant to be unique amongst the set of 
certificates issued by any particular CA, but maybe it would be OK to break 
this rule for each pair of certificates envisaged by this idea, since they are 
essentially the same.  If revocation is required, both certificates should be 
revoked together, so sharing a serial number would make sure this happens.

Comments welcome.

> to take many years to deploy.

If at least one my ideas would work, I think it could be deployed more quickly 
than that.  You'd only need buy-in from the CAs and Browsers.  No need to 
update any webserver software, and no need for site admins to do anything any 
differently.

Rob Stradling

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 14 Dec 2011 13:05:40 +0000

Both concepts are certs-within-certs, when all is said and done.  The CT
audit proof is nothing more than a certificate with an unusual format and
signature algorithm.

-- T

On 12/14/11 4:21 AM, "Rob Stradling" <[email-masked]> wrote:

>> On Tue, Dec 13, 2011 at 4:56 AM, Rob Stradling
>><[email-masked]>
>wrote:

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Dec 2011 12:04:06 -0500

> CAs than you've thus far intended to require (or perhaps expected).

Absolutely, putting the audit proof inside the TBSCertificate would be
nice and clean. But, while I've no doubt that a CA, such as
yourselves, would have no problem handling that, I do fear that
getting every CA to implement might be a struggle. Not to mention
dealing with folks who have an intermediate CA.

Because of this, wedging the data in afterward, while technically
obnoxious, is much easier to deploy, assuming that we can get the
client compatibility. (I also promise to leave extension space for
others if we end up using some trick!)

Thanks to your hint, I've confirmed that Android < 2.2 rejects
certificate chains with superfluous certificates. Thankfully, we can
typically wait a while in order to get rid of phones but I'm also
taking a look at other ways in which to squeeze the data. My current
attempt is running at https://fenton.imperialviolet.org which works on
everything that I've tried so far. Of course, none of this is a
replacement for a wide scale test on google.com, but that'll have to
wait until next year.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Dec 2011 22:23:23 +0000

On Wednesday 14 Dec 2011 17:04:06 Adam Langley wrote:
> > handshake, although these methods would require more collaboration from
> > the CAs than you've thus far intended to require (or perhaps expected).
> 
> client compatibility.

How about getting CT to support both approaches (TBSCertificate and "wedging 
the data in afterward") ?

If the TBSCertificate method has better client compatibility, CAs will want to 
support it.  But for those CAs that struggle to support it, "wedging the data 
in afterward" would work well enough for many customers.

> (I also promise to leave extension space for others if we end up using some
> trick!)

Sounds useful, but I'm not sure what you mean.  (Are you saying what I just 
wrote above, perhaps?)

> certificate chains with superfluous certificates.

Glad to help.

> Thankfully, we can typically wait a while in order to get rid of phones

Huh?  Not sure I follow you.  (Are you saying that people tend to replace 
their phones more often than their desktops/laptops/netbooks, so we don't need 
to support legacy phone OSes/browsers for as long as legacy 
desktop/laptop/netbook browsers?)

> but I'm also taking a look at other ways in which to squeeze the data. My
> current attempt is running at https://fenton.imperialviolet.org which works
> on everything that I've tried so far.

I can't see any squeezed data using "openssl s_client -connect 
fenton.imperialviolet.org:443".  Where should I be looking?

> Of course, none of this is a replacement for a wide scale test on
> google.com, but that'll have to wait until next year.
> 
> 
> Cheers
> 
> AGL

Rob Stradling

---

From: Martin Rex <[email-masked]>
Date: Wed, 14 Dec 2011 23:28:59 +0100 (MET)

Adam Langley wrote:
> 
> Rob Stradling <[email-masked]> wrote:
> >
> taking a look at other ways in which to squeeze the data.

The obvious solution is to use a TLS extension.  I fail to see
a reason why a TLS extension would not be the appropriate tool.

I am very strongly opposed to stuffing protocol extensions encodes
as X.509v3 into *regular* TLS Certificate handshake messages,
because it is a clear violation of the protocol and it would is a
perfectly sensible behaviour for a TLS peer to abort the TLS handshake
if being served a *regular* Certificate handshake message that does not
contain a well formed, ordered and valid certfication path.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Dec 2011 17:40:23 -0500

> the data in afterward") ?

I suspect that we'll end up supporting three methods of getting the
audit proof to the client:

1) Terrible hack that doesn't need CA co-operation nor server changes
2) A TLS extension: doesn't need CA co-operation but does need server changes
3) An X.509 extension: needs CA co-operation but not server changes.

> Sounds useful, but I'm not sure what you mean.  (Are you saying what I just

I'm just saying that, if I find a good way to wedge data in, I'll make
sure that other people can use it after us - i.e. by making it
extensible if need be.

> desktop/laptop/netbook browsers?)

Right, exactly.

> fenton.imperialviolet.org:443".  Where should I be looking?

If you look at the leaf certificate in DER form you'll see the word
"testing" in there, which isn't part of a normal COMODO certificate.
I'm not going to mention the terrible thing that I've done because
this is the PKIX mailing list and it would be like discussing hunting
at a PETA meeting :)

But, if it works...

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Wed, 14 Dec 2011 17:44:16 -0500

> a reason why a TLS extension would not be the appropriate tool.

A TLS extension is absolutely the correct solution to this and is
likely to be supported.

However, I'm still getting bug reports from people who have literally
not updated their HTTPS server software since 1999. We seeking to
reduce the cost imposed on them, and many others like them.

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Dec 2011 23:04:08 +0000

> fenton.imperialviolet.org:443".  Where should I be looking?

Parameters on the signature algorithm :-)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Dec 2011 15:22:28 -0800

> reduce the cost imposed on them, and many others like them.

Please don't. I recognize that this thread is in the PKIX WG, but I'm pretty sure that if it was in the TLS WG, people would say "ability to handle TLS extensions is required".

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Dec 2011 01:45:50 +0100 (MET)

> Parameters on the signature algorithm :-)

My SSL client fails with an ASN.1 decoding error.

which is pretty much in compliance with
http://tools.ietf.org/html/rfc3447#appendix-A.2.4

   A.2.4 RSASSA-PKCS1-v1_5

   The object identifier for RSASSA-PKCS1-v1_5 shall be one of the
   following.  The choice of OID depends on the choice of hash
   algorithm: MD2, MD5, SHA-1, SHA-256, SHA-384, or SHA-512.  Note that
   if either MD2 or MD5 is used, then the OID is just as in PKCS #1
   v1.5.  For each OID, the parameters field associated with this OID in
   a value of type AlgorithmIdentifier shall have a value of type NULL.

Your server certificate contains an invalid AlgId structure,
so all sensible PKI software that recognizes the OID of that AlgId
ought to reject your certificate, and those who PKI software which
does not recognize the sha1WithRsaEncryption OID in that AlgId
(should there be any such PKI software -- this is probably the most
commonly used AlgId around) then that PKI software would not be able
to do a lot of PKI-like stuff with the decoded result...

But otherwise, yes, the AlgId parameter seems to be an
"extensible" part in X.509 certificates that is not
fenced off by the digital signature on the certificate.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 15 Dec 2011 19:31:24 +1300

Adam Langley <[email-masked]> writes:

>If you look at the leaf certificate in DER form you'll see the word "testing"
>in there, which isn't part of a normal COMODO certificate. 

Or just use dumpasn1:

1091   20:           SEQUENCE {
1093    9:             OBJECT IDENTIFIER '1 2 840 113549 1 1 5'
1104    7:             OCTET STRING 'testing'
         :             }
1113  257:           BIT STRING
         :             4E A5 34 27 4F D7 A2 52 96 C2 85 76 AC 80 67 8B
         :             12 3F 7D DE 0E A4 D0 76 68 05 4F 56 DB 53 B4 02
         :             1E CB 53 F3 07 97 80 A4 A1 18 AA 3D 81 E6 97 80
         :             0A 94 ED 72 2D 1C BD 9D 05 8B 88 65 17 1C 66 EA
         :             EC 18 F3 54 1B A8 2C C5 60 1E D8 68 64 91 67 A5
         :             98 26 30 9E 1F 3D 80 ED DF 01 A8 43 DA E3 FB 9A
         :             71 8F 76 1B A8 2D 4D 96 BA 08 C8 D6 DF E7 45 1C
         :             93 48 3A 9E 07 07 F8 FA A4 BC 5D 89 38 24 6D AA
         :                     [ Another 128 bytes skipped ]

>But, if it works...

Only on implementations that accept any old rubbish.  Mind you there's an
awful lot of those out there (I grabbed it with Firefox, which doesn't care or
even seem to notice it, and MSIE is the same), so it may indeed work.

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 15 Dec 2011 10:32:20 +0000

On Wednesday 14 Dec 2011 22:40:23 Adam Langley wrote:
> On Wed, Dec 14, 2011 at 5:23 PM, Rob Stradling <[email-masked]>
<snip>
> this is the PKIX mailing list and it would be like discussing hunting

That's clever.  However, when you applied for that certificate you agreed to 
our subscriber agreement [1] which says...

"...1.7. Restrictions. Subscriber shall not:...
(ii) modify, license, create a derivative work of, or transfer any Certificate 
(except as required to use the Certificate) or Private Key;"

So there might be some legal hoops to jump through if you do decide to go with 
this "terrible thing" approach.

[1] 
https://www.comodo.com/repository/docs/20090820_SslCertificateSubscriberAgreement.html

Rob Stradling

---

From: "Polk, William T." <[email-masked]>
Date: Thu, 15 Dec 2011 05:44:17 -0500

Is it really a priority to protect people running software more than a decade old?

Personally, I am more interested in ways to simplify and motivate migration to appropriate security protocols and cryptographic algorithms & key sizes.  Making system updates part of the system life cycle -- instead of the Ron Popeil ("Set it and forget it!") style of system administration -- could significantly improve security on the Internet.

Tim
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Langley [[email-masked]]
Sent: Wednesday, December 14, 2011 5:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS

Cheers

AGL

---

From: Ben Laurie <[email-masked]>
Date: Thu, 15 Dec 2011 11:01:02 +0000

> My SSL client fails with an ASN.1 decoding error.

What is your client?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 15 Dec 2011 11:02:52 +0000

>   a value of type AlgorithmIdentifier shall have a value of type NULL.

BTW, 3447 is not normative on the content of certificates, only the
contents of signatures :-)

---

From: Ben Laurie <[email-masked]>
Date: Thu, 15 Dec 2011 11:05:19 +0000

> this "terrible thing" approach.

If you can't transfer a certificate, how can you use it for TLS?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 15 Dec 2011 11:06:03 +0000

> If you can't transfer a certificate, how can you use it for TLS?

Silly me - you have "except as required to use the Certificate". Would
this not also apply to modifications needed for CT?

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 16 Dec 2011 00:24:01 +1300

>What is your client?

I was going to ask that too, there's actually a client that doesn't just
obliviously accept this cert?

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 15 Dec 2011 11:24:27 +0000

On Thursday 15 Dec 2011 11:06:03 Ben Laurie wrote:
> >> That's clever.  However, when you applied for that certificate you
> >> agreed to our subscriber agreement [1] which says...
> >> 
> >> (ii) modify, license, create a derivative work of, or transfer any
> >> Certificate (except as required to use the Certificate) or Private
> >> Key;"
> >> 
> >> So there might be some legal hoops to jump through if you do decide to
> >> go with this "terrible thing" approach.
> > 

IANAL, but the positioning of the commas seems to suggest that "except as 
required to use the Certificate" applies only to "transfer any Certificate", and 
not to "modify" or "create a derivative work of".

Rob Stradling

---

From: Ben Laurie <[email-masked]>
Date: Thu, 15 Dec 2011 11:40:10 +0000

> not to "modify" or "create a derivative work of".

:-) Either way, its your licence, presumably you can fix it if you need to.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 15 Dec 2011 11:46:08 +0000

On Thursday 15 Dec 2011 11:40:10 Ben Laurie wrote:
> >> >>> this is the PKIX mailing list and it would be like discussing
> >> >>> hunting at a PETA meeting :)
> >> >>> 
> >> >>> But, if it works...
> >> >> 
> >> >> So there might be some legal hoops to jump through if you do decide
> >> >> to go with this "terrible thing" approach.
> >> > 
> > required to use the Certificate" applies only to "transfer any
> > Certificate", and not to "modify" or "create a derivative work of".
> :

Sure.

Rob Stradling

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Dec 2011 18:56:02 +0100 (MET)

Ben Laurie wrote:
> Martin Rex wrote:

rfc3447 *IS* normative on the ASN.1 encoding and decoding for the
sha1WithRSAEncryption AlgId.

  ITU-T Rec. X.509 11/2008  page 12:

  AlgorithmIdentifier{ALGORITHM:SupportedAlgorithms} ::= SEQUENCE {
    algorithm ALGORITHM.&id ({SupportedAlgorithms}),
    parameters ALGORITHM.&Type ({SupportedAlgorithms}{ @algorithm}) OPTIONAL }

  -- Definition of the following information object set is deferred,
  -- perhaps to standardized profiles or to protocol implementation
  -- conformance statements. The set is required to specify a table
  -- constraint on the parameters component of AlgorithmIdentifier.

  SupportedAlgorithms ALGORITHM ::= { ... }

in combination with rfc-3447 PKCS #1 v2.1, page 57 (ASN.1 Module):

  --
  -- When the following OIDs are used in an AlgorithmIdentifier the
  -- parameters MUST be present and MUST be NULL.
  --
  md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
  md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
  sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
  sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
  sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
  sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

Differing values for signatureAlgorithm on the outer Certificate
structure and the TBSCertificate structure, on the other hand,
might(!) be ignored by RPs when verifying the certificate,
because there exists no requirement to compare these fields
in rfc5280 6.1.3 Basic Certificate Processing (and neither am I
aware of any such requirement in ITU-T Rec. X.509 11/2008).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Dec 2011 19:02:59 +0100 (MET)

> Ben Laurie <[email-masked]> writes:

One of the two SSL/TLS clients that we are shipping with our products.
(the one that I maintain).

> obliviously accept this cert?

Actually, every *CORRECT* implementation of an ASN.1 decoder for
AlgId that recognizes sha1WithRSAEncryption will have to reject
that cert, because of the non-NULL parameters field.
 
Enforcing the esoteric stuff in the comment fields of the ASN.1 module
is something that ASN.1 compilers will usually not provide, and what
any sensible implementor will have to manually add.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Dec 2011 19:08:34 +0100 (MET)

Ben Laurie wrote:
> 
> Ben Laurie wrote:
> > Rob Stradling wrote:
> > >
> > > That's clever.  However, when you applied for that certificate
> > > you agreed to our subscriber agreement [1] which says...
> > > Certificate (except as required to use the Certificate) or Private Key;"
> > >

Here in Germany, this certainly would apply
(provided that this clause would not be found to be entirely invalid).

-Martin

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 16 Dec 2011 11:10:10 +1100

> Parameters on the signature algorithm :-)

I looked at the cert for fenton.imperialviolet.org with my ASN.1 tool. It FAILED.

  % asn -t Certificate fenton.cer
  rtdec.c:1177: 0, 4 Null: Incorrect or invalid tag
  fenton.cer: failed to import Certificate

Switching off some of my tool's algorithm-specific knowledge helped:

  % asn -t Certificate -s0xFB fenton.cer
  ...
    algorithmIdentifier {
        algorithm sha1WithRSAEncryption,
        parameters BER:'040774657374696E67'H
    },
    encrypted '4EA534274FD7A25296C28576A...

This tool is built from a code-based used for some commercial X.500 directory software and some (mainly internal) CA software. That might not be enough by itself to say this hack doesn't "work" on the web, but it is one more data point highlighting its hacky nature.

Below is another version of the fenton certificate. It also squeezes in "testing". It is a valid BER-encoding; the toBeSigned portion is untouched; the signature still verifies; my ASN.1 tool accepts it.

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

It encodes the nibbles of "testing" very inefficiently as the lengths of segments that the bit string signature is segmented into. It is not a practical mechanism. It doesn't "work" as Windows FAILS to accept it. ;-) I thought it was cute, however.

P.S. The fenton signature-param hack changes the "thumbprint" that Windows displays for a certificate, which is an unfortunate side-effect.

--
James Manger

---

From: Rob Stradling <[email-masked]>
Date: Fri, 16 Dec 2011 09:06:54 +0000

> any sensible implementor will have to manually add.

Martin, are you saying that it is never sensible to apply the robustness 
principle when decoding ASN.1 data?

http://en.wikipedia.org/wiki/Robustness_principle

Rob Stradling

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Dec 2011 17:04:43 +0100 (MET)

> http://en.wikipedia.org/wiki/Robustness_principle

The rubustness principle should only be applied to communication protocols
when you are the terminal endpoint and the questionable communication protocol
elements are completely gone after processing.  That could be applied
to semantic restrictions on contents of an X.509 certificate created
by the CA, interpreted by the user, but entirely ignored by any
transport agent in between.

What we have:

 CA <-> SrvApp <-> SrvPKI <-> SrvTLS <-> CliTLS <-> CliPKI <-> CliApp <-> User

What you are suggesting would result in the follwing:

(1q) CliApp -> CliPKI:  "perform a certificate path validation on the EE cert"
(1a) CliPKI -> CliApp:  (liberal) "I did, the EE cert is valid"
(2q) CliApp -> CliPKI:  "great!  Please give me the validated EE cert"
(2a) CliPKI -> CliApp:  (conservative) "I can't, the EE cert is invalid"

To me, that would look quite inconsistent.
The result of (1a) and (2a) ought to be the same.

 (A)  either the certificate is *valid* -- in which case specification
      of AlgorithmIdentifier in ITU-T X.509 ASN.1 and PKCS#1 v2.1 ASN.1
      must be wrong

 (B)  or the certificate is *invalid* because of the incorrect AlgId
      parameter for sha1WithRSAEncryption.  You can not really perform
      a PKIX certificate path validation on a certificate if you can
      not decode or do not even recognize the AlgId parameter of the
      digital signature.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Sun, 18 Dec 2011 15:40:06 -0500

At 9:06 AM +0000 12/16/11, Rob Stradling wrote:
>O...

NO is a good answer here, and in most security contexts.

ASN.1 decoding should, under the best circumstances, identify the 
error so that an RP can try to "persuade" the issuer of broken certs, 
CRLs, etc. to fix them. The decoded ought not core dump. But it also 
should reject invalid syntax. Failign to do so merely encourages the 
issuance of broken certs etc., and eventually imposes a burden on all 
RPs to accommodate errors by some issuers.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 19 Dec 2011 09:51:02 +0000

> RPs to accommodate errors by some issuers.

I was actually thinking of PKCS#10 CSRs when I asked that question.  When we 
launched our CA ~10 years ago, my ASN.1 CSR decoder only accepted CSRs that 
were encoded 100% correctly.  Over time, I've had to relax the rules several 
times to accommodate various varieties of broken encoding.  I've never been 
able to suggest a business case for turning away customers just because their 
CSR generation software contains bugs!

CAs are the "terminal endpoint" for CSRs, so hopefully Martin will forgive me.  
;-)

Rob Stradling

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Dec 2011 09:38:31 -0500

>COMODO - Creating Trust Online

I understand the commercial rationale for such behavior, but I think
we agree that it results in precisely the problem I noted.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 19 Dec 2011 15:10:09 +0000

On Monday 19 Dec 2011 14:38:31 Stephen Kent wrote:
> >>  >Martin, are you saying that it is never sensible to apply the
> >>  >robustness principle when decoding ASN.1 data?
> >>  >
> >I was actually thinking of PKCS#10 CSRs when I asked that question.  When
> >we launched our CA ~10 years ago, my ASN.1 CSR decoder only accepted CSRs
> >that were encoded 100% correctly.  Over time, I've had to relax the rules
> >several times to accommodate various varieties of broken encoding.  I've
> >never been able to suggest a business case for turning away customers
> >just because their CSR generation software contains bugs!
> >

Relaxing the decoding rules certainly doesn't alleviate the problem, but IMHO 
it doesn't necessarily make the problem any worse.  For example, if we'd 
decided instead to persist with only allowing correctly encoded CSRs, 
customers with broken CSR generation software would've simply gone to a 
different CA that did accept their incorrectly encoded CSRs.  There would still 
be no incentive for the authors of the broken software to fix their code.

But as for discouraging incorrectly encoded certificates: if just one major TLS 
Client rejected Adam's "terrible thing" signature algorithm parameters hack, 
then I'd imagine this would provide sufficient incentive for Adam to abandon the 
idea.

Rob Stradling

---

From: Adam Langley <[email-masked]>
Date: Mon, 19 Dec 2011 10:23:51 -0500

> then I'd imagine this would provide sufficient incentive for Adam to abandon the

That's pretty much true - our tolerance for breaking things is pretty limited.

As a browser, we're in largely the same situation as the CAs ("there's
no point in taking a hard line because users will just move to a
different browser.") None the less, we do try to win small victories
where we can, and we take a fair amount of flack for it. (We banned
EDH parameters < 512 bits rather than work around it. We're pushing
1/n-1 record splitting before Firefox and IE, and thus taking a lot of
the heat. We're banning MD2/4/5 in certificate chains. We're banning
RSA keys < 1024 bits.)

But a way to include extra data in a certificate chain is valuable,
and not just for us (i.e.
https://github.com/moxie0/Convergence/wiki/TACK). We'll take it if we
can, even if it means having to pinch our noses.

Cheers

AGL

---

From: Rob Stradling <[email-masked]>
Date: Mon, 19 Dec 2011 15:44:09 +0000

On Monday 19 Dec 2011 15:23:51 Adam Langley wrote:
> > But as for discouraging incorrectly encoded certificates: if just one
> > major TLS Client rejected Adam's "terrible thing" signature algorithm
> > parameters hack, then I'd imagine this would provide sufficient
> > incentive for Adam to abandon the idea.
> 

Adam, now you've got me wondering if I was too hasty to abandon [2] the idea 
of using an "extra certificate" for sending (multiple) OCSP Responses without 
requiring webserver code changes! [1]

openssl s_client -connect ocspstaplingtest.comodoca.com:443
(sorry for the expired cert; like I said, I'd abandoned the idea!)

[1] 

[2] 

Rob Stradling

---

From: Adam Langley <[email-masked]>
Date: Mon, 19 Dec 2011 10:52:43 -0500

> (sorry for the expired cert; like I said, I'd abandoned the idea!)

It's too early to say. I need to run an experiment to gauge the
effectiveness of wedging data into the certificate chain with the
fleet of clients that are out there. Obviously, we have a reasonably
popular web site with which we can try and run this experiment, but
setting up such a thing will take a couple of months given that
Christmas is in the way.

As I mentioned, if we do find that it's effective, I'm certainly not
going to define a format that excludes anything else in the future.
And, since the code change should be very small, I'd also be happy to
put OCSP multi-stapling via the cert chain into Chrome.

Cheers

AGL

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Dec 2011 10:54:39 -0500

>be no incentive for the authors of the broken software to fix their code.

The ability to go to a second CA that does not require correct syntax 
arises precisely because such CA behavior is not perceived as "bad." 
Slippery slope, v2 :-).

>But as for discouraging incorrectly encoded certificates: if just 
>one major TLS  Client rejected Adam's "terrible thing" signature 
>algorithm parameters hack,  then I'd imagine this would provide 
>sufficient incentive for Adam to abandon the
>idea.

yes, that would be a nice outcome. but, given the very poor track record of
browsers (in general) correctly implementing correct cert processing 
I am not encouraged.

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 19 Dec 2011 11:29:28 -0500

-----Original Message-----
From: Stephen Kent
> From: Rob Stradling
>> Relaxing the decoding rules certainly doesn't alleviate the problem, 
>> but IMHO it doesn't necessarily make the problem any worse.  For 
>> example, if we'd decided instead to persist with only allowing 
>> correctly encoded CSRs, customers with broken CSR generation software

>> would've simply gone to a different CA that did accept their 
>> incorrectly encoded CSRs.  There would still be no incentive for the 
>> authors of the broken software to fix their code.
>
> The ability to go to a second CA that does not require correct
> syntax arises precisely because such CA behavior is not
> perceived as "bad." 

Accept/Reject is a false dichotomy.  Why is Flag not among the
alternatives:

"Warning: the certificate signing request submitted by browser <UA
string> is garbled.  We've done our best to interpret your request, but
please check to ensure that the certificate is acceptable before putting
it to use."

That ought to shame any vendor capable of feeling shame :-).

Dave

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Dec 2011 17:33:50 +0100 (MET)

Rob Stradling wrote:
> CAs are the "terminal endpoint" for CSRs, so hopefully Martin will
> forgive me.  ;-)

Correct, for PKCS#10 I would consider it OK to tolerate _some_ amount
of non-conformance -- in case that you ensure that none of that
incorrect ASN.1 gets incoporated into the issued certificate.
But I would still exclude errors on the PKCS#10 signature and its encoding
from that tolerance.

There is also a difference between inaccuracies that are detected late,
(like incorrect DER-encoding of unused bits on named BitStrings),
which probably resulted in this recommendation in ITU-T X.509 11/2008, pg 11

    When checking signatures in received data, it shall check the
    signature against the actual data received rather than its
    conversion of the received data to a distinguished encoding.

-Martin

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Dec 2011 16:38:54 +0000

> please check to ensure that the certificate is acceptable before putting

Because what that actually says, despite the words on it, is "do you
want to go to the site you just went to or not?". Naturally, the
answer is generally "yes".

---

From: Michael StJohns <[email-masked]>
Date: Mon, 19 Dec 2011 12:35:14 -0500

Let me pile on with Steve and say that the robustness principle has two parts. The first - which seems to be overlooked here -  is "be conservative in what you send".  

For security you need to be a) conservative in what you send and b) a total and utter paranoid in what you accept.

More comments coming to other emails.

Mike

At 03:40 PM 12/18/2011, Stephen Kent wrote:
>ASN.1 decoding should, under the best circumstances, identify the error so that an RP can try to "persuade" the issuer of broken certs, CRLs, etc. to fix them. The decoded ought not core dump. But it also should reject invalid syntax. Failign to do so merely encourages the issuance of broken certs etc., and eventually imposes a burden on all RPs to accommodate errors by some issuers.
>
>Steve

---

From: Michael StJohns <[email-masked]>
Date: Mon, 19 Dec 2011 12:56:01 -0500

As I mentioned in my private note to you, I find your analysis of X.509 and RFC5280 unconvincing.

Encoding issues first:
1) The ASN1 SIGNED macro uses the signatureAlgorithm AlgorithmId value in the outer wrapper to determine the signature type used to validate the signature.
2) X.509 says that "signature contains the algorithm identifier for the algorithm and hash function used by the CA in signing the certificate" for the inside signature AlgorithmId.  That's in ADDITION to the outside algorithmIdentifier and is a strong indicate tha X.509 expects them to be identical.
3)  RFC 5280 says (4.1.1.2)  about the certificate inside "signature field"
 This field MUST contain the same algorithm identifier as the
   signature field in the sequence tbsCertificate (Section 4.1.2.3).
4) Not all signature algorithms have NULL for their parameters field (for example RSA PSS)
5) The certificate processing description in RFC5280 does not say "ensure the ASN1 and certificate is properly encoded" as that's pretty much a no-brainer.  Under your argument, I could pass in a signed object that just sort of looked like a certificate but had additional fields inside the signature wrapper and that would be OK since the signature just happened to verify and I was able to find all the certificate fields.

For implementations:
I believe at least a few implementations just do a look up of the encoded AlgorithmIdentifier rather than parsing out the OID in the AlgId.  So any mucking about with the field will cause things to fail.

So how about moving on from this rather *hackish* idea.  The RPs that *might* accept are obviously broken.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Dec 2011 13:07:40 -0500

+1

This is a standards process and while support for legacy platforms is good
there is a major difference between supporting a legacy platform with a bug
and exploiting that bug to deploy a new feature.

There is no way that we can be sure that all software and hardware out
there is going to be tolerate this form of abuse. In particular I suspect
that it is the type of check that FIPS140 certified HSMs are likely to do.

The parameters issue actually came up in another forum last week. The spec
apparently allows DSA certs to inherit parameters from higher certs in the
chain. This creates an opportunity to attack where a CA issues a cross cert
with malicious parameters.

On Mon, Dec 19, 2011 at 12:56 PM, Michael StJohns <[email-masked]>wrote:

> 1) The ASN1 SIGNED macro uses the signatureAlgorithm AlgorithmId value in
> the outer wrapper to determine the signature type used to validate the
> signature.
> 2) X.509 says that "*signature *contains the algorithm identifier for the
> algorithm and hash function used by the CA in signing the certificate" for
> the inside signature AlgorithmId.  That's in ADDITION to the outside
> algorithmIdentifier and is a strong indicate tha X.509 expects them to be
> identical.
> 5) The certificate processing description in RFC5280 does not say
> "ensure the ASN1 and certificate is properly encoded" as that's
> pretty much a no-brainer.  Under your argument, I could pass in a
> signed object that just sort of looked like a certificate but had
> additional fields inside the signature wrapper and that would be OK since
> the signature just happened to verify and I was able to find all the
> certificate fields.
>
> For implementations:
> I believe at least a few implementations just do a look up of the encoded
> AlgorithmIdentifier rather than parsing out the OID in the AlgId.
> So any mucking about with the field will cause things to fail.
>
> So how about moving on from this rather *hackish* idea.  The RPs
> that *might* accept are obviously broken.
>
> Mike
>
>
>
>
>
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Dec 2011 20:52:59 +0100 (MET)

> with malicious parameters.

I also noticed the goofy DSA AlgorithmIdentifier parameters a short
while ago (because one of those goof-ups is used CMS).

Originally there were these:
  id-dsa           (OID 1.2.840.10040.4.1)  with DSA parameters p,q,g
  id-dsa-with-sha1 (OID 1.2.840.10040.4.3)  with NULL

some CMS implementations abused id-dsa with NULL parameters for
DSA signatures ... but on top of that, there is this crazy idea that
a public key in a certificate tagged with id-dsa and no parameters
should inherit parameters from the issuing CA cert.

I consider the reference of the DSA parameters from the CA certificate
a thoroughly crazy option and we delibertately do not support it
-- we do not have CA certs available when doing the signature processing.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 19 Dec 2011 19:30:08 -0500

Phillip,

DSA parameters are NOT to be inherited from the signed macro or from signature field.  They need to come from SPKI or from the Issuer.

What specs are you reading?

Did you see my paper on this 1995.

BTW, I have always thought that the parameters field in the signature field is a perfect place to throw the random data to avoid hash collision attack.  I am glad I did not suggest to this list.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 19, 2011 1:08 PM
To: Michael StJohns
Cc: [email-masked]; Ben Laurie
Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS

+1

This is a standards process and while support for legacy platforms is good there is a major difference between supporting a legacy platform with a bug and exploiting that bug to deploy a new feature.

There is no way that we can be sure that all software and hardware out there is going to be tolerate this form of abuse. In particular I suspect that it is the type of check that FIPS140 certified HSMs are likely to do.

The parameters issue actually came up in another forum last week. The spec apparently allows DSA certs to inherit parameters from higher certs in the chain. This creates an opportunity to attack where a CA issues a cross cert with malicious parameters.

On Mon, Dec 19, 2011 at 12:56 PM, Michael StJohns <[email-masked]<mailto:[email-masked]>> wrote:
As I mentioned in my private note to you, I find your analysis of X.509 and RFC5280 unconvincing.

Encoding issues first:

   signature field in the sequence tbsCertificate (Section

4.1.2.3).

4) Not all signature algorithms have NULL for their parameters field (for

example RSA PSS)

certificate fields.

For implementations:

Mike

-Martin
_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Tom Ritter <[email-masked]>
Date: Mon, 19 Dec 2011 20:32:48 -0500

On 19 December 2011 19:30, Santosh Chokhani <[email-masked]> wrote:
> DSA parameters are NOT to be inherited from the signed macro or from
> signature field.  They need to come from SPKI or from the Issuer.
>

The original thread is here:
http://www.ietf.org/mail-archive/web/websec/current/msg00867.html
[websec] Key pinning for DSA keys with inherited domain params by
James Manger in the websec working group regarding the key pinning
draft.

-tom

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 19 Dec 2011 20:38:03 -0500

In that case, the parameters can be in SPKI.  The parameters should not be taken from the signature algorithm or SIGNED MACRO.

-----Original Message-----
From: Tom Ritter [mailto:[email-masked]] 
Sent: Monday, December 19, 2011 8:33 PM
To: Santosh Chokhani
Cc: Phillip Hallam-Baker; [email-masked]
Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS

-tom

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 20 Dec 2011 16:05:15 +1300

>be no incentive for the authors of the broken software to fix their code.

This is the direct expression of the PKI toxic codependency problem that I've
commented on in the past, implementers have to accept all manner of broken 
certs because of the large deployed base of such certs, and everyone can keep
deploying broken certs because everything accepts them.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 20 Dec 2011 16:16:38 +1300

>and utter paranoid in what you accept.

Unfortunately this doesn't work so well in the real world, where you often 
have to accept any old rubbish because everyone else does as well.  For 
example within the last two weeks I've had to change my code to accept 
messages from an implementation that defaults to using a 15-year-old obsolete 
block cipher in its messages, but then uses ~2.5 *million* iterations of 
hashing to set up the keys for the cipher, which my code rejected (quite 
sensibly) as a DoS attack.  Since the implementation that does this is GPG, 
you don't have any choice, you can either do it or (effectively) choose not to 
talk PGP any more.

So the above, while laudable in theory, only works if you're prepared to not 
talk to any implementation except your own one.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Dec 2011 07:34:22 +0200

> deploying broken certs because everything accepts them.

Agree, and I think that the IETF is ill-equipped to solve this, as we're all individuals here speaking only for ourselves.

The CA/Browser consortium might be able to do a better job, at least for HTTPS. They really have >99% of the browser vendors there (sorry, Omniweb) and the most important CAs. Maybe they can do something to reduce the brokenness of the deployed base.

We won't be able to do Michael's "utter paranoia", but we could do "somewhat less liberal"