Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)

[Peter Saint-Andre <[e-mail]>]

On 10/5/10 11:47 AM, Martin Rex wrote:
> Jim Schaad wrote:
>>
>> Martin Rex wrote: 
>>>
>>>  (2) support for server certs that do not succeed certificate
>>>      path validation to one of the (pre-)configured trust anchors
>>
>> This is from the abstract of the document in question:
>>
>> "This document specifies best current practices for
>>    representing and verifying the identity of application services in
>>    such interactions."
>>
>> As you see the document is about how to do name comparisons.  If you believe
>> a document on trust , path validation and pinning are needed I would
>> strongly suggest that you write such a draft.
> 
> Thanks! I was asking for removal of the reference to path validation from
> that one paragraph:
> 
> PeterSA wrote:
>>
>>                                    then the client MUST verify that
>>    the presented certificate is the same as the cached certificate,
>>    including verification of the entire certification path.
> 
> So the "including verification of the entire certification path"
> should be completely removed, 

I'd be curious to see what Jim's feedback is on that point, since he
suggested the inclusion of text about the certification path.

> and the "cached certificate"
> ought to be clarified to mean memorized "CERT-ID" reference identifier
> to make it clearly distinct from anything related to TLS session caching.

1. How about changing "cached certificate" to "stored certificate" or
"memorized certificate"? I agree that the term "caching" might be
confusing to some folks.

2. Are you suggesting that we change "cached certificate" to "stored
reference identifier"? That doesn't strike me as a helpful change
because it doesn't make clear that the client needs to keep track of
more than just the reference identifier, it needs to store an
association between the verified reference identifier (im.example.com or
whatever) and the certificate that was presented by the server it
connected to for that DNS domain name (or, at the very least, a hash of
the certificate).

> Jim Schaad wrote:
>>
>> Martin Rex wrote:
>>>
>>>  (1) lack of rationale why the cert chain should be cached
>>>      rather than only the server certificate
>>>
>>> I think that (1) is seriously underspecified.  With the existing matching
>>> procedure, caching the entire cert chain does NOT make any sense at all
>>> (and does not provide security benefit).
>>
>> I look upon section 4.6.2 (and follows) to be analogous to the user adding
>> an additional SAN to a certificate that states that one or more of the
>> reference identifiers is being bound to a certificate.  As an advanced user,
>> I may still wish some correct path validation to occur.
>>
>> Example  [...]
> 
> 
> Given your example, which admittedly I have difficulty understanding,
> I firmly believe the use of the term "cached server cert (chain)"
> is throroughly underspecified in server-id-check and should be
> fixed and all existing references to "certificate path validation"
> should be removed.
> 
> The concept of "caching" implies to shortcut or skip operations and
> rely on previous results of the same operation (e.g. network round-trips,
> network bandwidth, computational overhead like PK-crypto-operations
> or other resource-intensive operations such as OCSP-requests or
> CRL-downloads&checking).
> 
> The TLS protocol contains a feature called "TLS session caching",
> and when used, it normally "saves" not only the PK-crypto-operations
> for the TLS key exchange (which may be a single PK-crypto operation
> for each peer for RSA ciphersuites), but also the entire certificate path
> validation (which usually involves several PK-crypto-operations plus
> OCSP-requests and CRL-downloads with third parties).
> 
> As specified in all existing TLS protocol specs, last sentence of
> section 1, the interpretation of peer certificates is entirely up
> to the calling application on top of TLS.  It is also completely
> up to the application to decide whether to abort a TLS handshake
> when PKIX certificate path validation can not be performed for
> the peer certificate due to a lack of trust.
> 
> server-id-check is an operation that is performed after
> the TLS handshake has completed, and the peer certificate
> can be obtained from the TLS stack, independent of whether
> the TLS session was resumed from the cache (and certificate
> path validation skipped) or a full TLS handshake was perfomed.
> 
> "Pinning" of the server certificate means, that server-id-check
> is substituted with a comparison of the server's end-entity cert,
> like a "CERT-ID" reference identifier.  The "pinned" server cert
> must be memorized by the application "somewhere", along with the
> meta-information for which hostname / reference-identifier the
> pinning applies and whether PKIX cert validation succeeded
> on this certificate.  There is no security problem with allowing
> CERT-ID matching for certificate chains for which no certificate
> path validation can be performed due to a lack of trust.
> 
> This is what this paragraph of rfc-2818 is about:
> 
>    If the client has external information as to the expected identity of
>    the server, the hostname check MAY be omitted. (For instance, a
>    client may be connecting to a machine whose address and hostname are
>    dynamic but the client knows the certificate that the server will
>    present.) 
> 
> A users decision to "pin" a server cert may involve consideration
> of chain certificates in case that PKIX certificate path validation
> succeeded.  But memorizing anything besides the server cert will *NOT*
> provide any security benefit for future automated server endpoint
> identifications and is unnecessary.

Aha, I see your point now. Thanks for explaining it in more detail.

> If the server-id-check document wants to define a CERT-ID reference
> identifier and use the term "caching", is should use it in a fashion
> that there is no confusion with the TLS session caching and that
> the PKIX certificate path validation usually performed by TLS
> on behalf of the calling app (but only during full TLS handshakes)
> is independent from application-level server-id-check, independent
> of whether DNS-ID, URL-ID, SRV-ID, CN-ID or CERT-ID is used.
> 
> One should be very careful about the use of the term "caching"
> in server-id-check so that there is no confusion with anything
> from the TLS session caching. 

Yes, point taken.

> For server-id-check "caching" applies
> only to the decision to use the server end-entity cert as the
> reference identifier ("CERT-ID") for a specific target, 

In the terms of this I-D, a certificate is not a reference identifier.
The reference identifier is still a DNS-ID or whatever, it's just that
after pinning the client considers it acceptable to use as a reference
identifier a DNS domain name that was presented in the server's
certificate during a previous connection attempt and explicitly accepted
by a human user (as long as the memorized certificate doesn't change in
future connection attempts etc.).

> instead
> of deriving reference identifiers such as DNS-ID, URL-ID or CN-ID
> from the target's hostname that was used to establish the
> communication channel.  This decision could be a result of
> user-interaction or result of a configuration to that effect.

Correct.

> Btw. I would be extremely careful about visualizing chain certificates
> to Joe Average user for a chain that failed certificate path validation
> because it is quite undefined how many checks were really skipped.
> You do NOT want to have Joe Average user perform an eyeball comparison
> on the cert or public key fingerprint on the top-level cert at the
> end of a cert chain for which certificate path validation failed
> and let him assume this makes it a successfull path validation.

Yes, applications need to be extremely careful about presenting anything
to Joe Average or Barry's Mother or other unsophisticated individuals.

> Given how certificate path validation is specified by PKIX
> (rfc-5280, section 6), working from the trust anchor downwards,
> no signature checks, no constraints checks and not revocation
> checks are performed on an untrusted chain.

Noted.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/