Subject: [Trans] Policy for adding to IANA registries requested in 6962-bis

From: Eran Messeri <[email-masked]>
Date: Mon, 12 Dec 2016 15:44:28 +0000

No policy has been specified in 6962-bis for adding values to the IANA
registries requested.

In https://github.com/google/certificate-transparency-rfcs/pull/215 I
propose the following policies, all based on definitions in RFC5226:
* Hash algorithms and Signature algorithms: Expert Review
* SCT extensions and STH extensions: Specification Required
* Log ID 1, Log ID 2: First Come First Served.

Feedback welcome, since, as far as I recall, this topic was not discussed
on the list previously.

Eran

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Dec 2016 15:47:57 +0000

> In https://github.com/google/certificate-transparency-rfcs/pull/215 I propose the following policies, all based on definitions in RFC5226:

+1 for all.

---

From: Eran Messeri <[email-masked]>
Date: Mon, 12 Dec 2016 15:54:03 +0000

Some background as to why I propose each of the policies:
* Expert Review for Hash algorithm and Signature algorithm: The algorithm
selection does not affect the behaviour of the protocol. However, an expect
should make sure proposed additions are suitable (for example, that a
proposed hash algorithm does not suffer from known preimage attacks).
* Specification requirement for SCT & STH extensions: new values for these
extensions are meaningless without specifying what they do - how should
clients behave when encountering them.
* First-come-first-served for Log IDs: I can't see how an expect review
could be meaningful, given log operators requesting those IDs can't really
prove competence to "own" log IDs, so requiring a "minimal amount of
clerical information" seems enough.

Eran

---

From: Rob Stradling <[email-masked]>
Date: Tue, 13 Dec 2016 00:53:25 +0000

On 12/12/16 15:54, Eran Messeri wrote:
> * Expert Review for Hash algorithm and Signature algorithm: The
> algorithm selection does not affect the behaviour of the protocol.
> However, an expect should make sure proposed additions are suitable (for
> example, that a proposed hash algorithm does not suffer from known
> preimage attacks).

https://tools.ietf.org/html/rfc5226 section 4.1 says (emphasis mine):
   "Expert Review (or Designated Expert) - approval by a Designated
          Expert is required.  The *required documentation* and review
          criteria for use by the Designated Expert should be provided
          when defining the registry."

So I think we should specify both Expert Review and Specification 
Required, just as (for example) https://tools.ietf.org/html/rfc6844 
section 7.2 does:
   "Addition of tag identifiers requires a public specification and
    Expert Review as set out in..."

Separately, should we reserve some values in either or both of these 
registries for Private Use or for Experimental Use?

> * Specification requirement for SCT & STH extensions: new values for
> these extensions are meaningless without specifying what they do - how
> should clients behave when encountering them.

+1 (and for the VersionedTransType registry we just added too)

Separately, should we reserve some values in any of these registries for 
Private Use or for Experimental Use?

> could be meaningful, given log operators requesting those IDs can't
> really prove competence to "own" log IDs, so requiring a "minimal amount
> of clerical information" seems enough.

+1

> Eran
>
> On Mon, Dec 12, 2016 at 3:44 PM, Eran Messeri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     No policy has been specified in 6962-bis for adding values to the
>     IANA registries requested.
>
>     In https://github.com/google/certificate-transparency-rfcs/pull/215
>     <https://github.com/google/certificate-transparency-rfcs/pull/215> I
>     Feedback welcome, since, as far as I recall, this topic was not
>     discussed on the list previously.
>
>     Eran
>
>
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 12 Dec 2016 20:39:05 -0500 (EST)

On Tue, 13 Dec 2016, Rob Stradling wrote:

> So I think we should specify both Expert Review and Specification Required, 
> just as (for example) https://tools.ietf.org/html/rfc6844 section 7.2 does:

Sounds good.

> registries for Private Use or for Experimental Use?

Yes please.

> Private Use or for Experimental Use?

Yes.

>>  of clerical information" seems enough.

It would be nice to have some kind of rules or documentation, and at
least have an Expert around to block strange or excessive requests?

Stephen: how would you see this happening?

Paul

> This e-mail and any files transmitted with it are confidential and intended 
> solely for the use of the individual or entity to whom they are addressed. 
> If you have received this email in error please notify the sender by replying 
> to the e-mail containing this attachment. Replies to this email may be 
> monitored by COMODO for operational or business reasons. Whilst every 
> endeavour is taken to ensure that e-mails are free from viruses, no liability 
> can be accepted and the recipient is requested to use their own virus 
> checking software.
>

---

From: Eran Messeri <[email-masked]>
Date: Tue, 13 Dec 2016 14:32:04 +0000

Rob and I had a chat, we have the following proposals (which Rob may
correct in case I got something wrong):

* For Hash Algorithm repository, specify "Expert Review" guiding the Expert
to make sure the proposed hash algorithm has public specification and does
not suffer from known preimage attacks.

* For the Signature Algorithm repository, specify "Expert Review" guiding
the Expert to make sure the proposed signature algorithm has public
specification and can generate signatures deterministically.

* For the STH extensions, SCT extensions and VersionedTransType: Require a
public specification that accompanies the proposed additional values and an
expert review of the public specification, to ensure the public
specification is detailed enough for interoperable implementations.

* For the Log ID 2 repository: First-Come-First-Served, only requirement is
to fill in a template that contains the log metadata.

* For the Log ID 1 repository: Require Expert Review, guiding the Expert to
make sure the requester is requesting the OID in good faith with the
intention of running a CT log (since that's a limited resource). The log
metadata is still required.

On Tue, Dec 13, 2016 at 1:39 AM, Paul Wouters <[email-masked]> wrote:

>> this email may be monitored by COMODO for operational or business reasons.
>> Whilst every endeavour is taken to ensure that e-mails are free from
>> viruses, no liability can be accepted and the recipient is requested to use
>> their own virus checking software.
>>

---

From: Eran Messeri <[email-masked]>
Date: Tue, 13 Dec 2016 15:45:41 +0000

Text to describe the policies and expert reviews was added in:
https://github.com/google/certificate-transparency-rfcs/commit/615a8c3be0acfc6461f6d3043d19ecc863f3888b

On Tue, Dec 13, 2016 at 2:32 PM, Eran Messeri <[email-masked]> wrote:

> * For Hash Algorithm repository, specify "Expert Review" guiding the
> Expert to make sure the proposed hash algorithm has public specification
> and does not suffer from known preimage attacks.
>
> * For the Log ID 2 repository: First-Come-First-Served, only requirement
> is to fill in a template that contains the log metadata.
>
> * For the Log ID 1 repository: Require Expert Review, guiding the Expert
> to make sure the requester is requesting the OID in good faith with the

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 13 Dec 2016 15:59:17 -0800

On Tue, 13 Dec 2016 14:32:04 +0000
Eran Messeri <[email-masked]> wrote:

> Expert to make sure the proposed hash algorithm has public
> specification and does not suffer from known preimage attacks.

The hash algorithm also needs collision resistance.

How precise does the guidance need to be?  "Not suffer from known
preimage attacks" wouldn't be construed as forbidding SHA-2 because
there are some very expensive preimage attacks on some rounds, would it?

Arguably, "suitable for use as a cryptographic hash function" covers
both preimage and collision resistance, and leaves it to the expert's
discretion what attacks are worth worrying about.  Would leaving it at
this provide sufficient guidance?

Regards,
Andrew

---

From: Bill Frantz <[email-masked]>
Date: Tue, 13 Dec 2016 16:20:10 -0800

>this provide sufficient guidance?

It might be better to specifically mention the characteristics 
known to be needed along with some general guidance which leans 
on the reviewer's expertise. Perhaps:

"Suitable for use as a cryptographic hash with no known preimage 
or collision attacks. These attacks can damage the integrity of 
the log."

Cheers - Bill

------------------------------------------------------------------------
Bill Frantz        |"Insofar as the propositions of mathematics 
refer to
408-356-8506       | reality, they are not certain; and insofar 
they are
www.pwpconsult.com | certain, they do not refer to reality.” 
-- Einstein

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Dec 2016 00:48:26 +0000

Hiya,

Just a comment from the sidelines...

On 14/12/16 00:20, Bill Frantz wrote:
> 
> "Suitable for use as a cryptographic hash with no known preimage or
> collision attacks. These attacks can damage the integrity of the log."

If taking this approach it might be useful to consider the
duration for which any such properties are desired, e.g. to
consider how that duration maps to hashes used in certificate
signing would seem like a natural enough thing to do. And it
might even be the case that such consideration provides a way
to avoid a separate registry maybe, not sure.

S.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Dec 2016 11:46:55 +0000

FYI, I've been revamping the 6962-bis registry sections in this PR:
https://github.com/google/certificate-transparency-rfcs/pull/216

---

From: Eran Messeri <[email-masked]>
Date: Wed, 14 Dec 2016 12:27:34 +0000

On Wed, Dec 14, 2016 at 12:48 AM, Stephen Farrell <[email-masked]
> wrote:

> to avoid a separate registry maybe, not sure.
IIUC the question is for how long a hash algorithm used in a log should be
resistant to preimage or collision attacks.
A simple answer would be "for the entire lifetime of the log" (with the
expectation that new logs would be spun up with better hash algorithms if
the one in current use doesn't have these properties anymore).
A more in-depth analysis of how the protocol would break if the hash
algorithm used by logs is a good idea, merits more thought though (and may
belong in the threat analysis document?).

Re a separate registry, I've looked into re-using existing registries
(following a suggestion from a colleague, David Drysdale), but concluded
that  it would complicate implementation by tying them to implementations
of more hash algorithms than is necessary or useful to the protocol. Since
each hash algorithm has to be evaluated for suitability for use in CT logs
anyway, I didn't see much point in re-using an existing registry and
specifying a bunch of exceptions on top of it.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Dec 2016 10:49:26 -0500 (EST)

> https://github.com/google/certificate-transparency-rfcs/pull/216

I think we reached a point where it has become rather confusing to
see many small changes and pull requests on github. I think it would
be a good idea to put out a new draft version with these changes.

Then we can do a quick WGLC on the changes and move this document
along.

Paul

---

From: Eran Messeri <[email-masked]>
Date: Wed, 14 Dec 2016 17:06:42 +0000

> be a good idea to put out a new draft version with these changes.
Rob just did (thanks Rob!).

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Dec 2016 17:47:18 +0000

To view the changes to the .txt format of the I-D:
https://www.ietf.org/rfcdiff?url1=draft-ietf-trans-rfc6962-bis-19&url2=draft-ietf-trans-rfc6962-bis-22

To view the changes to the .md source file:
https://github.com/google/certificate-transparency-rfcs/compare/a3a5a20595c75c2cf0ee5170b2a4d18c4a5fb420...17e7404be8c4727fbc9dc57c10ed55626833cdb9
(Click "Files changed", then "Load diff" for 
draft-ietf-trans-rfc6962-bis.md)

On 14/12/16 17:06, Eran Messeri wrote:
>
> On Wed, Dec 14, 2016 at 3:49 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <https://github.com/google/certificate-transparency-rfcs/pull/216>
>
>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 14 Dec 2016 17:54:55 +0000

Specifically, that's the changes to the document since the (second) WGLC 
that took place in September.