Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

On 17 June 2014 10:55, Dmitry Belyavsky <beldmit@gmail.com> wrote:

> Hello Ben,
>
>
> On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie <benl@google.com> wrote:
>
>>
>>
>>
>> On 16 June 2014 20:07, Stephen Kent <kent@bbn.com> wrote:
>>
>>>
>>>
>>>
>>>    1.
>>>
>>>    Each browser should provide an editable way of managing logs. By
>>>    default it should be a reasonable subset of “important” logs.
>>>
>>>  The set of "important" logs might not include a CA that is important
>>> for a set of clients 9since log operators have complete discretion as to
>>> which CAs they accept) so it ought to be possible for a client to include a
>>> pointer to logs outside the default set.
>>>
>>
>> I agree. However, there is a security risk here: a client that includes a
>> log that is not audited has opened themselves up to abuse via mis-issue.
>>
>
> Well, now a client is able to add bad CA as trusted. I do not see extra
> security risks here.
>

Even if I agreed, which I don't (if you can't add extra logs, then the
effect of adding bad CAs is reduced :-), this seems beside the point. It is
a security risk that should be considered.

>
>
>>
>>
>>>
>>
>>>
>>>    1.
>>>
>>>    Browsers should
>>>     1.
>>>
>>>       allow user to accept the cert without CT providing warning about
>>>       absence of CT
>>>        2.
>>>
>>>       allow user to specify absence of log for this or that domain
>>>       (non-public suffix)
>>>        3.
>>>
>>>       allow user to a particular log for this or that domain and return
>>>       an error if there is no SCT for id provided by this log.
>>>        4.
>>>
>>>       there should be a procedure of report about log misbehaviour in
>>>       case of invalid log records
>>>
>>>  These seem like reasonable suggestions, at least to begin, but none of
>>> them appear in the doc.
>>> I worry that, absent a description of minimum browser management
>>> interfaces for CT, we have no sense of whether users will be able to deal
>>> with incremental deployment.
>>>
>>
>> The IETF is far too slow-moving to get involved in browser UI, at least
>> for new/experimental features. Nor do I get much sense that we have the
>> necessary expertise in this WG.
>>
>
> I agree. But I think that it's a correct behavior of any CT-compliant
> client. Browsers, being interactive, can suggest an user to make a choice
> (yes, he will push the button "Add security exception" in 99%).
> Non-interactive software is to have command-line settings/config/etc.
>

Yes, browsers can suggest a choice. Or they can choose not to.

>
>
>
>>
>>>
>>>
>>>    1.
>>>
>>>    I think that warning is acceptable in case of an absence of SCTs,
>>>    but in case of cryptographic errors the error should be generated.
>>>
>>>  I presume you mean that if there is a crypto error, the cert should be
>>> rejected, a hard fail, right?
>>>
>>
>> For EV certificates, there will be no warning in Chromium: instead, there
>> will be no EV indication.
>>
>
> Even in case of invalid SCT?
>

I think if the SCT is invalid, you will be able to tell in the connection
information dropdown, but we will otherwise treat it in the same way as a
missing SCT.

>
>
>>
>> We have not yet decided exactly how things will work when we start
>> requiring CT for all certificates.
>>
>>
>>>
>>> Steve
>>>
>>> _______________________________________________
>>> Trans mailing list
>>> Trans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trans
>>>
>>>
>>
>>
>> --
>> Certificate Transparency is hiring! Let me know if you're interested.
>>
>
>
>
> --
> SY, Dmitry Belyavsky
>

-- 
Certificate Transparency is hiring! Let me know if you're interested.