Subject: Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID

From: "trans issue tracker" <[email-masked]>
Date: Thu, 03 Sep 2015 22:09:12 -0000

#105: Shrink LogID

Comment (by [email-masked]):

 Alternative idea: Use a truncated hash of the log public key as the LogID.
 How many bits would be needed?

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  enhancement              |      Status:  new
 Priority:  major                    |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 04 Sep 2015 09:53:04 -0000

#105: Shrink LogID

Comment (by [email-masked]):

 I found that the use of the key's hash as the log ID very useful when
 implementing RFC6962: There is no disambiguity regarding the issuing log,
 there are no chances of discrepancy between key and log ID and no chance
 of missing log metadata hampering signature validation (the only piece of
 information a client absolutely needs to know about a log is its key).

 For this reason I don't support the suggestion of using an OID.
 Truncating the hash sounds more reasonable.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 07 Sep 2015 14:10:15 -0000

#105: Shrink LogID

 Replying to [comment:3 eranm@…]:
 <snip>
 > Truncating the hash sounds more reasonable.

 I'm minded to agree to you, Eran.

 If LogID is an OID (or indeed anything that's not derived from the log
 public key), a log operator might be tempted to set up multiple logs that
 have different LogIDs but that use the same keypair.  That sounds like a
 bad idea to me, so I think it'd be best to avoid opening up that
 possibility.

 How many bits of truncated hash is enough?  32 bits?

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

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 08 Sep 2015 12:49:53 -0000

#105: Shrink LogID

Comment (by [email-masked]):

 If the ID is too short, you fail to meet the "no chance of discrepancy
 between ID and key" goal. 32 bits is certainly too short to be comfortable
 about that.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:5>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 08 Sep 2015 13:40:03 -0000

#105: Shrink LogID

 I just chatted to Ben.  We're inclined to stick with the OID proposal (see
 Description of this ticket).

 Let's also add some text along the lines of:
 "A log MUST NOT use the same keypair as any other log"

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:6>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 08 Sep 2015 16:57:54 -0000

#105: Shrink LogID

Comment (by [email-masked]):

 How many bytes would a typical OID encoded as described be?

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:7>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 08 Sep 2015 19:05:36 -0000

#105: Shrink LogID

Comment (by [email-masked]):

 Hi Adam, it really depends on the OID that the log operator is able to
 allocate for their log. The smallest would be around 3 bytes without the
 ASN.1 tag. However, they can be much longer, the OID for sha256WithRSA is
 9 bytes while CT's SCT OID is 10 bytes without the ANS.1 tags.

 You can see a visual here (oid related bytes are colored gold):
 [http://www.cem.me/20150121-cert-binaries-3.html]

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:8>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 09 Sep 2015 21:15:01 -0000

#105: Shrink LogID

 Thanks - and reading up it looks like anyone can easily create an OID
 based on a UUID (e.g. for testing) without needing to go and register it
 anywhere.

 So by way of example,
 http://www.itu.int/en/ITU-T/asn1/Pages/UUID/generate_uuid.aspx gave me:

 ea203d20-5736-11e5-96b8-0002a5d5c51b

 with an OID equivalent of:

 2.25.311206744302421014316069734894592705819

 which encodes (using https://www.viathinksoft.com/~daniel-marschall/asn.1
 /oid-converter/online.php) as:

 06 14 69 83 D4 A0 9E C8 8A F3 B0 C7 CB 96 DC 80 80 AA AE D7 8A 1B

 The first two bytes of which we can strip, leaving us with 20 bytes.

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:9>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 10 Sep 2015 12:37:06 -0000

#105: Shrink LogID

 ASN.1 tag.

 I'm optimistic that we'll be able to find an organization that owns a
 1.3.<X> OID arc (where X<=127) and that will be willing to either:

 1. delegate a single 1.3.<X>.<Y> subordinate arc (where Y<=127) so that
 any log will be able to request a 1.3.<X>.<Y>.<Z> OID.  (Without the ASN.1
 tag and length, that would be 4 bytes for the first 128 logs, then 5 bytes
 thereafter).
 or
 2. delegate a portion of the OID range 1.3.<X>.<0..16383>.  (Without the
 ASN.1 tag and length, that would be 4 bytes for many more than just the
 first 128 logs, and maybe even 3 bytes for the first few logs).

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105#comment:10>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Sep 2015 13:19:30 -0400

Folks,

I'm puzzled by the decision to use OIDs here, instead of a public key hash.
The latter seems to offer nice security properties and doesn't have to
rely on a log operator to follow a requirement to change public keys for
each log instance. The former appears to be attractive only because one
could structure the OIDs to indicates that successive log instances are 
related.
But, if one uses OIDs that are not part of an allocation that is not managed
by an org like the IETF or ITU, then the assurances that the OID structure
follows the suggested approach are vague.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 14 Sep 2015 10:46:15 +0100

> Folks,

Hi Steve.

> each log instance.

But ISTM that 32 bytes (assuming SHA-256) is an unnecessarily bloaty
scheme for uniquely identifying each log.

> The former appears to be attractive only because one

I agree that you could structure the OIDs to indicate relationships
between logs, but that's not what this ticket proposes.

This ticket is about reducing unnecessary bloat.

> But, if one uses OIDs that are not part of an allocation that is not
> managed by an org like the IETF or ITU, then the assurances that the OID
> structure follows the suggested approach are vague.

Any OID will do, as long as no two logs share the same OID.  Personally
I don't think this needs to be managed by IETF or ITU.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Sep 2015 15:32:12 -0400

Rob,

> scheme for uniquely identifying each log.
I agree that one can design smaller IDs, but they lack the nice security 
property
that comes from using the public key (or a hash thereof?).
> This ticket is about reducing unnecessary bloat.
I appreciate the desire to avoid unnecessary bloat, but if that causes 
us to have
to rely on procedural security measures instead of algorithmic ones, I'm not
convinced that the tradeoff is a good one.
> I don't think this needs to be managed by IETF or ITU.

Again, I agree that one could manage OIDs for this separate from existing
systems, but that just means that some new party is responsible. Why not 
make
use of existing OID management entities?

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 Sep 2015 21:17:20 +0100

> convinced that the tradeoff is a good one.

Procedural security measures?

I don't see how any security measure is needed.  The only purpose of the
LogID field is, AFAICT, to give clients a hint about which log public
key should be used to verify an SCT.

We could ditch the LogID field if we thought clients would be prepared
to loop through all known log public keys until verification succeeds or
all keys have been tried.

> make use of existing OID management entities?

I proposed using OIDs from any OID arcs because I think making use of
existing management entities would be overkill for allocating LogIDs.

(If we had to involve IANA in allocating LogIDs, then I would not
propose to use OIDs at all.  Instead, I would propose "uint32 LogID",
with unique integers allocated from a new dedicated IANA registry).

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Sep 2015 11:52:25 -0400

Rob,

> ...
I thought I recall someone suggesting that the move to an OID (vs. key/hash)
would require that someone(?) check to make sure that a log operator didn't
re-use the same key with a new log instance. I'd call that a procedural 
secruity
measure.
> all keys have been tried.
The issue I was citing is different from what you note above, i.e., the
possibility that a log operator changes the ID but not the key.
> ...
that strikes me as a reasonable compromise.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Sep 2015 16:18:57 +0000

> re-use the same key with a new log instance. I'd call that a procedural

This is true even if you use hashes, surely? For example, an old key (from
a log no longer known to someone) could be reused. Or a key for a log that
was never used publicly. Or the same key could be used for two logs
accepted by different clients. And so on.