Re: [Trans] IETF 90 scheduling

On 23 April 2014 15:51, Jean-Michel Combes <jeanmichel.combes@gmail.com>wrote:

> Hi,
>
> I have actually two technical comments with the current specifications of
> CT:
>
> #1 Log server identification
>
> Currently, if I am correct, the identity of the log server providing the
> SCT is based on its public key (in fact, the hash of it), which is also
> stored in the TLS client. As with the public key pinning mechanism (cf.
> draft-ietf-websec-key-pinning), I am afraid about a potential complexity
> (from a technical/business point of view) to add a new public key in the
> TLS client (e.g., web browser), to be able to set up/manage a new log
> server.
>
> So, I am wondering, instead (or in parallel) of using log server's public
> key as log server's ID, if that would be easier to use URI for new log
> servers deployment.
>

There's already been a fairly extensive discussion on this, perhaps still
not resolved. But my position continues to be that the TLS client needs to
know various things about the log - public key, URL, MMD. I don't see the
problem in those things being communicated in a data structure (e.g. in
JSON).

Indeed we will shortly be defining such a structure for Chrome's valid
logs. Whether this should form part of the RFC is up to the WG.

>
> #2 Interaction between TLSA RR and CT
>
> At first, from my point of view, using TLSA RR means "prevention" and
> using CT means "repression". Now, if I want only do "prevention", the
> current CT specifications will not allow me to do it. Indeed, as specified
> in Section 3, TLS clients MUST reject certificates that do not have a valid
> SCT for the end-entity certificate, enforcing the use of CT by the TLS
> server.
>

That is correct.

>
> Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would
> relax this enforcement.
>

No, because this gives an attacker a way to evade CT.

I would appreciate any feedback from the WG regarding these comments.
>
> Thanks in advance for your replies.
>
> Best regards,
>
> JMC.
>
>
> 2014-04-22 0:35 GMT+02:00 Melinda Shore <melinda.shore@gmail.com>:
>
> We just received notification that working group session
>> scheduling for the July meeting is now open.  This is a good
>> time to be thinking about what needs to be done between
>> now and then and how session time will be spent.  Right now
>> my sense is that a single two-hour session will be more than
>> enough, but I'll hold off until we get a better sense of
>> what will need to be done during the session.
>>
>> Melinda
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>

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