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

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.

>
>
>>
>
>>
>>    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.

>
>>
>>
>>    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?

>
> 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