RE: [TLS] Record layer corner cases

["Kemp, David P." <DPKemp at missi.ncsc.mil>]

There is fortunately a difference between errors that are security
land mines waiting to explode, and differences in interpretation
that do not lead to security errors.

Assume that the world view and behavior described in X.509 and
RFC 3280 (root certs map to TAs) is called Type A, and the behavior
you describe (root certs both map to TAs and are evaluated during
path validation) is called Type B.  Assume that there is a mix
of Type A and Type B sender and receiver implementations on the
Internet.  Assume that a CA (call it GloboSign, with apologies
to the movie Dodgeball) chooses to publish two root certificates
for its single root signing key, one expiring in 1900 (RootA)
and the other expiring in 2050 (RootB) in order to cater to
both types of customers.

Type A senders include RootA, CA, EE in their paths.
Type B senders include RootB, CA, EE in their paths.
Type A receivers validate TA -> CA -> EE.
Type B receivers validate TA -> Root(x) -> CA -> EE.

I contend that the Type B receivers are impacting both their
own performance (by checking 50% more signatures than necessary)
and their own interoperability (by unnecessarily rejecting
connections from Type A senders) without gaining an ounce
of security.  If there is an undetected compromise of
GloboSign's root key, then validating the RootB certificate
will not prevent a rogue CA from being validated.  If
the compromise is detected and receivers of both types
change their GloboSign TA keys, then CA certs signed with
the compromised root key will be rejected regardless of whether
the root cert is validated.

Simplicity is one form of security goodness.  A web site
that chooses to purchase a Type A web server will gain
1) standards compliance with X.509 and PKIX, 2) performance
(by eliminating unnecessary cert validations), and
3) interoperability with both Type A and Type B browsers.
A web site that purchases a Type B server loses performance
and interoperability with Type A browsers (when doing
client auth) and gains nothing in security.

I too dislike ambiguity in specifications.  The text
in RFC 3280 is unambiguous about what constitutes TA
information (and you do not disagree with that definition).
And according to you, the TLS spec calls for the same
decision that a Type A receiver would render, without
specifying an algorithm for reaching that decision:

> TLSv1 improved the situation, indicating that the
> path may or may not contain a rootCA (=self-signed)
> cert, and mentioned that such a cert, if present,
> should not have an impact on the decision whether
> the peer's certificate is trusted.

It would appear that the PKIX and TLS standards are
unambiguous and in agreement with each other in specifying
Type A behavior, and that horses that refuse to drink
when led to water are hurting only themselves.

Dave

P.S.  If you can come up with an example combination of
circumstances where Type B behavior would have a
security advantage over Type A, I'd listen.  But vague
references to not checking errors and land mines are
not persuasive.  The ASN.1 reconstruction example
you cite is an argument in favor of Type A.
The only case I can think of is a Type A sender
(expired root cert) with a Type B receiver (root
cert checked) and an undetected root key compromise
(TA not replaced, rogue CA cert signed by adversary).
In that case a Type B receiver stumbles onto the
right decision, but since Type B always rejects
Type A connections regardless of whether the root
is compromised, that's like saying a stopped perpetual
clock/calendar is right once a millennium.


--------------------
From: Martin Rex [mailto:martin.rex at sap.com] 

Personally, I dislike text in a specification that will result
in different, non-interoperable behaviour.  It would be much
better if all implementations did the same kind of tests so
that interoperability tests become meaningful.

In general, security software an protocols should be designed
so that they reliably fail if something is incorrect.  Every
attempt to ignore errors is a security problem waiting to happen,
just like planting land-mines -- and should be banned.

-Martin

--------------------
From: pgut001 [mailto:pgut001 at cs.auckland.ac.nz] 

At the time this first appeared (in X.509v4 drafts) I did an informal
survey
of PKI implementors, and exactly *zero* implementors were aware of this
sudden
change retroactively hacked onto X.509's behaviour.  It may be in the
spec
now, but how many existing implementations do you think will handle this
as
required?  To handle this complete reversal of root cert handling you'd
have
to more or less tear down everything built in the last 10-15 years and
start
again.  I wonder what the chances of that happening are?

Peter.

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls