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

From: Russ Housley <[email-masked]>
Date: Thu, 3 Apr 2014 13:51:30 -0400

I gave a presentation at the SAAG session in London about this document.  Stephen said that the discussion would continue on this list.  I'm posting this message to get that discussion going.

Russ

---

From: Ben Laurie <[email-masked]>
Date: Sun, 6 Apr 2014 12:09:31 +0100

> I gave a presentation at the SAAG session in London about this document.  Stephen said that the discussion would continue on this list.  I'm posting this message to get that discussion going.

Thinking about this in the context of Certificate Transparency, it
seems there are a couple of problems with the I-D.

"IETF protocols that make use of cryptographic algorithms MUST carry
one or more algorithm identifier."

CT (at least currently) does not carry the algorithm identifier in
band, it is metadata that is known about each log. Allowing logs to
choose algorithms on-the-fly probably results in reduced security.

I guess this is because the threat model is unusual: the bad guy is
running the log. Normally one assumes that the bad guy is not one of
the endpoints.

A corollary of this is that

" If a protocol does not carry an algorithm identifier, then the
   protocol version number or some other major change is needed to
   transition from one algorithm to another.  The inclusion of an
   algorithm identifier is a minimal step toward cryptographic algorithm
   agility."

would appear to be incorrect.

Finally, I'm not really sure what s3.3 is getting at. It makes some
statements about some protocols without drawing any conclusions that I
can discern.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 6 Apr 2014 15:08:27 -0400

Not to count angels on a pin, but is CT a protocol or a set of data formats? 

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: S Moonesamy <[email-masked]>
Date: Sun, 06 Apr 2014 12:18:21 -0700

Hi Rich,
>Not to count angels on a pin, but is CT a protocol or a set of data formats?

 From RFC 6962:

  "Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document."

Regards,
S. Moonesamy

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 6 Apr 2014 17:54:34 -0400

I know what the text says.  But there are no protocol operations, really, it's just HTTP/JSON, right?

Having said that, I think the agility document should say "protocols and data formats."

I was arguing (with Google folks, mainly) for crypto identifies in the CT data structures before the WG was convened. And I still think that CT should be brought in line with the letter and spirit of the agility document:  identify the mechanisms used, in the data types. If interop is a concern, make the current set be MUST and say SHOULD NOT implement anything else.

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

	/r$

---

From: S Moonesamy <[email-masked]>
Date: Sun, 06 Apr 2014 16:05:06 -0700

Hi Rich,
>really, it's just HTTP/JSON, right?

I read the RFC again.  The better choice was "protocol operations" 
because of some requirements.  There is a thread at 
http://www.ietf.org/mail-archive/web/ietf/current/msg71257.html about 
the term "protocol".

>I was arguing (with Google folks, mainly) for crypto identifies in 
>the CT data structures before the WG was convened. And I still think 
>that CT should be brought in line with the letter and spirit of the 
>agility document:  identify the mechanisms used, in the data types. 
>If interop is a concern, make the current set be MUST and say SHOULD 
>NOT implement anything else.
>

And the above is the part which I would look at in terms of data 
formats.  It is better to solve the Certificate Transparency part in 
the TRANS working group.  The agility document is in the IAB 
Stream.  It's better to keep the two documents separate for now.

Regards,
S. Moonesamy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Apr 2014 00:22:35 +0100

Just to clarify...

On 04/07/2014 12:05 AM, S Moonesamy wrote:
> The agility document is in the IAB Stream. 

The author's goal was for this to end up as an IETF consensus
document, hence using this list and not an IAB list.

So to the extent there's an issue highlighted by CT, we should
tackle that issue.

Cheers,
S.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 06 Apr 2014 18:05:35 -0700

Hi Rich,

Replying again based on the comment from Stephen Farrell.

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

If I understood draft-iab-crypto-alg-agility-00 correctly, the point 
is to insulate the application layer protocol from the cryptography 
altogether.  The data formats would not be part of the 
protocol.  What is being done is securing the transport.  The issue 
may be clearer if the interoperability parts of 
draft-ietf-trans-rfc6962-bis-00 were identified.

Regards,
S. Moonesamy

---

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

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

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Apr 2014 09:57:40 -0400

> And the above is the part which I would look at in terms of data formats.  It is better to solve the Certificate Transparency part in the TRANS working group.  The agility document is in the IAB Stream.  It's better to keep the two documents separate for now.

I never meant to imply that they should be merged into one document; sorry if I gave that impression.

What I meant was that CT should follow the policy of the crypto-agility document; I'll continue that discussion in the other thread (with Ben).

	/r$

---

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

(Adding [email-masked])

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$

---

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: S Moonesamy <[email-masked]>
Date: Mon, 07 Apr 2014 07:30:04 -0700

Hi Rich,
>sorry if I gave that impression.

I did not read it as that. :-)

>What I meant was that CT should follow the policy of the 
>crypto-agility document; I'll continue that discussion in the other 
>thread (with Ben).

That is what I understood.

In my opinion it is a good idea to identify the end-points [1].

Regards,
S. Moonesamy

1. msg-id: 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 13:54:36 -0400

Ben,

Sorry to jump on late on this, but as a co-author of an RFC that deals
with alg agility for the RPKI, I thought I might be able to contribute.

It's generally useful to have a MUST implement alg (or set, if there are 
multiple
algs needed) for any set of protocols (data formats, etc.) to help ensure
interoperability. Selecting the MUST implement is sometimes hard, but 
it's worth
the effort.

Then one needs to have a way for all clients, CA, and log servers (in 
the CT context)
to express which alg9s) are being used at any time, so that everyone 
else knows
what choices have been made, when choices are allowed, and to guide 
folks through the
transition process.

I suggest folks read RFC 6919 as an example of how that can be done, 
although
I'm not suggesting that CT needs to adopt as thorough a model as did the 
RPKI.

Steve

---

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: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 10:00:46 -0400

Whoops.

Stephen Farrell noted that I cited the wrong RFC. It's 6916, not 6919, that
describes the alg agility design for the RPKI.

Steve

---

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

On 7 April 2014 18:54, Stephen Kent <[email-masked]> wrote:
> interoperability. Selecting the MUST implement is sometimes hard, but it's
> worth
> the effort.
>
> Then one needs to have a way for all clients, CA, and log servers (in the CT
> context)
> to express which alg9s) are being used at any time, so that everyone else
> knows
> what choices have been made, when choices are allowed, and to guide folks
> through the
> transition process.

I am not really arguing with that, actually. But in the case of CT,
this information needs to be in the metadata about the logs. The RFC
does not currently specify how that metadata becomes available to
clients (and I'm not sure it should, either).

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

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

---

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

---

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: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 14:30:50 -0400

Ben,
> clients (and I'm not sure it should, either).

Is that really the only option, i.e., externally-distributed alg info?

I worry that this will be a problem. The RFC really needs to address this.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 14:33:22 -0400

Ben,

> describe how clients decide what logs they are prepared to accept. I
It may be OK to separate the discussions, but there needs to be an 
architecture
doc that does address these questions. I fact I think it needs to 
precede the
details that the current doc addresses.

Steve

---

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