Subject: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR

From: Melinda Shore <[email-masked]>
Date: Wed, 25 Jan 2017 10:03:43 -0900

Hi, all:

We've been looking at the discussion and trying to figure
out next steps.  Because we believe that the mechanisms
Richard's asking for can be built on top of what's specified
in 6962-bis, we've decided that we're going to
continue progressing the document towards publication,
and look to Richard and EKR to produce a draft specifying
a mechanism that meets their requirements with the intent
of adopting it as a working group deliverable.

Thanks,

Melinda

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Jan 2017 18:08:08 +0100

Hi Melinda,

Unfortunately, I don't believe that the concerns that we are proposing
can in fact be plausibly addressed by post-hoc mechanisms on top of
the 6962-bis structure. To be precise, one might build either:

(a) A system which is not publicly verifiable in which case EEs would
    only need to handle and provide SCTs and one can and should
    dispense with much of the Merkle hash tree infrastructure.

(b) A system in which is publicly verifiable in which case the
    current Merkle hash tree infrastructure seems inadequate and
    would need to be revised, not just built on top of.

Either of these seem like reasonable WG decisions (though the
charter pretty clearly contemplates (b)) but the current draft
doesn't really do either. For that reason, I don't think it makes
sense to just proceed as-is. Typically for last call comments
of this magnitude the process would be to discuss them at the
next IETF. Accordingly, rather than pubreq the draft now,
we'd ask for agenda time to discuss in Chicago.

-Ekr

---

From: Ben Laurie <[email-masked]>
Date: Sun, 29 Jan 2017 17:44:34 +0000

> we'd ask for agenda time to discuss in Chicago.

I don't think you're right. In practice, there are mechanisms that
address your concerns, I believe.

Firstly, its important to understand that the goal of CT is to reveal
misissuance, not to prevent it, nor to deal with it when it occurs.

So, inclusion proofs.

One way to deal with this would be to for browsers to report to
servers the previous cert seen for that server. The server can then
fetch the inclusion proof.

If the client ever talks to the correct server having talked to an
evil one, the evil one will be discovered. If the client doesn't, then
the client is effectively in a bubble and beyond help.

Another would be to require servers to serve inclusion proofs
alongside the cert, once the SCT was past the MMD. This could be done
either with OCSP stapling or with the TLS extension.

Next, STH consistency.

My preferred plan for this is to add a new leaf type, STH, and require
(by policy) all logs to accept STHs from all other logs. Then you add
a call to logs that lists the positions of those STHs, so they can be
efficiently retrieved. Or maybe just retrieves the latest seen from
each log. If inconsistent STHs are ever logged, monitors can detect
this. In order to fork a log, you would then have to fork all logs. Of
course, monitors and other interested parties could also gossip STHs
for added value.

All of these can be done on top of 6962-bis.

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 29 Jan 2017 09:31:54 -0900

> we'd ask for agenda time to discuss in Chicago.

Of course, but in the meantime I'm not really a fan of holding
work hostage to meeting schedules (my own deficiencies in that
area duly noted), plus -bis draft authors often don't come to
meetings, plus it looks possible that a number of regular
attendees may not be coming to Chicago because of the political
situation.  We can try to have a conference call in the next
week or so, if people are up for that.

Melinda

---

From: Paul Wouters <[email-masked]>
Date: Sun, 29 Jan 2017 18:12:25 -0500

I think a conference call would be good. I think if we call it an interim meeting, we might need to give more notice.

Paul

Sent from my iPhone

> On Jan 29, 2017, at 13:31, Melinda Shore <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Jan 2017 23:25:28 +0000

On 29/01/17 23:12, Paul Wouters wrote:
> I think a conference call would be good. I think if we call it an
> interim meeting, we might need to give more notice.

You need "one week (ideally two)" [1] though the chances of finding
a slot that has all the necessary folks within one week seems small.

As noted in [1] you don't need AD approval for a virtual interim,
but I do happen to agree it's a good idea:-)

Cheers,
S.

[1] https://www.ietf.org/iesg/statement/interim-meetings.html

>>> On 1/29/17 8:08 AM, Eric Rescorla wrote: Either of these seem
>>> like reasonable WG decisions (though the charter pretty clearly
>>> contemplates (b)) but the current draft doesn't really do either.
>>> For that reason, I don't think it makes sense to just proceed
>>> as-is. Typically for last call comments of this magnitude the
>>> process would be to discuss them at the next IETF. Accordingly,
>>> rather than pubreq the draft now, we'd ask for agenda time to
>>> discuss in Chicago.
>> 
>> Of course, but in the meantime I'm not really a fan of holding work
>> hostage to meeting schedules (my own deficiencies in that area duly
>> noted), plus -bis draft authors often don't come to meetings, plus
>> it looks possible that a number of regular attendees may not be
>> coming to Chicago because of the political situation.  We can try
>> to have a conference call in the next week or so, if people are up
>> for that.
>> 
>> Melinda
>> 
>> 
>> 
> 
> _______________________________________________ Trans mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/trans
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jan 2017 05:39:53 +0100

> misissuance, not to prevent it, nor to deal with it when it occurs.

That's a reasonable objective, but as far as I can tell it requires that
the client be able to ensure that it is seeing the same thing that the
rest of the world sees (i.e., "public" or "end-to-end" verifiability).
The concerns that we have raised go to the practicality of achieving
that.

So, inclusion proofs.
> the client is effectively in a bubble and beyond help.

I don't believe this is correct, at least for common clients, because
the attacker can selectively interfere with just your connections to
the site of interest; this would be detectable with at least some designs.

Consider a trivial, inefficient, CT-like system in which the browser
manufacturer scrapes the entire CT log and sends it to every browser client.
As long as the manufacturer doesn't cheat (in which case you truly
are beyond help, but for non-CT reasons), then a client can easily
assess log-inclusion for any server as long as the connection back
to the vendor is live. And if that connection fails, then the browser
in fact knows it is under attack, which is different from the silent
attack we have here.

So, ultimately, I don't think this is that useful.

> either with OCSP stapling or with the TLS extension.

I agree that having the server serve an inclusion proof is the right design
(and in fact it's what Richard and I contemplated) but this seems
problematic
for two reasons:

1. It's effectively retroactive consistency and so it's a weaker guarantee
than prevention of compromise. I realize that that's not your objective, but
it seems like it's a good one. Also, it means that if a client just goes to
a site once, then compromise may never even be detected.

2. In order to operate efficiently, it requires that the client be able to
verify consistency for the specific STH which this is an inclusion proof
for.
It's possible that this can be made efficient, especially if you minimize
the number of STHs to which inclusion proofs are actually issued, but
all that needs to actually be specified in some way.

Next, STH consistency.
> course, monitors and other interested parties could also gossip STHs

That might work, but I think again it requires some notion that there are
a limited number of STHs which are actually published in practice and
which there are inclusion proofs to. And then this gets into the efficiency
analysis that Richard posted in his initial comments.

Perhaps. However, given that these proposals are pretty essential to
determining whether the public verifiability part of CT works, it would
probably be good to have a fully fleshed out design to analyze prior
to standardizing that piece.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jan 2017 06:01:53 +0100

I'd be happy to have a call to discuss this and see if we can all
come to some agreement. However, if we don't then this probably
does need some kind of virtual interim or a meeting in Chicago.

-Ekr

---

From: Ben Laurie <[email-masked]>
Date: Tue, 31 Jan 2017 11:51:55 +0000

> The concerns that we have raised go to the practicality of achieving

Given that CT has revealed a good deal of misissuance it is clear that
it does not _require_ that, but it is, of course, a desirable
property.

In other words: don't let the perfect be the enemy of the good.

> So, ultimately, I don't think this is that useful.

Really? You think the common case is where an attacker controls
connections to a single site?

> a site once, then compromise may never even be detected.

I agree it is a good objective, but not one I know how to achieve
practically. If you have a plan, I'm all ears.

> all that needs to actually be specified in some way.

Eh? It is specified in 6962-bis.

> analysis that Richard posted in his initial comments.

There are a limited number of STHs, again, required by 6962-bis.

I will have to look again at the efficiency analysis, but I am
sceptical having done the same thing myself when we started the
project!

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Jan 2017 14:11:14 +0100

> In other words: don't let the perfect be the enemy of the good.

Sorry, I should have been clearer.

As I said in my earlier mail, I think there are several threat models:

- Security if you trust the CAs to accurately log their certs.
- Security if you trust the logs to accurately log certs.
- Security even if you don't trust the logs.

ISTM that the misissuance that CT has revealed is under the first threat
model, namely that the CAs are misbehaving but correctly logging. However
this doesn't require any of the Merkle tree machinery specified here; indeed
it doesn't even require the browser to check SCTs, because these events
happened when people don't check them.

> sceptical having done the same thing myself when we started the

It would certainly be very helpful to get your thoughts on why you think
Richard's analysis is wrong.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Jan 2017 16:10:24 +0000

If we had a threat model document, it would be easier to determine which kinds of threats and uses are in-scope and out of scope.

Oh wait, …  https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/

I again ask the Chairs to determine the consensus and advance this document.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Melinda Shore <[email-masked]>
Date: Tue, 31 Jan 2017 09:41:01 -0900

> I again ask the Chairs to determine the consensus and advance this document.

We don't have consensus.  We're deadlocked and we're not getting
sufficient input from the working group to break the deadlock.
Paul and I can make a decision on the particular question that's
a problem but it probably means an appeal and further delay.

That said, we're only deadlocked on one particular item (the
description of a conspiring CA attack) and there's been no dissent
on the rest of the document.  I would think it's safe to use it as
the basis for a decision about how to go forward on the issues
raised by Richard and EKR, except that I also anticipate that
they'll argue that the threat model is incomplete.

Frankly, this working group was chartered under the assumption
that the goal was detection, not prevention.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Jan 2017 18:50:07 +0000

> sufficient input from the working group to break the deadlock.

Well, yeah, that's why you get paid the big bucks, right? :)

> Paul and I can make a decision on the particular question that's a problem but
> it probably means an appeal and further delay.

That's the process.
 
> Frankly, this working group was chartered under the assumption that the
> goal was detection, not prevention.

That's my perception as well.  Is there anyone who thinks prevention was part of the scope?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Feb 2017 07:51:06 +0100

> That's my perception as well.  Is there anyone who thinks prevention was

I think this is painting with a bit too broad a brush. One needs to talk
about
detection under a specific threat model, as I indicated previously.
Specifically,
there seem to be a number of potential threat models:

1. CAs make mistakes but aren't malicious.
2. CAs are malicious but logs are not
3. CAs and logs are both malicious

What technological solution is adequate to detect misissuance depends on
which
of these three threat models you think applies.

-Ekr