Re: [TLS] Comment on draft-thomson-tls-sic-00

[Jonathan Hoyland <[e-mail]>]

Hi Martin,

Could you comment on how the client and server know they agree on the
certificate chain?
Would it be possible for the client and server to resolve the certificate
chain down two distinct paths, for example in the case of cross signed
certificates?

If so, is there a security risk here, as in, does it matter if the client
and server disagree on the chains?
Could an attacker perform some shenanigans with disjoint roots of trust, or
by finding paths with differing policy constraints (if that even makes
sense)?

Would it help anything if the server included a digest of the certificate
chain in its EncryptedExtensions?

Regards,

Jonathan

On Thu, 11 Apr 2019 at 03:58, Martin Thomson <[e-mail]> wrote:

> On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote:
> > And one more....
> >
> > "The 0xTBD flag can only be send in a ClientHello or CertificateRequest
> > message.  Endpoints that receive a value of 1 in any other handshake
> > message MUST generate a fatal illegal_parameter alert."
> >
> > This goes against draft-nir-tls-tlsflags
> >
> > "A server that supports this extension and also supports at least one
> > of the flag-type features that use this extension and that were
> > declared by the ClientHello extension SHALL send this extension with
> > the intersection of the flags it supports with the flags declared by
> > the client."
> >
> > I assume the sic sic extension should be sent in EncryptedExtensions.
>
> I think that this is a problem in draft-nir-tls-tlsflags.  Extensions in
> ClientHello are "answered" in two places: EncryptedExtensions and
> Certificate.  The requirement that the flag be echoed creates a problem in
> that context.
>
> We could define separate "Handshake flags" and "Certificate flags", but
> that complicates things.
>
> If you look at extension usage, you see that not all "flags" are echoed.
> In this case, a requirement to echo would just increase the size of
> Certificate for no good reason - the extension can be omitted completely.
>
> We should only require the presence of the flag where it carries
> semantics.  The requirement should be stated as
>
>    Implementations MUST NOT set flags in extension responses if the remote
>    endpoint did not send the corresponding flag in extension requests.
> Upon
>    receiving a flag that is incorrectly set, an endpoint MUST abort the
> handshake
>    with an "unsupported_extension" [?] alert.
>
> Mirroring the language from RFC 8446.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>