Re: [Trans] CT for opportunistic STARTTLS in SMTP

[Ben Laurie <[e-mail]>]

On 25 February 2014 17:01, Paul Hoffman <[e-mail]> wrote:
> Sorry for using a valid subject line. :-)
>
> On Feb 24, 2014, at 11:28 PM, Ben Laurie <[e-mail]> wrote:
>
>> On 24 February 2014 21:43, Daniel Kahn Gillmor <[e-mail]> wrote:
>>> On 02/24/2014 04:25 PM, Melinda Shore wrote:
>>>
>>>> As for relevance, right now therightkey is the best place
>>>> for discussion of other approaches to fixing PKI, while trans
>>>> is specifically for discussion of certificate transparency.
>>>> The only thing that's in our charter at the moment is 6962bis.
>>>> That doesn't mean that other applications of CT are out-of-
>>>> scope, but that we'd need to recharter to take them on
>>>> as work items.
>>>
>>> I think you're saying you want the slot in London to focus on getting
>>> the mechanism right, and not trying to propose policy, which is
>>> completely reasonable.  I'm happy to stay focused.
>>>
>>> There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that
>>> is HTTPS-specific, though; it's defined as a mechanism for logging X.509
>>> certificates for use in TLS, regardless of the application layer traffic
>>> within the TLS session.
>>>
>>> So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other
>>> application" -- it's still TLS.  If we suspect that CT is somehow valid
>>> only for X.509 certs used by HTTPS servers, we should make that more
>>> explicit in the draft (but i hope we don't!)
>>
>> I agree. One observation: CT as applied to HTTPS uses the CA signature
>> as a spam limitation mechanism.
>>
>> I believe most SMTP certs are not CA issued, so the question arises:
>> how would you propose to limit spam?
>
> At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was.

That does not seem effective to me.

>> I am open, by the way, to running CT logs at Google with alternate
>> spam limitation mechanisms to allow this kind of usage. I think that
>> not having a spam limitation mechanism is dangerous.
>
> Spam limitation is needed for both attacks on CT to weaken it and accidental misconfiguration that could look a lot like an attack.
>
> --Paul Hoffman