Subject: Re: [Trans] SCT encoding

From: Ben Laurie <[email-masked]>
Date: Thu, 5 Feb 2015 12:42:13 +0000

On 12 December 2014 at 20:53, Stephen Kent <[email-masked]> wrote:

> Ben,
>
>  On 11 December 2014 at 16:50, Paul Wouters<[email-masked]>  wrote:
>>
>>> On Thu, 11 Dec 2014, Melinda Shore wrote:
>>>
>>>  One of the open issues (ticket 34:
>>>> https://tools.ietf.org/wg/trans/trac/ticket/34)
>>>> concerns SCT syntax, with Steve Kent arguing that either ASN.1 should
>>>> be used or that there needs to be a clearer justification for the
>>>> choice of 5246 representation (see RFC 5246, section 4).  We need to
>>>> come to a decision whether or not to go ahead and carry forward what's
>>>> in 6962 (the TLS format).  This is a call for discussion - we'd really
>>>> like to close this in the next week or so.
>>>>
>>> See also Ben's slide deck from IETF-91 (slide 6 & 7)
>>>
>>> http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf
>>>
>>> And the raw minutes (look for "slides-91-trans-4.pdf" in the text)
>>>
>>> http://www.ietf.org/proceedings/91/minutes/minutes-91-trans
>>>
>>> Ben has argued that SCT's appear only as TLS structures or DER format,
>>> and prefers the TLS structure as the DER format is used with OCSP only.
>>>
>> Actually, also used in certs.
>>
> Yes, but when used in certs (and OCSP responses) the SCT will be in
> an ASN.1 encoded context.
>
>> Steve has argued against that since two of the three formats are ASN.1.
>>>
>> That's not really an argument. My argument is that in ten years' time
>> almost all CT info will be transmitted as TLS extensions.
>>
> I think mine is a very valid argument based on the fact that 6962-bis
> proposed 3 ways to convey the same data and did not explain why we need
> all three ways. Your argument above says that CAs will (essentially) cease
> logging pre-certs, after having rewritten their code to do so to meet
> Google's mandate for EV certs and Chrome acceptance in early 2015. This
> seems
> like a questionable projection to me, but maybe there are other details
> that
> lead you to this conclusion, but which you have mot shared. Can you
> elaborate
> on why you anticipate such a change? (The analysis should be on the list,
> to
> facilitate discussion, but it also belongs in the document if the WG elects
> to retain the 5246 encoding convention.)
>

My thinking is that:

1. There is concern, generally, about the size of certificates (really
about the size of handshakes).

2. Embedding SCTs in certs leads to more bloat than either OCSP stapling or
the TLS extension because the SCTs cannot be updated, and so more are
required (see Chrome's EV/CT policy).

3. Embedding SCTs in certs runs the risk that the SCTs will become invalid
before the cert does.

4. Certs are not generally updated before expiry.

5. Stapled OCSP requires the CA, the webserver and the CT logs to be
actively involved.

6. The TLS extension only requires the webserver and the CT logs to be
actively involved.

7. All three mechanisms can be made essentially automatic from the
webservers POV.

So, I would expect in the long run that the TLS extension would be the
favoured option.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 5 Feb 2015 12:47:17 +0000

On 5 January 2015 at 15:42, Stephen Kent <[email-masked]> wrote:

> Ben,
>
> Happy New year!
>
>  ...
>> Because of the risk of logs becoming untrusted, SCTs in certificates
>> may become invalid before the certificate expires, effectively
>> terminating the cert early.
>>
> If a log becomes untrusted then the cert is "invalid" only for the
> set of clients who relied upon that log. It may be that the cert was
> fine and the log was misbehaving with respect to other certs. So
> the term "invalid" is not quite appropriate here, in the usual PKI sense.
>
>> You can mitigate this to some extent by including many SCTs, but its
>> clearly better/safer to use SCTs that are retrieved "live" so that you
>> can always be sure they're valid.
>>
> I agree that this would be preferable.
>
>> This requires either OCSP stapling or the TLS extension. Using the TLS
>> extension puts updating the SCTs in the control of the site operator,
>> which seems like the best way forward.
>>
> Maybe. I've been told that site operators are not always very reliable
> when it comes to maintenance issues. Also, I believe you argued that it
> was critical to put SCTs in certs because it would take a very long time
> for site operators to update their software to trans,it SCTs. So, is your
> argument that, over time, the vast majority of site operators will
> go to the effort of getting an SCT for their web certs and transmit it
> instead of just using the SCT that is already embedded in the same certs?
>

My argument is that over time servers will deal with SCTs automatically and
CAs will stop including SCTs (at least optionally) as a result.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2015 15:37:04 -0500

Ben,

> about the size of handshakes).
That concern varies a lot, depending on context. I don't agree that this 
is a universal, major
concern. Look at JSON; it's use of XML encoding suggests no concern 
about bloat in a web context.
>
> 2. Embedding SCTs in certs leads to more bloat than either OCSP 
> stapling or the TLS extension because the SCTs cannot be updated, and 
> so more are required (see Chrome's EV/CT policy).
I am not familiar with Chrome's EV/CT policy, and I think you argued 
that what Google has chosen to
do is out of scope, in the context of a prior argument in TRANS. Anyway, 
absent a spec for TLS client
behavior, one cannot discuss the need to update SCTs, right?
> 3. Embedding SCTs in certs runs the risk that the SCTs will become 
> invalid before the cert does.
until we have a precise description of how a client will deal with an 
invalid SCT, we can't
really evaluate the implications of this potential mismatch. Also, what 
causes an SCT to become
invalid?.
> 4. Certs are not generally updated before expiry.
agreed.
> 5. Stapled OCSP requires the CA, the webserver and the CT logs to be 
agreed. which gets back to my question from several months ago as to why 
we have 3 ways
of signalling SCT info.
> 6. The TLS extension only requires the webserver and the CT logs to be 
agreed, if the web serer operator submits the cert to the log.
> 7. All three mechanisms can be made essentially automatic from the 
This point, in conjunction with #5, sounds like you're trying to have it 
both ways :-).

Lots of things can be made automatic, with the right support software. 
In the IETF
we often try (though we do not always succeed) to limit the number of 
mandatory to
support ways to do the same thing. That's why I questioned the 
specification of OCSP
delivery of SCT data, plus pre-certs plus TLS handshake delivery.
> So, I would expect in the long run that the TLS extension would be the 
Maybe. But, as I noted, if CAs have already gone to the trouble of 
embedding SCT data in
certs, and if this is free for web site operators, there seems to be 
more inertia than
motivation to change, from the perspective of operators.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2015 15:37:17 -0500

Ben,
> My argument is that over time servers will deal with SCTs 
> automatically and CAs will stop including SCTs (at least optionally) 
> as a result.
I understand your assertion, but I don't feel that you have made a 
strong case for why this
specific path will become the norm.

---

From: Matt Palmer <[email-masked]>
Date: Fri, 27 Feb 2015 09:02:50 +1100

On Thu, Feb 26, 2015 at 03:37:17PM -0500, Stephen Kent wrote:
> Ben,
>
> >My argument is that over time servers will deal with SCTs automatically
> >and CAs will stop including SCTs (at least optionally) as a result.
>
> I understand your assertion, but I don't feel that you have made a strong
> case for why this specific path will become the norm.

Because it is operationally more flexible than embedding SCTs in the
certificate (rotating SCTs if logs cease operation or become untrusted), and
hence can make the TLS handshake smaller (only need to transmit the one SCT
that is trusted, rather than N SCTs in the certificate).

- Matt

---

From: Matt Palmer <[email-masked]>
Date: Fri, 27 Feb 2015 09:16:28 +1100

> is a universal, major concern.  Look at JSON; it's use of XML encoding
> suggests no concern about bloat in a web context.

This isn't a *web* context, though; it's a TLS session establishment
context.  Bloating the handshake so as to require an additional round trip
increases session establishment time, which degrades user experience --
something which is generally considered a bad thing.

> invalid SCT, we can't really evaluate the implications of this potential
> mismatch.  Also, what causes an SCT to become invalid?.

An SCT becomes invalid when the log which issued it ceases to be trusted by
the browser.

- Matt

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Feb 2015 16:16:43 -0500

Matt,

> something which is generally considered a bad thing.
The charter for the WG says:
"The working group will produce a standards-track version of the 
experimental RFC 6962
*for HTTP over TLS*, ..." so I think it's appropriate to discuss this in 
the web context.

> An SCT becomes invalid when the log which issued it ceases to be trusted by
Thanks for that clarification. But, since there is no spec for client 
behavior,
the notion of a browser no longer trusting a log is undefined at this 
time. Also,
there is no description of how a web site operator will learn that some 
non-trivial set
of clients no longer trust  a given log, and thus the operator will be 
motivated to
acquire a new SCT for his cert from another log. Finally, the text above 
refers to a
cert becoming "invalid." Does this mean the cert is revoked, or does 
this refer to a
cert expiring? if the latter is intended, then it is preferable to use 
the correct term.

Steve