Subject: [therightkey] Roundup of Proposals

From: Tom Ritter <[email-masked]>
Date: Mon, 16 Jan 2012 11:33:42 -0500

Not sure if this will jumpstart discussion or not, but I thought I'd
post the list of ideas I know of, just to see if make sure I'm aware
of what everyone else has spinning around in their heads:

 - Certificate Authority Transparency and Auditability by Ben Laurie &
Adam Langly http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf
http://www.links.org/?p=1212
http://www.imperialviolet.org/2011/11/29/certtransparency.html
 - Sovereign Keys by the EFF https://www.eff.org/sovereign-keys
 - Convergence by Moxie http://convergence.io/
 - CA T&A proofs as cert extensions by Brad Hill
http://www.ietf.org/mail-archive/web/pkix/current/msg30146.html

There's the CA/B Forum which just released a draft of requirements for
Certificate Authorities effective July 1 2012.  This is notable if
only because it has buy-in from CAs. http://www.cabforum.org/

And there's some older projects that predate this past summer that are relevant:

 - Monkeysphere http://web.monkeysphere.info/
 - Cert Patrol https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/
 - Perspectives http://perspectives-project.org/

And there's some partially-connected things in the works:

 - Key Pinning in HTTP working it's way through the websec working
group: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01
 - Key Pinning in TLS by moxie: https://github.com/moxie0/Convergence/wiki/TACK
 - DANE for cert assertions via DNSSEC

If anyone else has more items for a reading list, please send them on.

-tom

---

From: Ralph Holz <[email-masked]>
Date: Mon, 16 Jan 2012 18:14:57 +0100

Hi,

The list sounds about right. CA transparency and Sovereign Keys have a 
lot in common. One thing that I was wondering is why Sovereign Keys does 
not use Merkle hash chains; my guess so far was performance.

>   - DANE for cert assertions via DNSSEC

Not quite the same as it has a different purpose, but may I also add our 
own Crossbear: https://pki.net.in.tum.de/node/4. The purpose of the tool 
is to trace the MitM. It has its own tracking infrastructure, but also 
makes use of Convergence.

Ralph

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Jan 2012 13:46:06 -0500

I would not get too hung up on the precise technology, there are mechanisms
that might well work better than Merkle trees.

One thing to beware of is that there was quite a bit of work in this area
in the mid 90s, some of which is just coming out of patent rights, others
have some more years to go. So it might well turn out to be necessary to
tak a sub optimal approach.

I don't think it at all likely that one proposal will be adopted in its
entirety without modification.

On Mon, Jan 16, 2012 at 12:14 PM, Ralph Holz <[email-masked]> wrote:

> Hi,
>
> The list sounds about right. CA transparency and Sovereign Keys have a lot
> in common. One thing that I was wondering is why Sovereign Keys does not
> use Merkle hash chains; my guess so far was performance.
>
>
>> group: http://tools.ietf.org/html/**draft-ietf-websec-key-pinning-**01<http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01>
>>  - Key Pinning in TLS by moxie: https://github.com/moxie0/**
>> Convergence/wiki/TACK <https://github.com/moxie0/Convergence/wiki/TACK>
> own Crossbear: https://pki.net.in.tum.de/**node/4<https://pki.net.in.tum.de/node/4>.
> The purpose of the tool is to trace the MitM. It has its own tracking
> infrastructure, but also makes use of Convergence.
>
> Ralph
>
> ______________________________**_________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/therightkey<https://www.ietf.org/mailman/listinfo/therightkey>
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 15:36:03 -0800

The charter for this list says: "A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI."

Which attacks are we interested in?

a) Attackers can get a trusted PKIX certificate due to errors on the part of some CAs that are trusted by web browsers.

b) Attackers can get a trusted PKIX certificate due to intentional laxness on the part of some CAs that are trusted by web browsers.

c) Attackers can issue certificates that cause warnings in web browsers that are often ignored and clicked through.

The solution to each of these is different.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Jan 2012 18:51:13 -0500

None of them

The threat we should be interested in at this point is the following:

* Bad thing happens to user of the Internet.

On Thu, Jan 19, 2012 at 6:36 PM, Paul Hoffman <[email-masked]> wrote:

> The charter for this list says: "A number of people are interested in
> discussing proposals that have been developed in response to recent attacks
> on the Internet security infrastructure, in particular those that affected
> sites using TLS and other protocols relying on PKI."
>
> a) Attackers can get a trusted PKIX certificate due to errors on the part
> of some CAs that are trusted by web browsers.
>
> b) Attackers can get a trusted PKIX certificate due to intentional laxness
> on the part of some CAs that are trusted by web browsers.
>
> c) Attackers can issue certificates that cause warnings in web browsers
> that are often ignored and clicked through.
>
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Jan 2012 21:43:17 -0500

Like, his dog dies?  Someone posts naked pictures of his girlfriend to facebook?

I think we might need to constrain things a little further.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Jan 2012 23:19:32 -0500

> * Bad thing happens to user of the Internet.

If Paul's threat lineup was a too specific, Phillip's description here
strikes me as a tad overbroad.

Given the name of the list and the context in which it was formed, it
seems that the concern is about identity management, particularly with
public key infrastructure in mind:

 * an attacker can convince a victim on the network that the attacker is
someone else.

 * the victim is likely to do or communicate things with that attacker
given their mistaken belief about the identity of the attacker.

Public key infrastructure (in the general sense, not limited to PKIX and
X.509) has a goal of making sure that each party to a transaction can be
sure that the key of each other party belongs to the entity they think
it does.

We're looking at various ways that this binding (knowing "the right key"
for each peer you communicate with) can fail, and what can be done to
avoid those failures.

Hopefully, participants in this list will also be willing to examine the
social structures and incentives created by the various technical
proposals under discussion, since they're relevant to the resistance of
the scheme against various methods of impersonation.

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 00:09:33 -0500

And don't forget:

The user discloses an authentication credential to a party that is not the
intended one, permitting the attacker to impersonate them.

When people propose schemes that involve modifying the Web Server and the
browser together, the scheme has the same deployment constraints as fixing
the HTML password bug so that the password is not disclosed in the protocol.

On Thu, Jan 19, 2012 at 11:19 PM, Daniel Kahn Gillmor <[email-masked]
> wrote:

---

From: Bill Frantz <[email-masked]>
Date: Thu, 19 Jan 2012 21:32:24 -0800

On 1/19/12 at 15:36, [email-masked] (Paul Hoffman) wrote:

>The charter for this list says: "A number of people are 
>interested in discussing proposals that have been developed in 
>response to recent attacks on the Internet security 
>infrastructure, in particular those that affected sites using 
>TLS and other protocols relying on PKI."
>
>a) Attackers can get a trusted PKIX certificate due to errors 
>b) Attackers can get a trusted PKIX certificate due to 
>intentional laxness on the part of some CAs that are trusted by 
>web browsers.
>
>c) Attackers can issue certificates that cause warnings in web 
>browsers that are often ignored and clicked through.
>

I would add to this list:

d) Attackers can register a domain name that looks like that of 
another domain and entice users into visiting that domain 
instead of the intended domain. Unicode, with its many similar 
looking glyphs makes this easier, although the I 1 and O 0 
similarities in 95 character ASCII have successfully been used 
in this kind of attack.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | I like the farmers' market   | Periwinkle
(408)356-8506      | because I can get fruits and | 16345 
Englewood Ave
www.pwpconsult.com | vegetables without stickers. | Los Gatos, 
CA 95032

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 01:20:55 -0500

Interesting, the certificate continuity problem is also a DNS name
continuity problem.

If someone was to register bigbonk.com it is not very likely someone would
guess that it is actually a phishing attack against bigbank.com

On Fri, Jan 20, 2012 at 12:32 AM, Bill Frantz <[email-masked]> wrote:

>> b) Attackers can get a trusted PKIX certificate due to intentional
>> laxness on the part of some CAs that are trusted by web browsers.
>>
> d) Attackers can register a domain name that looks like that of another
> domain and entice users into visiting that domain instead of the intended
> domain. Unicode, with its many similar looking glyphs makes this easier,
> although the I 1 and O 0 similarities in 95 character ASCII have
> successfully been used in this kind of attack.
>
> Cheers - Bill
>
> ------------------------------**------------------------------**
> -----------
> (408)356-8506      | because I can get fruits and | 16345 Englewood Ave
> www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032
>
>

---

From: Vesna Manojlovic <[email-masked]>
Date: Fri, 20 Jan 2012 09:05:55 +0100 (CET)

'morning

On Thu, 19 Jan 2012, Paul Hoffman wrote:
> a) Attackers can get a trusted PKIX certificate due to errors on the 
> part of some CAs that are trusted by web browsers.

I would like to add:

d) Atacker can get a trusted PKIX certificate due to a legislation / law 
that enables them to order some CAs to hand out that PKIX certificate

In light of SOPA/PIPA, ACTA, and Iranian (etc) government.

> The solution to each of these is different.

Regards,
BecHa

(disclaimer: posts from my private email address express my personal 
opinion, not endoresed by my employer nor any other group I associate 
with)

---

From: Yoav Nir <[email-masked]>
Date: Fri, 20 Jan 2012 12:49:41 +0200

> In light of SOPA/PIPA, ACTA, and Iranian (etc) government.

You don't need any special legislation. If the FBI/DHS contacts an American CA, tells them they're following some terrorists who are planning some big attack in the US, and need a certificate in order to listen in on their communications, most people would help their government. Even without the coercion of law enforcement.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 08:15:36 -0500

Stating the problem in terms of PKIX is way too specific. The requirements
should apply equally to any new technology being proposed.

Otherwise we end up with a set of requirements that are trivially satisfied
just by having something that is not called PKIX.

SOPA/PIPA attempt to force actions on the DNS, an infrastructure that the
US Congress appears to regard itself as being in control of. So the same
issues are raised for DNSSEC in spades. I would not be surprised if some
idiot attempts to 'fix' SOPA/PIPA by giving the plaintiffs the power to
order ICANN and/or the registry to insert fraudulent records.

As for the activities of intelligence services and co-operation therewith,
it seems rather unlikely that any intelligence service is going to attempt
to engage in a covert operation that leaves highly visible traces unless
the object is to be visible or they are very desperate. Fraudulent
certificates are rather visible.

I do not believe that the police are above the law. There are courts that
sit on a 24 hour basis for precisely the purpose of vetting wiretap
requests. The obvious response to a purported US national security letter
is to tell the investigator that you do not recognize them as lawful
authority as clearly contrary to the searches and seizures clause and that
if they want to maintain the secrecy of their investigation they will
return with a court order.

On Fri, Jan 20, 2012 at 5:49 AM, Yoav Nir <[email-masked]> wrote:

> You don't need any special legislation. If the FBI/DHS contacts an
> American CA, tells them they're following some terrorists who are planning
> some big attack in the US, and need a certificate in order to listen in on
> their communications, most people would help their government. Even without
> the coercion of law enforcement.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 20 Jan 2012 17:20:27 +0200

On Jan 20, 2012, at 3:15 PM, Phillip Hallam-Baker wrote:

Stating the problem in terms of PKIX is way too specific. The requirements should apply equally to any new technology being proposed.

Otherwise we end up with a set of requirements that are trivially satisfied just by having something that is not called PKIX.

SOPA/PIPA attempt to force actions on the DNS, an infrastructure that the US Congress appears to regard itself as being in control of. So the same issues are raised for DNSSEC in spades. I would not be surprised if some idiot attempts to 'fix' SOPA/PIPA by giving the plaintiffs the power to order ICANN and/or the registry to insert fraudulent records.

I agree, except I'm not sure that DNS is within the scope of this mailing list.

As for the activities of intelligence services and co-operation therewith, it seems rather unlikely that any intelligence service is going to attempt to engage in a covert operation that leaves highly visible traces unless the object is to be visible or they are very desperate. Fraudulent certificates are rather visible.

Without pinning, fraudulent certificates are invisible, especially when applied to specific individuals. The fraudulent diginotar cerrtificates in Iran would have gone unnoticed had it not been for the pinning of Google certificates.

I do not believe that the police are above the law. There are courts that sit on a 24 hour basis for precisely the purpose of vetting wiretap requests. The obvious response to a purported US national security letter is to tell the investigator that you do not recognize them as lawful authority as clearly contrary to the searches and seizures clause and that if they want to maintain the secrecy of their investigation they will return with a court order.

I do not believe so either, but con artists posing as policemen or secret agents have managed to get civilians to do lots of things and keep it a secret in the interest of "national security".

On Fri, Jan 20, 2012 at 5:49 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

You don't need any special legislation. If the FBI/DHS contacts an American CA, tells them they're following some terrorists who are planning some big attack in the US, and need a certificate in order to listen in on their communications, most people would help their government. Even without the coercion of law enforcement.
_______________________________________________
therightkey mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/therightkey

Scanned by Check Point Total Security Gateway.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 11:14:50 -0500

On Fri, Jan 20, 2012 at 10:20 AM, Yoav Nir <[email-masked]> wrote:

> Otherwise we end up with a set of requirements that are trivially
> satisfied just by having something that is not called PKIX.
>
>

The scope of the list is the problem. If there is a BOF in Paris a possible
outcome could be 'problem X can actually be handled in PKIX, or DANE or
whatever.'

The biggest problem is deployment. If the near term deployment incentive
for whatever came out of this was that it also fixed the PIPA/SOPA hole in
DNS, I am perfectly OK with that.

As a matter of practicality, having an application make separate calls to a
name service and a trust service is inefficient. It means two packets to
two separate services, either of which could fail. So there is an
availability issue to be considered.

> Without pinning, fraudulent certificates are invisible, especially when
> applied to specific individuals. The fraudulent diginotar cerrtificates in
> Iran would have gone unnoticed had it not been for the pinning of Google
> certificates.
>

The Google certs were not pinned. Pinning is a very specific mechanism. It
is actually more than is required to detect a possible anomaly.
Perspectives, the EFF Observatory and other mechanisms are going to be
deployed for detecting anomalies regardless of whatever standards action
might occur.

What is necessary is to have an understanding of what 'normal' is. Pinning
is an explicit assertion by a (presumably) authoritative party as to what
normal is.

---

From: Vesna Manojlovic <[email-masked]>
Date: Fri, 20 Jan 2012 17:18:30 +0100 (CET)

Hi,

> If anyone else has more items for a reading list, please send them on.

I would like to add a topic of using certificates for "IP resources",
not only domain names: 
http://datatracker.ietf.org/wg/sidr/charter/
http://www.rpki.net/

If you do agree that this is relevant, I can send more "reading material".

Thanks,
Vesna

--
(muse) a force personified as a woman,
who is the source of inspiration for a creative artist.

disclaimer: opinions expressed from this personal e-mail address
are my private thoughts, not endoresed by my employer or any other group.

you are free to feel inspired
http://blogger.xs4all.nl/becha

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 20 Jan 2012 18:50:58 +0100

> If you do agree that this is relevant, I can send more "reading material".

Certainly I do. Public keys are much more pervasive than HTTPS connections through browsers.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Chris Palmer <[email-masked]>
Date: Fri, 20 Jan 2012 10:59:59 -0800

On Fri, Jan 20, 2012 at 8:14 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> The Google certs were not pinned. Pinning is a very specific mechanism.

We consider them to have been pinned. The dynamic pinning proposal in
the WebSec WG is a generalization of what we call "preloaded" (or
"static") pins.

Word-noodling aside, the attack might very well have remained
invisible without Chrome's knowledge of and insistence on Gmail's true
SPKIs.

-- 
They who can give up general-purpose computing to obtain a little
temporary safety, deserve neither general-purpose computing nor
safety.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jan 2012 14:28:27 -0500

Achieving precision in the language used is what the process is all about :)

The reason I think it is useful to make a distinction is that the value
came from identifying a security policy violation and pinning generally
understood to encompass enforcement of a security policy.

Getting a security policy mechanism to the point where it is enforceable is
hard. Google has asked us not to implement the pinning code in Comodo
Dragon even for google.com for operational reasons that look valid to me.

We can use Perspectives or Convergence or similar to detect and report
violations in cases where we do not have sufficiently good data to force
connection failure.

It is clearly desirable to have the client have the capability to fail a
connection but too many false positives will result in people turning the
systems off (unless they are in Iran).

I think we will see security policy coming in different degrees of quality:

0) No information

1) Weak - e.g. data that has been collected from passive observations and
heuristic means.

2) Good - the data comes from an authoritative source (e.g. HTTP headers,
DNS records)

3) Strong - there is authenticated, curated data from an authoritative
source backed up by data from a trusted source

4) Proof - the client has the benefit of a full cryptographic
authentication of the security policy that is tied to immutable sources
(e.g. Merkle tree based notary).

At the moment I see a lot of proposals that attempt to find the sweet spot
on this continuum. Well maybe that is the wrong approach for the protocol
to take. Maybe a better approach is to have a protocol that supports
transport of security policy data of any quality and allows the client to
make an appropriate decision. This would also take into account the degree
of concern the user had. Iranian dissidents and security specialists would
probably want to be more aggressive than regular users.

So a default approach would probably be for the client to merely report
policy violations against weak policy to some external party, warn the user
if there is a violation against good policy and block the connection on
Strong policy or Proof.

Getting to proof is good (yeah, I did the formal methods thing too). But it
is also very difficult to achieve.