On Wed, 18 Jan 2017, Richard Barnes wrote:

Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue 
logs.  Without some sort of
consistency checking mechanism, logs can lie without any risk of discovery.  
That is true of CT as deployed
today.  There is no way to detect a rogue log.

6962bis defines a method of logging.

If you want to use that logging to discover bad parties, you need to use
that logging. For example:

https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/

Also, a description of a Monitor to perform those functions was started here:

https://tools.ietf.org/html/draft-kent-trans-monitor-auditor/

The problem here is that the document is not clear about what guarantees it 
provides, and where it tries to
explain clearly it assumes a mechanism for auditing SCTs exists.  For example:

That got spun of into a separate document:

http://tools.ietf.org/html/draft-ietf-trans-threat-analysis/

So either we need to block this document on the creation of some auditing 
mechanism that we all feel
comfortable with, or we need to put some clear warning labels on this thing in 
terms of the guarantees it
provides, and in particular, its vulnerability to rogue logs.

<chair hat on>

It was decided a long time ago not to block the 6962bis document for
these other documents. Do you believe that something in the formats of
6962bis MUST be changed to accomodate its use?

We had hoped that the threat document would have been ready by the
time 6962bis went into LC. While it is close, there seems to be an
unfortunate stalemate with a few people to move this document forward
bundled with 6962bis.

If you wish to offer some text for 6962bis that would satisfy you,
that might be useful for the WG to make a decision on.

<chair hat off>

In particular, I wonder if this is another example of the pain we have pain we 
have undertaken by having a
single global Merkle tree instead of some more flexible structure.

Something like TLSA records? :)

Paul

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

Reply via email to