Subject: [Trans] [trans] #158 (rfc6962-bis): Hash algorithm agility is hard to implement, as specified

From: "trans issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 14:49:26 -0000

#158: Hash algorithm agility is hard to implement, as specified

 The problem:
 Currently (draft 18) 6962-bis refers to the output size of the hash
 function chosen by a log (denoted HASH_SIZE) as a fixed value:

 opaque NodeHash[HASH_SIZE];

 Further structs (TreeHeadDataV2, SignedTreeHeadDataV2,
 ConsistencyProofDataV2, InclusionProofDataV2) then use this definition,
 which means parsers expect a vector of bytes of fixed length.

 The difficulty lies in having to know which log the data structure is
 parsed for before finishing parsing, as it requires parsing just the
 LogID, looking up the log's metadata by that LogID and continuing parsing
 according to the size of the NODE_HASH of that log.
 That is impossible in the case of TreeHeadDataV2 which doesn't even
 include the LogID (and is not encapsulated in anything that does).

 Ideally parsing code for parsing all log data would be independent of the
 hash algorithm chosen for the code (which would extremely simplify
 implementation in any language I've witnessed, as the TLS deserialization
 code is in a completely different layer to the signature validation code).

 Two options:
 * Force a fixed HASH_SIZE for all logs, say 32 bytes. That may not be
 silly if that space is deemed sufficient to implement secure hashes with
 (even if a particular hash function is found to be weak).
 * Use a variable-length vector for storing hashes.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 17 Aug 2016 14:38:00 -0000

Comment (by [email-masked]):

 Andrew Ayer on the idea of forcing a fixed HASH_SIZE:
 "a 32 byte long hash can provide collision resistance of 128 bits (i.e.
 2^128 operations required to find a collision).  However, with quantum
 attacks it's only ~85 bits, so fixing HASH_SIZE at 32 bytes would be
 short-sighted."

 So I'll go with a variable-length vector for hashes.

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:1>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 17 Aug 2016 14:38:17 -0000

Out for review in https://github.com/google/certificate-transparency-
 rfcs/pull/189

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:2>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 17 Aug 2016 16:18:30 -0000

Changes (by [email-masked]):

 * milestone:   => review

Comment:

 Fixed in https://github.com/google/certificate-transparency-
 rfcs/commit/9cbeb0a6715f85f0fb1282be4804642a39ecfd47

 Priority:  major        |   Milestone:  review

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:3>
trans <https://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 17 Aug 2016 16:54:51 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-trans-
  [email-masked]       |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:  review
Component:  rfc6962-bis  |     Version:
 Severity:  -            |  Resolution:  fixed
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/trans/trac/ticket/158#comment:4>
trans <https://tools.ietf.org/trans/>