Subject: [Trans] DNSSEC also needs CT

From: Nico Williams <[email-masked]>
Date: Fri, 9 May 2014 16:31:23 -0500

DNSSEC is a PKI [of sorts; please, no need to pick nits about that].

It stands to reason that DNSSEC should have similar trust problems as
PKIX.  I believe it does indeed.

It follows that things like CT that we're applying to PKIX should be
applied to DNSSEC as well, where possible.

I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
should be done.

Note that DNSSEC needs CT independently of protocols like DANE, but
any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE
effectively does) should increase the need for CT for DNSSEC.

Note too that I'm not in any way saying that DANE and similar should
block on CT for DNSSEC.

Sincerely,

Nico
--

---

From: "Mehner, Carl" <[email-masked]>
Date: Fri, 9 May 2014 21:58:34 +0000

RFC6698 says:
>This chain is required to prevent a CA from avoiding blame
>   by logging a partial or empty chain.  (Note: This effectively
>   excludes self-signed and DANE-based certificates until some mechanism
>   to control spam for those certificates is found.  The authors welcome
>   suggestions.)

I propose:

To have a DANE certificate (not signed by a public CA) included into a CT log:
1) a pre-certificate be created
2) the pre-certificate submitted to a log
3) the log will verify based on a valid DANE record of type PKIX-EE
4) return a SCT to the submitter to include in the final certificate

Carl Mehner
210.416.0942
Info Security

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Friday, May 09, 2014 4:31 PM
To: [email-masked]
Subject: EXTERNAL: [Trans] DNSSEC also needs CT

Sincerely,

Nico
--

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

---

From: Tao Effect <[email-masked]>
Date: Fri, 9 May 2014 17:13:37 -0500

DNSSEC is certainly broken, but the solution to have a Frankenstein on your hands isn't to staple another Frankenstein onto its body.

DNSSEC insecurities and problems are well documented in the resource on this webpage:

http://ianix.com/pub/dnssec-outages.html

The solution to DNSSEC is *no* DNSSEC. DNSCrypt, DNSCurve, and DNSChain are all better solutions.

Likewise the solution to X.509 PKI problems is *no* X.509 PKI. X.509 is _fundamentally_ the wrong approach.

CT doesn't fix X.509 PKI, it merely gives the illusion of a fix, and still maintains today's global mass-surveillance state and requires people to pay money for insecurity:

http://lists.randombit.net/pipermail/cryptography/2014-April/006480.html

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Tao Effect <[email-masked]>
Date: Fri, 9 May 2014 17:52:32 -0500

Incidentally, DNSChain + DNSCrypt/DNSCurve is a simple and actually secure solution to not just the problems DNSSEC tried to solve, but the ones CT tried to solve as well (and without the additional problems that CT creates anew).

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 May 2014 18:09:26 -0500

On Fri, May 9, 2014 at 5:13 PM, Tao Effect <[email-masked]> wrote:
> ...

Noted.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 May 2014 19:12:09 -0400

There are lots of tricky problems here.

* DNSSEC assertions are time limited
* DNSSEC record signatures have to be rolled up into some sort of
container before they could be used
* TRANS assumes X.509v3 certs.

The simplest way to align things is to simply have a certificate
issued for the DNSSEC zone KSK and plop that in the log as normal.

The actual certificate could be self signed or signed by another
hierarchy. I can't see any value in making specific requirements about
the cert unless there is an ulterior motive to ram some other
technology down people's throats. Which is a really bad move for
trying to get adoption of a science lab stage technology. We did that
with PGP (and S/MIME come to think of it).

Given the Trans architecture, it probably makes most sense if someone
is signing the certificate with some sort of key because the basic
principle of Trans is that the log is holding the certificate issuer
accountable for what they sign. But rolling up self signed certs into
a trans log can also make sense.

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

---

From: Tao Effect <[email-masked]>
Date: Fri, 9 May 2014 18:27:30 -0500

Thank you Nico for at least noting it. ;-)

This list is about making CT happen, and here I come saying that CT is a horrible and insecure protocol.

Such a civil reply is almost unexpected. ^_^

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 May 2014 18:29:11 -0500

> issued for the DNSSEC zone KSK and plop that in the log as normal.

Sure, each zone acts as a CA for its children.  That works, I think.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 10 May 2014 05:38:59 -0400

> Sure, each zone acts as a CA for its children.  That works, I think.

I have previously had some discussions about including DNSSEC / DANE /
self signed certs -- one of the objections / concerns was the threat
of someone DoSing the logs by making up data (there is a cost to a CA
cert, but I can create an infinite number of TLSA records or self
signed certs).

The main incentive (that I can see) to DoS the logs would be for the
lolz[0], and so (IMO) the protection does not need to be very strong -
having someone have to solve a captcha or make a small payment (could
become a donation) would be enough.

W
[0]: Unless you could kill off CT completely / make browsers stop
requiring it (and so allow someone to use an incorrect (misissued)
cert) I cannot see a financial incentive for anyone to do this.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 May 2014 17:31:22 -0400 (EDT)

>> Sure, each zone acts as a CA for its children.  That works, I think.

The problem with that approach is that it does not make DNSSEC distinct
from the existing CA PKI. It will also not remove the cost factor of
getting a DNSSEC "certificate" from a "certified" CABforum member.

> cert, but I can create an infinite number of TLSA records or self

Cost should IMHO not become a verification factor. That's the whole
reason https hasn't been universally deployed to begin with. We should
not make the same mistake with DNSSEC.

> become a donation) would be enough.

Or just say that anyone who puts in more than X amount of DNSSEC CT
entries underneath themselves must run a public CT node themselves. So
if nohats.ca want to get more then X entries, or one of their
subzones/customers wants more than X entries, either they or their
subzone/customer will have to run a fully functional CT node. And if
the node goes down, their new entries will be refused.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 11 May 2014 11:40:04 -0300

On 05/10/2014 06:31 PM, Paul Wouters wrote:
>> lolz[0], and so (IMO) the protection does not need to be very strong

Do not underestimate the appeal of the lulz for some people.

> the node goes down, their new entries will be refused.

This sounds expensive to verify, and still a bit unclear to me.  do you
mean that nohats.ca would need to run its own log for its own zone?  At
the moment, we're not expecting the authorities to run their own logs --
this seems like a change in semantics and control.  clients would also
need to know to switch over to another log in that case -- how would
that be done?  What kind of limits would this architecture place on
undetectable misissuance?

Or do you mean they would  would need to contribute to the CT
architecture in some other way?

Tthis question is related to the (currently idle) DBOUND discussion [0]
and (currently) the public suffix list [1].  If we can draw a line
between public registries (which need to be held publicly accountable)
and private zones (which in many cases may prefer to avoid full zone
enumerability that comes with CT) then we can just ensure that CT-style
audit logs apply only to the public registries.

Public registries themselves have some interest in limiting pollution,
and usually a revenue stream that scales with the size of the registry.
These are properties that we might be able to align with a logging
infrastructure.

So the idea is that for DNSSEC: the root zones and the TLDs (or
TLD-equivalents) would get CT-like logging, but children of those zones
(as you cross into a private administrative zone) would *not* get
CT-like logging.

I'd be curious to hear what other folks think about this balance, and
what it would take to draw that line cleanly.

	--dkg

[0] https://www.ietf.org/mailman/listinfo/dbound
[1] https://publicsuffix.org/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 May 2014 11:20:17 -0400

What I think this discussion is really uncovering is that we don't
really have a model for how CT is applied to WebPKI certificates. All
the questions raised in the DNSSEC discussion seem to be predicated on
assumptions as to how CT logs are managed that are outside the spec.

Which is why having the DNSSEC discussion now is useful. I don't like
specs that are based on unwritten assumptions. That leads to a
situation where implementations have to understand folklore.

In particular, does CA = log maintainer?

For DNSSEC there seem to be a lot of unnecessary assumptions being
made. I certainly don't think everyone wants to run their own CT log
for DNSSEC. And there would be little value in the scheme if they did.
The value of a CT log depends in part on aggregation.

Another unnecessary assumption is that any log maintainer would have
to be a CABForum member. Membership in the forum has no impact on root
inclusion or CT. The only requirement for root inclusion is acceptance
by the root maintainer, most of which adopt the CABForum EV and BR
criteria. The most important part there being audit.

It is probably fair to assume that CT logs will be maintained by CAs
but it would be entirely practical for an open service to be
established. The criteria are rather simpler to enforce than
certificate issue.

It might or might not be desirable to require some sort of certificate
chain to some sort of root. But any such chain does not need to be the
only validation chain PKIX supports cross certificates and an
end-entity certificate may be legitimately accredited to multiple
roots.

The main question is what purpose a CT log for DNSSEC would serve. For
me the value would be to protect my domain against having it stolen by
ICANN. The idea that we should put trust or faith in an organization
extorting $250,000 for domains is ridiculous. And so is the fact that
IESG members have told me that they don't think they should make that
kind of comment even if true because of 'politics'.

If you don't like your WebPKI CA then you can get another. And that
means the costs are competitive. But ICANN has a monopoly and a rent
seeking management.

Deploying CT to establish an independent claim on the domains makes
perfect sense.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 11 May 2014 11:37:59 -0400 (EDT)

> It is probably fair to assume that CT logs will be maintained by CAs

That would be a non-starter for those people (let's call them the defcon
crowd) who are looking at dnssec as a way out of the trust in a handful
of CAs or TLD operators.

> ICANN.

Or any of the parental zones above your own zone.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 May 2014 12:49:44 -0400

> crowd) who are looking at dnssec as a way out of the trust in a handful

As I went on to say:

"It is probably fair to assume that CT logs will be maintained by CAs
but it would be entirely practical for an open service to be
established. The criteria are rather simpler to enforce than
certificate issue."

I don't see the CAs running CT logs as being necessarily exclusive.

In particular, running a CT log does not require audit which is the
difficult part of being a CA. The whole point of transparency is that
the operation of the log does not need a trusted auditor with special
access. Anyone can audit the operation of the log.

Now what the non-CA application does call for is thinking through a
lot more of the operation of the logs and how they are held
accountable.

> Or any of the parental zones above your own zone.

True and that concern has already been an issue with zones such as
vb.ly which was grabbed back when the value of the zone was realized.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 11 May 2014 22:32:47 +0100

> getting a DNSSEC "certificate" from a "certified" CABforum member.

I think you're reading too much into "acts as a CA" ... it is a matter of
fact that the parent zone signs for its children.

> the node goes down, their new entries will be refused.

Yes, exactly. +1

-- 
Certificate Transparency is hiring! Let me know if you're interested.

---

From: Joseph Bonneau <[email-masked]>
Date: Mon, 12 May 2014 13:22:41 -0400

>> the node goes down, their new entries will be refused.

I'm wondering what the exact threat model is here. Imagine a malicious
domain operator wants to sign some DNSSEC records for use in an attack.
They include hashed of them in their log, then claim to "lose" the original
records, or issue the equivalent of SCTs and then never include them within
the MMD. Who is checking up on them for this? Does the superdomain that
signs this domain's record has to be doing full auditing of their DNSSEC-CT
log? Does this still work then as anti-DOS if the superdomain has to do all
of this auditing anyways (I suppose it could be made random, but then the
domain can try to hide malicious entries with lots and lots of spam ones).

Furthermore, is this requirement recursive? What if a malicious domain
evil.com agrees with a subdomain really.evil.com to not audit their
DNSSEC-CT log properly, so malicious records can be signed for
really.evil.com, not audited by evil.com, but if com (who we assume is
honest) only audits evil.com's log they'll think it's in valid order. Is
there a way to prevent the root from having to audit every log everywhere?

Also, the penalty for failing some audit check is losing control of your
domain? That seems like a sufficient disincentive that few domains will
want to go beyond whatever their superdomain's policy is and have to run
their own log, enough that some current practices (like giving users of a
website their own subdomain) would be affected.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 May 2014 12:40:39 -0500

On Mon, May 12, 2014 at 12:22 PM, Joseph Bonneau <[email-masked]> wrote:
> domain operator wants to sign some DNSSEC records for use in an attack. They
> include hashed of them in their log, then claim to "lose" the original

Clients (lazily perhaps).  The public.  Domain owners.  Registrars.

Remember, com. and . cannot merely MITM foo.bar.com.  com. would have
to MITM bar.com. as well.  And . would have to MITM com. too.  These
would be noticeable.

> domain can try to hide malicious entries with lots and lots of spam ones).

"Loss" of log entries gets detected.  Detection of MITM attacks by .
and TLDs would result in bad PR, and the news would spread quickly,
therefore they [mostly] wouldn't do it.  That's the point of CT.

I don't understand you question about anti-DOS.

> there a way to prevent the root from having to audit every log everywhere?

Domains would get to opt out for privacy reasons.  If evil.com opts
out, oh well.  This isn't about auditing every zone.

> domain? [...]

Eh?!  Who said that??  Nobody proposed that; nobody would.

Failure to include signatures in the log -> detection -> bad for
public relations -> incentive for CAs/registrars not to MITM.

Nico
--

---

From: Joseph Bonneau <[email-masked]>
Date: Mon, 12 May 2014 13:54:41 -0400

> Clients (lazily perhaps).  The public.  Domain owners.  Registrars.

Certainly possible, but I wonder how much this will happen in a world of
thousands of DNSSEC-CT logs existing for various domains. Some of them will
inevitably screw up. Will it be front-page news the 10th time that happens
due to server outages or administrative screwups? I imagine it will be kind
of like using an expired x.509 cert today. People on hackernews might
comment if a top website did it, but not an emergency board meeting type of
situation for that company.

With CT for x.509 certs the assumption is that smaller number of logs are
run which are very important and any screwup is a BFD. I don't know if that
assumption scales to thousands of DNSSEC-CT logs.

> to MITM bar.com. as well.  And . would have to MITM com. too.  These

What about a compelled creation attack (or undetected key compromise) where
malicious entries are signed by the genuine evil.com key? For example, say
evilhosting.com gives me jbonneau.evilhosting.com and I care that they only
sign my records for this domain so that nobody can MITM my site. But they
secretly agree to give the government of Elbonia a signed record for my
domain and then fail to log them properly. They can do this without any
compromise or intervention of com, right?

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 May 2014 13:01:27 -0500

On Mon, May 12, 2014 at 12:54 PM, Joseph Bonneau <[email-masked]> wrote:
> thousands of DNSSEC-CT logs existing for various domains. Some of them

The ones that matter most are the TLDs and the root.  Those get so
many users that they will be caught MITMing, if they do.

> assumption scales to thousands of DNSSEC-CT logs.

You're assuming I zones below the ones that matter audited, but I
don't.  I want the root ones audited -- same as with the TLS server
PKI.  Why would I have wanted anything else?

> compromise or intervention of com, right?

If evilhosting.com has lots of customers, then they'll help audit it,
else they might not.  At any rate, the first-order problem in a
hierarchical public key system is keeping the roots and intermediates
closest to the roots honest.

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 May 2014 15:53:00 -0400

> I don't see the CAs running CT logs as being necessarily exclusive.

Nor do we :)

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Joseph Bonneau <[email-masked]>
Date: Tue, 13 May 2014 00:56:41 -0400

> PKI.  Why would I have wanted anything else?

Your original email didn't specify if you were interested in logs only for
the root/important TLDs or for every domain. I (and I think others in this
thread) interpreted the idea as being some form of hierarchical logging for
all or almost all (non-private) domains. Are we on the same page now that
the stronger version seems very unlikely in the short to medium term?

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 00:12:02 -0500

> the stronger version seems very unlikely in the short to medium term?

Is CT intended to be run all the way from the root to the CAs furthest
from the root?  I didn't think it was, and if it is, please tell me.

Incidentally, rfc6962bis could use an operational considerations
section covering issues such as what CAs are expected to be logged.

Nico
--

---

From: Joseph Bonneau <[email-masked]>
Date: Tue, 13 May 2014 01:22:47 -0400

>  from the root?  I didn't think it was, and if it is, please tell me.

Yes, it is. The goal of CT is that browsers will eventually reject any
end-entity TLS certificate that doesn't have an SCT. I believe this is true
regardless of the number of intermediate CAs in the cert's path to a
trusted root. There's an exception for trust anchors manually added to the
browser to accommodate private CAs, but essentially all certificates that
standard browsers will accept out of the box must be logged.

By contrast with DNSSEC you seem to be suggesting that many DNSSEC records
that browsers/resolvers will accept as genuine will not be logged anywhere
(or be logged somewhere that isn't necessarily audited) and the browser
will still accept them.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 12 May 2014 21:26:19 -0800

> section covering issues such as what CAs are expected to be logged.

We've talked about the possibility of breaking out client behavior
into a separate document, and while that discussion focused on
the protocol between a client and a log server it seems that
this sort of thing may belong there, as well.

Nobody has stepped forward to draft a document but at this point
it would be very helpful indeed if someone could step forward and
contribute some text.

Melinda

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 01:34:40 -0500

On Tue, May 13, 2014 at 12:22 AM, Joseph Bonneau <[email-masked]> wrote:
> regardless of the number of intermediate CAs in the cert's path to a trusted
> root. There's an exception for trust anchors manually added to the browser
> to accommodate private CAs, but essentially all certificates that standard
> browsers will accept out of the box must be logged.

Ah, yes, and actually we should want the same for DNSSEC.  The problem
then becomes privacy.  But I think we can achieve that by not logging
names, just hashes of the relevant RRsets, no?  Since public keys will
generally be part of the relevant RRsets this won't help zone
enumerators.

Nico
--

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 13 May 2014 12:41:57 +0400

Hello Melinda,

> it would be very helpful indeed if someone could step forward and
Here are my ideas about "strict" behaviour of the TLS client:

==============
TLS clients supporting CT are supposed to have a preconfigured set of logs
and
their public keys.

In addition to normal validation of the certificate and its chain, they
should
validate the SCTs received during the TLS connection.

The client fully conforming to the specification SHOULD perform the
following
steps before establishing the connection for every certificate in the chain:

1. If no SCTs are provided, the client SHOULD reject the connection.

2. The client MUST ignore all the SCTs provided by unknown logs.

3. TLS clients MUST reject SCTs whose timestamp is in the future.

4. If no SCTs has left after steps 2-3, the client SHOULD reject the
connection.

5. If any of SCTs left after steps 2-3 has invalid signature, the client
SHOULD reject the connection.

Client MAY check whether the certificate is present in the log
corresponding to the passed SCT.
If the certificate is not present in the log, the connection MUST be
rejected.
=============

Can it be a starting point or you want something else?

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Tue, 13 May 2014 12:51:58 +0100

On 13 May 2014 07:34, Nico Williams <[email-masked]> wrote:

> trusted

Is it necessary to log anything other than keys? My base assumption was no:
if the keys are as expected, then all records signed by those keys can be
trusted. If someone wants to publish RRsets that are other than the one the
true domain owner wants to publish, they necessarily have to inject a key
they control, which becomes apparent from the logs.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 May 2014 09:55:05 -0400 (EDT)

On Tue, 13 May 2014, Ben Laurie wrote:

[DNSSEC CT]

> Is it necessary to log anything other than keys? My base assumption was no: if the keys are as expected, then all records signed by those keys
> can be trusted. If someone wants to publish RRsets that are other than the one the true domain owner wants to publish, they necessarily have
> to inject a key they control, which becomes apparent from the logs.

That would not allow us to detect coercion, that is a custom RRset signed
to be used only for a targetted attack (by say, .com or the root)

But I'm not sure how we _could_ detect that. Let's say they get an A
record for www.victim.com that bypasses the NS RRset completely, that
is, signed by the .com key. To notice this case, you would also need to log
the change of zone cut.

The other case is injection of a custom DS RRset. How would we tell the
difference between the legitimate zone owner adding a DS record or an
attacker/parent zone owner adding one? One defense would be to ignore
any new DS record for a certain amount of time, but that runs into
similar issues as pinning and TACK.

Paul

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 09:41:22 -0500

On Tue, May 13, 2014 at 8:55 AM, Paul Wouters <[email-masked]> wrote:
>> Is it necessary to log anything other than keys? My base assumption was
>> no: if the keys are as expected, then all records signed by those keys
>> can be trusted. If someone wants to publish RRsets that are other than the
>> one the true domain owner wants to publish, they necessarily have

Yes, these are the issues that need resolving.  Hashing the RRset name
doesn't help either where the attack is based on inserting a different
RRset to misdirect the victim.  Nor is it possible to audit logs to
look for such attacks if there's no names.

Still, if the goal is to get the root(s) and TLDs to stay honest, and
since they don't need privacy, their logs can include unhashed names.
Further below in the hierarchy things get murky; I have no answers as
to those, but it seems likely that some (most! probably) zones below
the TLDs will absolutely want protection against zone enumeration.  Is
a modicum of privacy possible with CT for the PKI?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 09:58:03 -0500

To what degree are the privacy issues different for DNSSEC than for PKI?

I would think: they aren't!  Both are PKIs, both have public data,
users (in the sense of having certificates) tend to want to avoid
enumeration below certain points in the hierarchy.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Tue, 13 May 2014 16:02:11 +0100

> is, signed by the .com key. To notice this case, you would also need to log

OK, good point: zone cuts need to also be verified.

> attacker/parent zone owner adding one?

The legitimate owner can tell - that's the point, right?

> One defense would be to ignore

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 10:11:31 -0500

On Tue, May 13, 2014 at 9:53 AM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> On 05/12/2014 02:01 PM, Nico Williams wrote:
> I think technically what we care about is the public registries, not the
> TLDs.  This was my point about the public suffix list and DBOUND: that
> we care about .co.uk just as much as we care about .net.
>
> I know that some people use the term TLD to refer to the public
> registries instead of "top-level domains", but i think it's worthwhile
> to be precise in this discussion.

That's fair.  I do tend to think of co.uk. as a TLD... for lack of a
better term (is there one?), yes.  You're quite right: if a zone is
(has) a public registrar(s) then it should be audited w/o privacy.
Whereas if it doesn't sell registrar services, then it is less
important that it log names: we can assume that names below it are
roughly in the same administrative domain as the zone itself.

>> else they might not.
> If evilhosting.com is handing out subdomains to its customers and
> expecting them to act as different administrative sub-zones, then
> evilhosting.com effectively *is* a public registry, and as such it needs
> to be auditable as well.  (it also needs to be considered a public
> registry for the sake of cookies and other same-origin policy things on
> the web, for example, so that jbonneau.evilhosting.com can't set cookies
> that would apply to dkg.evilhosting.com).

Agreed.

> Who is actually doing the monitoring and auditing is a separate
> question, though.
>
> note that CT appears to differentiate between monitoring (RFC 6962
> section 5.3) and auditing (RFC 6962 section 5.4) in this way:
>
>   Auditors make sure that SCTs are cryptographically valid against an
> STH, and that one STH chains properly to another;
>
>   Monitors make sure that the whole log itself is cryptographically
> valid, looking at all the data.
>
> Neither of these activities describes the actual checks that would need
> to happen for misissuance to be detected.  As noted in section 7.2,
> "interested parties" need to think about how to monitor to ensure that
> items with their administrative domains are not logged by other parties.

I would think that domain owners are "interested parties", and/or
maybe agents they delegate to (e.g., hosting companies).  I can audit
the logs for my domain's parent zone.  But yes, this probably needs to
be covered in more detail.  (Are there FOSS implementations of
monitors/auditors?)

> If this is neither "Monitoring" nor "Auditing" maybe we need a name for
> this kind of activity, so we can discuss it more directly?  how about
> "misissuance review"?

It seems to fall into "monitoring" given the text of the RFC.

> How does she know what logs to look in for this misissuance review?  Is
> there a way she can do this review efficiently?  I think these questions
> are relevant for regular CT as well, but a DNSSEC-focused CT adds the
> wrinkle of delegated zones.  (maybe this isn't actually worse than X.509
> PKI with its fully-delegated intermediate CAs though?)

No, it's easier!  With the name contraint-free TLS PKI the domain
owner has to check... every root CA.  With DNSSEC, which has strict
name constraints, there's only one issuer for each zone cut.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 May 2014 11:33:47 -0400 (EDT)

> The legitimate owner can tell - that's the point, right?

How does that help protect a non-owner user of someone's site being
attacked with a targetted attack? If I don't run victim.com, and I am
just a visitor of victim.com, but only I am given rogue DNSSEC records,
how can I tell something is wrong? I would go to the public log and see
the DS I received is not in there?

(I'm late in this discussion, so I wouldn't know how this gets
  authenticated by the consumer and the victim.com's owner, especially
  if the parent could do a hostile takeover)

Paul

---

From: Ben Laurie <[email-masked]>
Date: Tue, 13 May 2014 16:40:37 +0100

> the DS I received is not in there?

Right, exactly.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 May 2014 10:54:32 -0500

> attacked with a targetted attack? If I don't run victim.com, and I am

They check that what they see appears in the issuers' logs and rely on
domain owners to monitor their issuers.  If at all possible TLS (and
other) clients will tell their peers what STHs the saw, and the
servers can check that those appear in the log).  If enough domain
owners do this then targeted MITM attacks get harder to pull off
without being detected.

This is the herd immunity theory: eventually the risk of detection is
so high for would-be MITMers that they won't risk it at all (except,
of course, for cases like open war, where detection is a non-issue).

This seems especially likely to be the case for DNSSEC because of caching.

> the DS I received is not in there?

Yes.  Or that it is.  If it is and your peers monitor the logs then
you can at least rest easy that the likelihood of MITM issuer
detection is very high.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 13 May 2014 11:57:04 -0400 (EDT)

>> the DS I received is not in there?

So how does the owner authorize a new DS in such a way that the parent
could not override?

I'm reminded of the dlv.isc.org setup, where the zone owner had to prove
control of the private key by publishing something in the zone. In a way
this is also similar to the DS update problem in general. A rogue/hacked
registry could also perform a DS update.

I'm still not sure how to prevent a rogue update in the CT. And once you
fix the rogue update problem, you face the reverse problem. A zone
legitimately changes ownership and the old owner is malicious. How do
you deal with that?

Adding transition time into the equation could address some of this,
but that will re-add the pinning problems.

And adding another kind of authentication key would be adding similar
problems as with TACK.

Maybe some of these attacks are just out of scope and unfixable. After
all, most domains are not "owned" but wrapped in legalese to really only
give me a limited lease on it.

In that case, we could do things like "warn if a DS is present in the DS
RRset that has not been logged into the CT with a known signature by a
current KSK" and "zone cut changed KSK". I'm just not sure how many
false positives that would give with people rolling keys too fast for
the CT log (and slow enough to indeed give that added protection).

The last thing we need is another "cert patrol" style avalanche of
popups.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Tue, 13 May 2014 17:17:14 +0100

> So how does the owner authorize a new DS in such a way that the parent

I don't know: this is not a question transparency addresses.
Transparency allows the owner to detect that the parent has
overridden. What happens then depends on how it is all supposed to
work, which I presume varies by registry/registrar.

> legitimately changes ownership and the old owner is malicious. How do

It seems to me that this is a contractual/legal/infrastructural
question. CT allows everyone to verify that everyone has done what
they're supposed to (modulo their own knowledge of what "supposed to"
is). Once you discover they haven't, then you have to invoke
mechanisms that are nothing to do with CT.

> The last thing we need is another "cert patrol" style avalanche of

Agreed. And one thing you may have to accept is that CT leaves open a
window during which attacks are feasible, but guarantees that they can
eventually be discovered. This is certainly the case for the PKI
version of CT.

I think you can reduce the size of the window in various ways - for
example, preventing key roll until logs have caught up, or until logs
and monitors have caught up.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 13 May 2014 11:14:20 -0800

> Can it be a starting point or you want something else?

It's certainly a very good starting point for discussion.
We've got a couple of options for publishing text on client
behavior.  One would be to propose some text for inclusion
in 6962bis.  Another would be to write up a draft, start
a discussion, and see if there's interest in picking it up
as a working group document.  Publishing a draft should not
be seen as a big deal - they're used in the IETF in a number
of ways, including as scratch pads for ideas/discussion.

You might also wish to open an issue in the issue tracker.

Melinda

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 13 May 2014 23:22:03 +0400

Hello Melinda,

> You might also wish to open an issue in the issue tracker.

I think that, if my submission after discussion, is good enough, it should
be a part of  6962bis.

But I think that the specification of the gossip protocol should be a
separate document.

-- 
SY, Dmitry Belyavsky

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 May 2014 13:21:45 -0400

Nico,
> DNSSEC is a PKI [of sorts; please, no need to pick nits about that].
agreed.
> PKIX.  I believe it does indeed.
PKIX, per se, does not have the trust problems that seem to motivate
CT; the Web PKI does. That PKI has always had a serious problem because
any TA can issue a cert for any Subject, irrespective of the Subject name.
because DNSSEC intrinsically incorporate the equivalent of PKIX Name
Constraints, it does not suffer from that specific problem. That's not to
say that mis-issuance is not possible in DNSSEC, but rather that its
effects are more limited.
> applied to DNSSEC as well, where possible.
maybe.
> I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
I'll defer to DNS experts on that.

Steve

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 22 May 2014 17:32:38 +0000

> I'll defer to DNS experts on that.

Without implying an presumption of expertise on DNS, I would argue that DNSSEC avoids the problems CT seems to be trying to solve by coupling its key learning (and verification) methods to the hierarchical namespace.  As Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT seem to be focused more on the latter.  I don't think there is a key learning/verification dilemma in DNSSEC that CT is appropriate for.

Eric

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 May 2014 13:32:56 -0400

> effects are more limited.

On the contrary, it has a rather more severe problem in that the names
can be reassigned by the upstream zone.

Depending on your application, this might not matter. But if you want
to try hooking an enterprise PKI off a DNSSEC system then this matters
a great deal. I am sure that Google would not want to find that
VeriSign could direct their infrastructure to change configuration by
issuing a fraudulent DNSSEC signed zone.

Come to that, that particular sort of compromise is the type of thing
that we spent a lot of time and effort trying to put out of reach when
I worked at VRSN. I don't want to have someone's private key because I
don't want to be accused of losing it.

Don't think of CT in this case being something to solve a problem
faced by DNSSEC users, instead think of it as something that enables
use for problems where it is otherwise unsuited.

The other major advantage is that it provides a tool to avoid some of
the cryptographic lock in problems that are causing certain countries
to cause issues in ICANN. You don't have to agree with their analysis
to find value in addressing the concerns.

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 May 2014 12:38:36 -0500

> effects are more limited.

I've already said that DNSSEC fundamentally has strong naming
constraints, whereas the TLS web server PKI doesn't (and worse: has
been deployed with none).

However, I don't think it necessarily follows that having name
constraints -> no need for CT.

CT is about keeping CAs honest.  In the TLS web server PKI there are
very many CAs to keep honest, therefore anything that helps automate
that task is greatly helpful.

DNSSEC "CAs" also could use being kept honest, even if none of them
have yet failed to be honest.

>> applied to DNSSEC as well, where possible.

Sure, maybe.

Nico
--

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 22 May 2014 17:47:19 +0000

> have yet failed to be honest.

If I understand your point (perhaps I don't) the type of ``honest[y]'' that you are talking about (in the Web PKI) refers to a CA vouching for a name binding that is illegitimate. How do you imagine this is possible in DNSSEC?  I could (for example) stand up a DNSSEC signed zone for someone else's zone, but because key verification and key learning are tied to the DNS delegation hierarchy, no resolver would learn of my doppelgänger zone, right

Eric

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 May 2014 13:54:53 -0400 (EDT)

> Without implying an presumption of expertise on DNS, I would argue that DNSSEC avoids the problems CT seems to be trying to solve by coupling its key learning (and verification) methods to the hier…

There are some very visible and vocal people that have rejected DNSSEC
flat out because it can be circumvented or co-erced by the higher up
parental zones. They have an inherent distrust of the US Government,
Verisign, ICANN, etc. In fact, they are often trying to replace the
DNS with some peer-to-peer type solution for this very reason. I see
CT-DNSSEC as a way to address that concern, and get those people onboard
for DNS with DNSSEC security without the need for an alternative to DNS.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 May 2014 14:00:58 -0400

> If I understand your point (perhaps I don't) the type of ``honest[y]'' that you are talking about (in the Web PKI) refers to a CA vouching for a name binding that is illegitimate. How do you imagin…

if i control zone foo.bar.example, and you control my parent zone
(bar.example), you can do the following:

 * make a new zone-signing key X

 * stand up an "authoritative" server for the foo.bar.example zone,
signed by X, with a DNSKEY record for X.

 * serve the appropriate DS record in the parent zone (bar.example) to
delegate foo.bar.example to X instead of the correct ZSK.

I'd very much like to know if you've ever done this rather than
publishing the correct DS.

DNSSEC-for-CT seems like one approach to be able to detect this kind of
misissuance.

	--dkg

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 May 2014 14:12:35 -0400

Dimitry,

Thanks for posting the list below.

I have become very concerned that the doc we're working on describes a 
mechanism,
but we seem to lack a good description of the architectural context in 
which CT
is supposed to work. The intro text for the I-D is not at all adequate 
for this.
Maybe the charter for this WG would have included the need to publish a 
doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are now 
beginning to
be raised by several folks:
     - who is expected to operate logs, does every log cover all CAs, is one
log per CA (even if operated by someone else) adequate, how are users 
supposed to
select logs (what the UI like?), etc.
     - how are browsers expected to deal with missing SCTs, missing or 
non-matching
log entries, (crypto) invalid log entries, etc. are browser actions 
supposed to be
effect in real time or is this deferred activity model?
     - hard fail vs. warnings for CT "exceptions?"
     - how are browsers expected to deal with certs from CAs that are not
part of the Web PKI?
     - what are the fallback plans if some number of the Web PKI CAs 
elect to not
participate?
     - same question for major browser vendors?
     - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be 
described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI 
is illustrative
of the many aspects of a global system (with PKI aspects) that need to 
be documented.

Steve
> TLS clients supporting CT are supposed to have a preconfigured set of 
> logs and
> their public keys.
>
> In addition to normal validation of the certificate and its chain, 
> they should
> 5. If any of SCTs left after steps 2-3 has invalid signature, the 
> client SHOULD reject the connection.
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 May 2014 14:12:39 -0400

PHB,
> On Thu, May 22, 2014 at 1:21 PM, Stephen Kent<[email-masked]>  wrote:
>
is that really more "serve" than an ability to issue a credential
for ANY name, as in the Web PKI?
> issuing a fraudulent DNSSEC signed zone.
A large, competent enterprise (if that's not an oxymoron) can run its own
PKI w/o using DNSSEC. This seems like a red herring.
> don't want to be accused of losing it.
no argument there.
> use for problems where it is otherwise unsuited.
That's a very confusing last phrase.
> to find value in addressing the concerns.
I understand their concerns. But the lack of a well-articulated 
architecture
for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether
this is a good idea.

Steve

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 May 2014 13:24:49 -0500

> That's a very confusing last phrase.

I had no problem reading it.  Your complaints that we're all inarticulate
are getting old.

architecture
> for CT, much less a CT for DNSSEC, makes it hard for me to gauge whether

In other words, your concern is about CT in general, not DNSSEC in
particular.  Sounds like a separable issue to me.  But if CT makes sense
then it makes sense for DNSSEC.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 May 2014 14:48:28 -0400

Nico,

> I had no problem reading it.
>
a literal reading of it is as sarcasm. If that's PHB's intent, fine, but
I just wanted to verify that there was no typo.
>
> Your complaints that we're all inarticulate are getting old.
>
not everyone, but a lot of messages and docs seem to validate my 
complaint :-).

> particular.  Sounds like a separable issue to me. But if CT makes 
> sense then it makes sense for DNSSEC.
>
yes, my complaint about a lack of a doc describing CT architecture is not
specific to the CT for DNSSEC discussion.

CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC.

Until we have a doc that describes the architecture, we can't evaluate 
how good
it is in either context.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 22 May 2014 16:45:57 -0400

> for ANY name, as in the Web PKI?

At least that is a temporary condition.

Any trust infrastructure that ultimately rests on the common sense of
the US Congress and President is doomed in the long run. And there
isn't a better political solution on offer either.

Finding a technical mechanism that reduces the dependence on the
political/policy dimension makes it much easier to address that layer.
If it is possible it is always far easier to eliminate a single point
of failure than to work out policy level controls to prevent abuse.

> PKI w/o using DNSSEC. This seems like a red herring.

If they already have a PKI then they are probably not interested in
DNSSEC at all because that problem is already solved and DNSSEC is the
red herring.

Unless that is there is an interesting way to use DNSSEC as an
extension of the enterprise PKI. In which case it is critical that the
DNSSEC PKI does not introduce a new point of failure.

> That's a very confusing last phrase.

DNSSEC is still raw technology. Saying that it does not need feature X
before the full set of potential applications is premature. We don't
know what it is useful for yet. That is what we should find out.

> I understand their concerns. But the lack of a well-articulated architecture

I find that looking at an additional field of application is often a
very good way to improve an underspecified architecture.

Trans is rather too closely designed to solve one problem and it is
not even clear that it does that particularly well. There is a lot of
fuzziness in the process by which a relying party decides that a
particular value is the true Merkle tree apex of a particular log.

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 May 2014 16:24:08 -0500

> I just wanted to verify that there was no typo.

I saw no sarcasm in it.

>> particular.  Sounds like a separable issue to me. But if CT makes sense then
>> it makes sense for DNSSEC.
>>

We agree.

> CT may be appropriate for the Web PKI, w/o being a great idea for DNSSEC.

I take it you concede that lack of name constraints isn't the only
reason to want CT.

I'll concede that CT for DNSSEC might not be a good idea.  Did I ever
say it is?  I started the discussion with an inference: CT is for
PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss.

> Until we have a doc that describes the architecture, we can't evaluate how
> good
> it is in either context.

We have a doc; it's missing important things.  I agree.  But I think
we can have some of this discussion given what we know now.  Indeed,
we've been having this discussion, and important things have come up
(privacy protection, spam).

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 May 2014 14:00:07 +0100

On 22 May 2014 18:32, Osterweil, Eric <[email-masked]> wrote:

> Without implying an presumption of expertise on DNS, I would argue that
> DNSSEC avoids the problems CT seems to be trying to solve by coupling its
> key learning (and verification) methods to the hierarchical namespace.  As
> Steve said (I believe) PKIX != Web PKI, and the problems addressed by CT
> seem to be focused more on the latter.  I don't think there is a key
> learning/verification dilemma in DNSSEC that CT is appropriate for.
>

I disagree: the purpose of CT is to ensure that those who can mess with the
signing chain are monitored for correct behaviour. How people get into the
signing chain does not alter the need to monitor their correct behaviour.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 May 2014 14:01:38 +0100

> particular value is the true Merkle tree apex of a particular log.

FWIW, I plan to explain more clearly our plans in this area shortly (which
are actually quite solid, but not yet documented usefully).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 May 2014 09:12:17 -0400

But Ben, DNSSEC is predicated on the article of faith that DNS
Registrars will never ever make mistakes, get hacked or be run by the
Russian or Ukrainian mafia.

The fact that we have more examples of all of those than CAs being
breached is not going to affect an ideological commitment.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 27 May 2014 18:32:47 +0400

Hello Stephen,

Here is my understanding of the question you asked.
Let Ben or Rob fix me if I'm wrong.

   1.

   Anybody is allowed to operate log. But there should be a procedure
   (similar to CA/Browser forum) which is determined to register log as
   “important” (we need a better word). There should be not many “important”
   log servers, I suppose — otherwise we are to get the same problem as we
   have with many CAs.
   2.

   Any log-server can select the list of acceptable CAs. I think that
   “important logs” should cover all the CAs supported by major browsers.
   3.

   Any log server can select the algorithm of hash for Merkle Tree and for
   its key signing the SCTs.
   4.

   Each browser should provide an editable way of managing logs. By default
   it should be a reasonable subset of “important” logs.
   5.

   Each CA can be accepted by more than one log.
   6.

   Browsers should
   1.

      allow user to accept the cert without CT providing warning about
      absence of CT
      2.

      allow user to specify absence of log for this or that domain
      (non-public suffix)
      3.

      allow user to a particular log for this or that domain and return an
      error if there is no SCT for id provided by this log.
      4.

      there should be a procedure of report about log misbehaviour in case
      of invalid log records
      7.

   I think that warning is acceptable in case of an absence of SCTs, but in
   case of cryptographic errors the error should be generated.

On Thu, May 22, 2014 at 10:12 PM, Stephen Kent <[email-masked]> wrote:

> is supposed to work. The intro text for the I-D is not at all adequate for
> this.
>     - what are the fallback plans if some number of the Web PKI CAs elect
> to not
> participate?
> CT is a system, not just a handful of mechanisms. It needs to be described
> that way.
>
> Although not perfect, I suggest the set of RFCs that describe the RPKI is
> illustrative
> of the many aspects of a global system (with PKI aspects) that need to be
> documented.
>
> Steve
>
>
>>
> Trans mailing [email-masked]://www.ietf.org/mailman/listinfo/trans
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: [email-masked]
Date: Tue, 27 May 2014 16:47:23 +0200

Hi,

I have some other questions

-          What if a CA can´t belong or it´s not accepted in any log server? 

-          What if you need 3 logs for an EV and only get 2 for whatever reasons?

-          Who´s managing that procedure to accept log servers? Google? Are they going to be registered/publicly available for CAs to choose?

Regards

Iñigo Barreira
Responsable del Área técnica
[email-masked]

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: Trans [mailto:[email-masked]] En nombre de Dmitry Belyavsky
Enviado el: martes, 27 de mayo de 2014 16:33
Para: Stephen Kent
CC: [email-masked]
Asunto: Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

Hello Stephen,

1.    Anybody is allowed to operate log. But there should be a procedure (similar to CA/Browser forum) which is determined to register log as “important” (we need a better word). There should be not many “important” log servers, I suppose — otherwise we are to get the same problem as we have with many CAs.

2.    Any log-server can select the list of acceptable CAs. I think that “important logs” should cover all the CAs supported by major browsers.

3.    Any log server can select the algorithm of hash for Merkle Tree and for its key signing the SCTs.

4.    Each browser should provide an editable way of managing logs. By default it should be a reasonable subset of “important” logs.

5.    Each CA can be accepted by more than one log. 

6.    Browsers should

a.    allow user to accept the cert without CT providing warning about absence of CT

b.    allow user to specify absence of log for this or that domain (non-public suffix)

c.    allow user to a particular log for this or that domain and return an error if there is no SCT for id provided by this log.

d.    there should be a procedure of report about log misbehaviour in case of invalid log records

7.    I think that warning is acceptable in case of an absence of SCTs, but in case of cryptographic errors the error should be generated.

Dimitry,

I have become very concerned that the doc we're working on describes a mechanism,
but we seem to lack a good description of the architectural context in which CT
is supposed to work. The intro text for the I-D is not at all adequate for this.
Maybe the charter for this WG would have included the need to publish a doc of
this sort if we had gone through the usual BoF process :-).

I'd like to see a doc that addresses a number of points that are now beginning to
be raised by several folks:
    - who is expected to operate logs, does every log cover all CAs, is one
log per CA (even if operated by someone else) adequate, how are users supposed to
select logs (what the UI like?), etc.
    - how are browsers expected to deal with missing SCTs, missing or non-matching
log entries, (crypto) invalid log entries, etc. are browser actions supposed to be
effect in real time or is this deferred activity model?
    - hard fail vs. warnings for CT "exceptions?"
    - how are browsers expected to deal with certs from CAs that are not
part of the Web PKI?
    - what are the fallback plans if some number of the Web PKI CAs elect to not
participate?
    - same question for major browser vendors?
    - what are the plans for alg aglity, for logs?

CT is a system, not just a handful of mechanisms. It needs to be described that way.

Although not perfect, I suggest the set of RFCs that describe the RPKI is illustrative
of the many aspects of a global system (with PKI aspects) that need to be documented.

Steve

==============

TLS clients supporting CT are supposed to have a preconfigured set of logs and

their public keys.

In addition to normal validation of the certificate and its chain, they should

The client fully conforming to the specification SHOULD perform the following

4. If no SCTs has left after steps 2-3, the client SHOULD reject the connection.

5. If any of SCTs left after steps 2-3 has invalid signature, the client SHOULD reject the connection.

Client MAY check whether the certificate is present in the log corresponding to the passed SCT.

If the certificate is not present in the log, the connection MUST be rejected.

============= 

 

-- 
SY, Dmitry Belyavsky 

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Wed, 28 May 2014 12:11:57 +0100

On 27 May 2014 15:32, Dmitry Belyavsky <[email-masked]> wrote:

>    Any log server can select the algorithm of hash for Merkle Tree and
>    for its key signing the SCTs.
>    4.
>
>    Each browser should provide an editable way of managing logs. By
>    default it should be a reasonable subset of “important” logs.
>    5.
>
>       allow user to a particular log for this or that domain and return
>       an error if there is no SCT for id provided by this log.
>       4.
>
>       there should be a procedure of report about log misbehaviour in
>       case of invalid log records
>       7.
>
>    I think that warning is acceptable in case of an absence of SCTs, but
>    in case of cryptographic errors the error should be generated.
>
>
Google will be publishing its log inclusion policy soon, which covers some
of these points. We have already published our EV/CT plan (
https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo1ZjkwYzYwMjVhYTRmZjY3),
which covers some others.

I am not at all convinced that any of them are in scope for
standardisation, though.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 28 May 2014 12:16:34 +0100

> -          What if a CA can´t belong or it´s not accepted in any log
I would assume that in the very worst case CAs could agree with each other
to log in each other's servers. But I strongly suspect this is not going to
be a problem.

> -          What if you need 3 logs for an EV and only get 2 for whatever
Then you had better get a third.

> -          Who´s managing that procedure to accept log servers? Google?
>
For Chrome: yes, Google will.

> Are they going to be registered/publicly available for CAs to choose?
>
Yes.

> *Iñigo Barreira*
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
> gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
> erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
> la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
> error le agradeceriamos que no hiciera uso de la informacion y que se
> pusiese en contacto con el remitente.
>
>
>
> *De:* Trans [mailto:[email-masked]] *En nombre de *Dmitry
> Belyavsky
> *Enviado el:* martes, 27 de mayo de 2014 16:33
> *Para:* Stephen Kent
> *CC:* [email-masked]
> *Asunto:* Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs
> CT)
>
>
>
> Hello Stephen,
>
> 1.    Anybody is allowed to operate log. But there should be a procedure
> 2.    Any log-server can select the list of acceptable CAs. I think that
> 4.    Each browser should provide an editable way of managing logs. By
> c.    allow user to a particular log for this or that domain and return
> 7.    I think that warning is acceptable in case of an absence of SCTs,
> but in case of cryptographic errors the error should be generated.
>
>
>
>
>