Re: [Trans] [TLS] ct_compliant cached info field

[Rob Stradling <[e-mail]>]

EKR, Martin,

Hi, and sorry for the long delay in replying.

This originated in [1] and was added to 6962-bis in [2].  The motivation 
was to provide a mechanism to permit a TLS server to avoid sending CT 
artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client 
already has or doesn't need, thereby reducing bytes on the wire for 
constrained and high-volume environments.

The approach envisaged by RFC7924 seems to be: "here's a list of TLS 
message fingerprints I've received previously; please don't send these 
exact messages to me again".  This works for stand-alone messages that 
contain one item, such as the server's Certificate message (which 
contains 1 server certificate chain).

However, in 6962-bis's case, SCTs and inclusion proofs are not 
stand-alone items; instead, they correspond to particular certificates. 
Each relevant TLS message will contain a TransItemList, which will 
probably contain at least a set of several SCTs; and whilst each SCT is 
static, the set (and the order within the set) is not.  Therefore, the 
approach of caching TLS messages by fingerprint didn't look like it 
would work for us.

We concluded that it would make more sense for the client to make a more 
high-level statement: "here's a list of certificate fingerprints that 
I've received previously and that I already regard as being CT-compliant".

This isn't an essential part of 6962-bis.  Other than Ben L's "Sounds 
like a good idea" comment in [1], I don't recall anyone commenting on it 
until EKR started this thread.

I propose to remove this cached-info mechanism from 6962-bis, if nobody 
objects.  (It could of course be revisited in some future document, if 
there's interest).


[1] https://trac.ietf.org/trac/trans/ticket/111

[2] https://github.com/google/certificate-transparency-rfcs/pull/186

On 31/12/2018 14:36, Eric Rescorla wrote:
> + trans
> 
> On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> 
>     On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote:
>      > Please take a look at
>      >
>     https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
> 
>     At a minimum, this would seem to update cached_info.
> 
>     There's not a lot of meat on this text.  It seems to be saying that
>     if you are providing transparency_info, then you can provide a
>     certificate other than any of the certificates that the client
>     believes to be CT compliant.  Also, you don't provide "x509_sct_v2"
>     or "precert_sct_v2" in transparency_info.
> 
>     How is the client then able to determine that this new certificate
>     is CT compliant?  Using  "inclusion_proof_v2" and
>     "signed_tree_head_v2" (or one or other)?  If so, the text doesn't
>     point in that direction.
> 
>     There's a lot of "why" missing in this document.  Why would a client
>     choose to indicate "ct_compliant"?  Why is cached_info being
>     extended in this way?
> 
>     I might guess that the reason here is that the draft aims to avoid
>     including information that might change over time, which would
>     render caches invalid.  Isn't that motivation to recommend an SCT
>     over an STH?
> 
>     Separately, why does this establish a new registry for signature
>     schemes?  It is obviously trying to keep TLS compatibility, based on
>     the codepoints, but forking the registry is a great way to create
>     problems.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [e-mail]