Yes, digesting the chain is likely to fail. The set of "intermediates" that are included are not a strictly deterministic set. Counter-signing of trust anchors and other such practices mean that the client and server wouldn't be able to agree to the point that a digest would be reliable.
There are two things that you might want agreement on here, if you want agreement about anything. 1. Agreement on what was put into the handshake messages, or the contents of a Certificate message. 2. Agreement on what the certification path is. If the server omits intermediates, then we still get agreement on the content of the message, but whether we agree on the identity of the intermediate that the client ultimately uses is what you are concerned with. However, if we look at the second, we already lack TLS transcript protection for the full certification path because trust anchors are in practice (and by recommendation) omitted from the Certificate message anyway. This proposal just moves that one step further down the chain. So your question is more of a general question with TLS. If we don't include certain elements of the certification path in the handshake transcript, how do we know that the client and server agree on how the server identity was validated? The current answer, which might not seem satisfactory, is that there is no agreement or understanding. The various ways in which certification paths are recovered (see AIA chasing, missing intermediates) and then constructed is something of a mystery. In practice, people shove certificates into Certificate until the clients they care about accept the chain. And I would contend that agreeing on how authentication is performed is not entirely necessary[1]. The decision about whether a peer identity is valid is made by each participant independently. The information in Certificate is input to that process, but not the only input. We might also have other things, like pinned keys or CT policies, that also read on that decision. --Martin [1] We do, as much as possible, try to even this out, but the fact is that there are a number of subtle differences in client requirements. On Mon, Apr 15, 2019, at 19:09, Jonathan Hoyland wrote: > 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 <m...@lowentropy.net> 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
