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

[Eric Rescorla <[e-mail]>]

That works for me

-Ekr


On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <[e-mail]> wrote:

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