Subject: Re: [Trans] DNSSEC also needs CT

From: Stephen Kent <[email-masked]>
Date: Mon, 02 Jun 2014 13:12:01 -0400

PHB,

...

>> is that really more "serve" than an ability to issue a credential
>> for ANY name, as in the Web PKI?
> At least that is a temporary condition.
If CT is successful, yes.
> 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.
common sense an the U.S. Congress, that's an uncommon pairing :-).
> 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.
agreed.
> ...
> 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.
agreed, unless someone convinces them that the shiny new DNSSEC approach
to PKI is better, ...
> 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.
agreed,

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.
Thanks for the clarification.
>> 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.
> I find that looking at an additional field of application is often a
> very good way to improve an underspecified architecture.
I guess so, but I'd really prefer a fully-specified architecture for
what purports to be the motivating case, before we claim its a good
basis for solving other problems. I think the potential DNSSEC mis-issuance
problems are different enough to merit a separate analysis and design 
proposal.
> 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.
I agree.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 02 Jun 2014 13:20:16 -0400

Nico,
> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent <[email-masked]> wrote:
>>> 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.
> I saw no sarcasm in it.
I was just confused, as I said. PHB's reply was helpful.
>
>>> 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.
>>>
>> yes, my complaint about a lack of a doc describing CT architecture is not
>> specific to the CT for DNSSEC discussion.
> We agree.
OK.
>
>> 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.
agreed.
> 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.
I thought you did. I think CT for the Web PKI needs is missing an arch
doc, and absent that doc it's now clear how good CT is for that case.
This I consider it premature to suggest CT for DNSSEC si an obvious next 
step,
as some have suggested.
>
>> 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).
The experimental RFC does not provide a comprehensive problem statement,
a clear description of all of the elements of a proposed solution, an
explicit discussion of all of the assumptions that appear to underlie the
design, i.e., what must happen for CT achieve its goals, and an
analysis of what happens if some (implicit) assumptions are not satisfied.

I'm going to develop what I see as the missing arch doc, to elicit 
feedback from
the WG and the RFC authors. The WG can decide whether this is necessary, 
but I
believe the exercise will, in any case, be useful.

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jun 2014 18:14:49 -0500

> This I consider it premature to suggest CT for DNSSEC si an obvious next

I posted today providing my take as to one aspect of the CT architecture:

http://www.ietf.org/mail-archive/web/trans/current/msg00315.html

As I've understood it CT is partly about CA reputation.  As such CA
failures [to not MITM] should be handled asynchronously.  I think this
is an important consideration because it speaks to when the client
(and domain owners, and auditors) should do the hard work of checking
the CT logs.

> I'm going to develop what I see as the missing arch doc, to elicit feedback
> from
> the WG and the RFC authors. The WG can decide whether this is necessary, but
> I

I agree that CT is missing this.  That doesn't (and shouldn't) keep
one from asking if CT is applicable to DNSSEC, and if so what that
might look like.

Hand-waving a bit, if a) CT is a keep-CAs-honest mechanism in addition
to enabling domain owners to find out about erroneous certificate
issuance for their domains, b) CT applies to PKI in general (not just
PKI as in RFC5280), and c) DNSSEC is a PKI, then d) it's a fair
inference that CT ought to apply to DNSSEC.  The three conditions seem
to be true.

It's not a fair inference that CT ought to be applied to DNSSEC, of
course.  Even if CT can be applied to DNSSEC and even if it is
desirable to do so for many, there are still possibly strong arguments
to make against it.  For example, domain owners might object to yet
another "tax" on them: there's domain registrar fees, CA fees, and now
log fees paid indirectly.  And then auditing costs (probably
outsourced).  I'm sympathetic to such an argument.

Add to that a proper the benefit side of a proper cost/benefit
analysis...  For the TLS PKI case the benefit is:

 - mitigates the lack of name constraints
 - detects MITMing CAs

For DNSSEC the only benefit is the MITM detection one.  Assuming that
detections will be of a) errors by registrars, and b) political/legal
actions that we can't do much more about than detect...  is this
enough value to justify the additional costs?  This is a value
judgement to be made by the market.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Jun 2014 15:07:55 -0400

Dmitry,

My replies are inline. sorry that my mail program renumbered each of 
your bullets as I inserted my replies :-(.

> 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.
>
As you note, the notion of establishing some logs as "important" would 
borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. 
So, I think this
doc needs to address this issue in a fashion consistent with IETF 
procedures.
>
> 1.
>
>     Any log-server can select the list of acceptable CAs. I think that
>     "important logs" should cover all the CAs supported by major browsers.
>
The doc suggests this, but again, this has a CABF feel to it. IETF 
standards do not endorse
implementations and use decisions by vendors to drive standards.
>
> 1.
>
>     Any log server can select the algorithm of hash for Merkle Tree
>     and for its key signing the SCTs.
>
That's not what the doc says; it establishes two MTI algs that all 
clients must support, while log operators are allowed to pick form 
between the two. This seems a bit backwards to me, in that it imposes 
the greater burden on the larger # of implementations.
>
> 1.
>
>     Each browser should provide an editable way of managing logs. By
>     default it should be a reasonable subset of "important" logs.
>
The set of "important" logs might not include a CA that is important for 
a set of clients 9since log operators have complete discretion as to 
which CAs they accept) so it ought to be possible for a client to 
include a pointer to logs outside the default set.
>
> 1.
>
>     Each CA can be accepted by more than one log.
>
"Might be" is the more accurate characterization, based on the current 
doc. There is no requirement that any log operator accept submissions 
from a specific CA. Each log operator indicates what CAs/TAs it supports.
>
> 1.
>
>     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
>
These seem like reasonable suggestions, at least to begin, but none of 
them appear in the doc.
I worry that, absent a description of minimum browser management 
interfaces for CT, we have no sense of whether users will be able to 
deal with incremental deployment.
>
> 1.
>
>     I think that warning is acceptable in case of an absence of SCTs,
>     but in case of cryptographic errors the error should be generated.
>
I presume you mean that if there is a crypto error, the cert should be 
rejected, a hard fail, right?

Steve

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 17 Jun 2014 12:10:40 +0400

Hello Stephen,

Thank you for your reply!
My letter was composed as an answer questions you asked, so not all of my
points are in the scope of IETF.

On Mon, Jun 16, 2014 at 11:07 PM, Stephen Kent <[email-masked]> wrote:

>  Dmitry,
>
> My replies are inline. sorry that my mail program renumbered each of your
> bullets as I inserted my replies :-(.
>
>
>   Hello Stephen,
>
>    (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.
>
> CABF, but we're the IETF and this is intended to be an IETF standard. So,
> I think this
>    “important logs” should cover all the CAs supported by major browsers.
>
>    Any log server can select the algorithm of hash for Merkle Tree and
>    for its key signing the SCTs.
>
> clients must support, while log operators are allowed to pick form between
> the two. This seems a bit backwards to me, in that it imposes the greater
> burden on the larger # of implementations.
>

I think that the document should be corrected and optional algorithms
should be taken into account too.

>    default it should be a reasonable subset of “important” logs.
>
> a set of clients 9since log operators have complete discretion as to which
> CAs they accept) so it ought to be possible for a client to include a
> pointer to logs outside the default set.
>

Yes.

> doc. There is no requirement that any log operator accept submissions from
> a specific CA. Each log operator indicates what CAs/TAs it supports.
>

Yes.

>
>
>    1.
>
>    Browsers should
>     1.
>
>       allow user to accept the cert without CT providing warning about
>       absence of CT
>        2.
>
>       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
>
> interfaces for CT, we have no sense of whether users will be able to deal
> with incremental deployment.
>

So we need to specify these browser interface requirements, don't we?

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

Yes, thank you for a correct wording. IMHO, The cert MUST be rejected if
any of SCTs is signed incorrectly. If

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Jun 2014 10:34:06 +0100

> doc needs to address this issue in a fashion consistent with IETF

How would this work? From my POV it seems that users choose the logs they
pay attention to, probably mostly via choices made by their browser vendor.
How would the IETF get involved in that process?

> implementations and use decisions by vendors to drive standards.

Again, what do you suggest as an alternative?

> burden on the larger # of implementations.

This seems like physics to me. You might want it to be the other way around
(we could debate the burden, but that seems beside the point), but I don't
see how it can be.

> pointer to logs outside the default set.

I agree. However, there is a security risk here: a client that includes a
log that is not audited has opened themselves up to abuse via mis-issue.

> a specific CA. Each log operator indicates what CAs/TAs it supports.

Again, I don't see how you propose the IETF involves itself in this.
Clearly we can't say "logs must accept all CAs" because that defeats the
anti-spam objective of limiting the list of CAs.

> with incremental deployment.

The IETF is far too slow-moving to get involved in browser UI, at least for
new/experimental features. Nor do I get much sense that we have the
necessary expertise in this WG.

> rejected, a hard fail, right?

For EV certificates, there will be no warning in Chromium: instead, there
will be no EV indication.

We have not yet decided exactly how things will work when we start
requiring CT for all certificates.

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

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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 17 Jun 2014 13:55:04 +0400

Hello Ben,

On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie <[email-masked]> wrote:

>>  The set of "important" logs might not include a CA that is important
>> for a set of clients 9since log operators have complete discretion as to
>> which CAs they accept) so it ought to be possible for a client to include a

Well, now a client is able to add bad CA as trusted. I do not see extra
security risks here.

> The IETF is far too slow-moving to get involved in browser UI, at least
> for new/experimental features. Nor do I get much sense that we have the

I agree. But I think that it's a correct behavior of any CT-compliant
client. Browsers, being interactive, can suggest an user to make a choice
(yes, he will push the button "Add security exception" in 99%).
Non-interactive software is to have command-line settings/config/etc.

> will be no EV indication.

Even in case of invalid SCT?

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Jun 2014 11:15:09 +0100

> Well, now a client is able to add bad CA as trusted. I do not see extra

Even if I agreed, which I don't (if you can't add extra logs, then the
effect of adding bad CAs is reduced :-), this seems beside the point. It is
a security risk that should be considered.

> Non-interactive software is to have command-line settings/config/etc.

Yes, browsers can suggest a choice. Or they can choose not to.

> Even in case of invalid SCT?

I think if the SCT is invalid, you will be able to tell in the connection
information dropdown, but we will otherwise treat it in the same way as a
missing SCT.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jun 2014 14:28:15 -0400

Ben,

I agree that some aspects of CT operation are procedural matters that fall
outside the scope of what the IETF usually specifies when defining a 
protocol.
But, readers cannot evaluate the effectiveness of a proposed system (CT is
a system, not just a protocol) without a clear picture of what the system
designers envision wrt to operational issues. You might want to look at 
the suite
of RFCs published by the SIDR WG, defining the RPKI, as an example of 
how to address
the full range of issues associated with a big, complex system. Most of 
the RFCs are
standards track, but a few are informational; together they provide a 
fairly clear
picture of what is expected of each element of the system, and how the 
elements
are intended to work together. Topics such as key rollover were party of 
the initial
set of RFCs, as well as discussion of the expected frequency with which 
relying
parties would query repositories, etc.

I don't agree that specifying behavior for browsers is out of scope for this
WG. (Pardon me if I misunderstood part of your response.) To define the 
CT system
one needs to specify behavior for TLS servers, TLS clients,  Web PKI 
CAs, log operators,
monitors, and Auditors. The current doc does some of this, but there are 
a number of gaps.
If browser vendors are to play a major role in managing config info in 
support info
for CT, e.g, providing pointers to log and public key for logs, then 
this should be
stated explicitly.

I've just completed a detailed analysis of the CT I-D and will begin 
posting my comments,
questions, and suggested edits on Monday. No need to dump this on the 
list on a Friday :-).
The analysis is about 18 pages, so I'll break it into separate messages, 
each dealing with
a section of the I-D, plus a message offering overall comments.

Steve