Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Apr 2014 10:00:37 -0400

(Adding [email-masked])

Me:
> CT should not be a special case exemption from the agility spec.

Ben:
> I think it should, and here's why: normally you want agility so endpoints can change their crypto in an orderly way, so as to phase out weak algorithms. In CT the endpoint is the enemy: you don't want it to be able to choose algorithms that suit it.

What is the endpoint?  The  log server?  I don't understand the point.

And as I said, why can't you get the same effect with proper use of ALL CAPS words in the RFC?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Ben Laurie <[email-masked]>
Date: Mon, 7 Apr 2014 15:37:10 +0100

> What is the endpoint?  The  log server?  I don't understand the point.

Yes, the log server.

> And as I said, why can't you get the same effect with proper use of ALL CAPS words in the RFC?

What effect? You mean define an algorithm that the log server MUST use?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Apr 2014 15:08:04 -0400

So the concern is log servers that are going to reserve the right to "go rogue" by using weak crypto that could be subverted?  Or is there a different concern?
 
I believe this can be addressed by leaving the data formats future-proof, but mandating the crypto in the RFC. For example, put a hash identifier (OID, TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256."  To make it even stronger, you could set up an IANA registry. Being pragmatic, nobody's going to implement anything other than what Chrome supports, at least at first. And by making log data self-identifying, you can (quietly) perform experiments on new crypto types.

	/r$

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Apr 2014 15:08:11 +0100

> So the concern is log servers that are going to reserve the right to "go rogue" by using weak crypto that could be subverted?  Or is there a different concern?

Right, that's the concern.

> I believe this can be addressed by leaving the data formats future-proof, but mandating the crypto in the RFC. For example, put a hash identifier (OID, TLS id, whatever) in the hash entry, but the…

As I responded to Steve, I agree that there should be an identifier,
but it belongs in the metadata about the logs. The RFC does not (and
arguably should not) specify how logs get that metadata, nor what
format it is in.

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Apr 2014 10:10:01 -0400

> As I responded to Steve, I agree that there should be an identifier, but it belongs in the metadata about the logs.

I do not understand why metadata is more secure then the data itself.

I strongly disagree that CT should be a special case from the general agility doc.

	/r$

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Apr 2014 15:14:24 +0100

> I do not understand why metadata is more secure then the data itself.

It is created by a different authority.

> I strongly disagree that CT should be a special case from the general agility doc.

I am not saying it is a special case, I am disputing where the agility
should happen. :-)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Apr 2014 10:18:18 -0400

> It is created by a different authority.

?  Is this in the part of the RFC that is still TBD?

	/r$

---

From: Ben Laurie <[email-masked]>
Date: Tue, 8 Apr 2014 15:21:28 +0100

> ?  Is this in the part of the RFC that is still TBD?

The RFC describes how logs work and how clients work. It does not
describe how clients decide what logs they are prepared to accept. I
am not sure it should.

But whoever does also decides whether the algorithms in use by the
logs are acceptable and tells the client what those algorithms are
(along with other things, like the log's key, base URL and MMD).

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 8 Apr 2014 18:28:51 +0400

Hello Ben,

On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie <[email-masked]> wrote:

> I think that the client should be able to find out the algorithm used by
log because it cant'be changed during the log lifetime. And if the RFC
specifies the URIs for certificate submit, it seems to me that it's
reasonable to specify the URI for finding out the algorithm. But I prefer
to leave out of band of the protocol only the data that can't be passed
using it.

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Apr 2014 20:49:30 -0400

Since TRANS is joined to X.509 at the hip, how about we just shovel
all the metadata describing the configuration of the notary into the
certificate that signs the notary log outputs periodically?

I am assuming here that the signing hierarchy for the log has an
offline key that periodically signs the online key. The cert for the
online key can specify the notary algorithm by OID (its ASN.1 after
all) and any other parameters that might be useful. Probably want to
allow for different accumulation strategies in case we ever decide a
binary tree isn't the only choice. Might have some other options.
Might want to be able to specify the CPS/CP equivalents for the
notary, etc.

On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky <[email-masked]> wrote:
> I think that the client should be able to find out the algorithm used by log
> because it cant'be changed during the log lifetime. And if the RFC specifies
> the URIs for certificate submit, it seems to me that it's reasonable to
> specify the URI for finding out the algorithm. But I prefer to leave out of
> band of the protocol only the data that can't be passed using it.
>
> Thank you!
>
> --
> SY, Dmitry Belyavsky
>

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 9 Apr 2014 14:13:08 +0100

> certificate that signs the notary log outputs periodically?

I guess if you are a CA everything looks like a certificate.
Currently, logs do not use certificates to manage their own keys. I
guess they could. But I thought you preferred JSON for new stuff?

> offline key that periodically signs the online key.

Again, currently, no. Seems to me that you can introduce a lot of
complication this way not needed for the only known client use case
(deployment in Chrome). Not against specifying it, to be clear, but
unsure it should live in the same doc. Or hold it up.

> The cert for the

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Apr 2014 20:55:04 -0400

> guess they could. But I thought you preferred JSON for new stuff?

I do, but I also prefer to avoid long discussions that I don't think I
am going to win.

As a general matter, most mechanisms that manage keys are likely to
generate X.509v3 certificates or CRSs as a by product. Even some of
the DNSSEC stuff generates them.

> unsure it should live in the same doc. Or hold it up.

I tend to think that anyone who would check cert status against TRANS
is already doing X.509v3 and bar