Re: [therightkey] Revised Draft Charter for Transparency WG

[Ben Laurie <[e-mail]>]

On 7 January 2014 18:04, Tim Moses <[e-mail]> wrote:
> I see. It seems unfortunate that reliance on one or more time stamps is not sufficient, but that the client also has to consult the log.

The client audits the log, which is a different thing.

To make a TLS connection, the timestamps are sufficient.

>
> All the best. Tim.
>
>> On Jan 7, 2014, at 12:40 PM, "Ben Laurie" <[e-mail]> wrote:
>>
>>> On 7 January 2014 17:26, Tim Moses <[e-mail]> wrote:
>>> Ok.  But that's at least one additional round trip, right?
>>
>> It does not need to be done before accepting the certificate. CT is
>> designed around responsiveness at the cost of finding out bad things
>> happened a little late. But this seems like an acceptable trade-off,
>> since a log still can only misbehave once (or for a short period of
>> time), which makes the cost of doing so very high.
>>
>>> Is it more realistic to say that the protocol fails if ALL of the CA and every timestamp relied upon is untrustworthy?
>>
>> I'm not sure what you mean by this, but perhaps the above makes it irrelevant?
>>
>>>
>>> All the best. Tim.
>>>
>>>
>>>>> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" <[e-mail]> wrote:
>>>>>
>>>>> On 7 January 2014 16:37, Tim Moses <[e-mail]> wrote:
>>>>> Hi Ben.  Is it explained somewhere how it would be discovered that a log had issued a time stamp for a certificate that it then did not log?
>>>>
>>>> RFC 6962, Section 5.4 "Auditor".
>>>>
>>>>> According to my understanding, the time stamp would only be distributed within a certificate or OCSP response, and (therefore) its existence would not necessarily be apparent to an auditor.
>>>>
>>>> If no-one ever sees the certificate, then whether an SCT was issued or
>>>> not is unimportant. This is why recipients of certificates need to at
>>>> least audit the certificates they see.
>>>>
>>>> In the RFC "auditor" is a role that may be incorporated in other
>>>> things. From the RFC: "An auditor might be an integral component of a
>>>> TLS client".
>>>>
>>>> There may be a better way of explaining this.
>>>>
>>>> Possibly something to this effect should've been added to 5.2. I've
>>>> added an issue (https://code.google.com/p/certificate-transparency/issues/detail?id=25).
>>>>
>>>>> Maybe I missed something.
>>>>>
>>>>> All the best. Tim.
>>>>>
>>>>>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" <[e-mail]> wrote:
>>>>>>
>>>>>> Problem statement: many Internet protocols require a mapping between
>>>>>> some kind of identifier and some kind of key, for example, HTTPS,
>>>>>> SMTPS, IPSec, DNSSEC and OpenPGP.
>>>>>>
>>>>>>
>>>>>> These protocols rely on either ad-hoc mappings, or on authorities
>>>>>> which attest to the mappings.
>>>>>>
>>>>>>
>>>>>> History shows that neither of these mechanisms is entirely
>>>>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain,
>>>>>> and authorities make mistakes or are subverted.
>>>>>>
>>>>>>
>>>>>> Cryptographically verifiable logs[1] can help to ameliorate the
>>>>>> problems by making it possible to discover and rectify errors before
>>>>>> they can cause harm.
>>>>>>
>>>>>>
>>>>>> These logs can also assist with other interesting problems, such as
>>>>>> how to assure end users that software they are running is, indeed, the
>>>>>> software they intend to run.
>>>>>>
>>>>>>
>>>>>> Work items: Specify a standards-track mechanism to apply verifiable
>>>>>> logs to HTTP/TLS (i.e. RFC 6962-bis).
>>>>>>
>>>>>>
>>>>>> Discuss mechanisms and techniques that allow cryptographically
>>>>>> verifiable logs to be deployed to improve the security of protocols
>>>>>> and software distribution. Where such mechanisms appear sufficiently
>>>>>> useful, the WG will re-charter to add relevant new work items.
>>>>>>
>>>>>>
>>>>>> [1] A cryptographically verifiable log is an append-only log of hashes
>>>>>> of more-or-less anything that  is structured in such a way as to
>>>>>> provide efficiently-accessible, cryptographically-supported evidence
>>>>>> of correct log behaviour.
>>>>>>
>>>>>>
>>>>>> For example, from RFC 6962: “The append-only property of each log is
>>>>>> technically achieved using Merkle Trees, which can be used to show
>>>>>> that any particular version of the log is a superset of any particular
>>>>>> previous version. Likewise, Merkle Trees avoid the need to blindly
>>>>>> trust logs: if a log attempts to show different things to different
>>>>>> people, this can be efficiently detected by comparing tree roots and
>>>>>> consistency proofs. Similarly, other misbehaviors of any log (e.g.,
>>>>>> issuing signed timestamps for certificates they then don't log) can be
>>>>>> efficiently detected and proved to the world at large.”
>>>>>>
>>>>>>
>>>>>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
>>>>>> and http://www.links.org/files/RevocationTransparency.pdf for
>>>>>> background.
>>>>>> _______________________________________________
>>>>>> therightkey mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/therightkey