Subject: [TLS] Record layer corner cases

From: <[email-masked]>
Date: Tue, 21 Nov 2006 18:06:27 +0200

Hi all,

In San Diego I gave a short presentation on how various TLS
implementations handle some corner cases in the TLS record protocol:

http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt

The conclusion was that receiving these corner cases is not handled
well, probably because real implementations never send them.
Thus, I'd suggest explicitly forbidding some of these corner
cases in TLS 1.2. In particular:

- Implementations MUST NOT fragment Handshake, Alert, or Change
  cipher spec messages to multiple TLS records unless the message 
  exceeds the maximum fragment length (either 2^14 or negotiated 
  with max_fragment_length extension).

- Implementations MUST NOT send zero-length fragments of Handshake, 
  Alert, or Change Cipher Spec content types (zero-length fragments
  of Application data would still be allowed; presumably they might
  be useful against traffic analysis).

- Implementations MUST NOT send content types not defined in this
  document except when explicitly negotiated using e.g. a TLS
  extension (current text says unknown content types SHOULD
  be just ignored).

- The maximum fragment size is a strict limit (i.e. change
  "the length should not exceed 2^14" to MUST NOT).

Comments?

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Nov 2006 18:33:46 +0100

>   "the length should not exceed 2^14" to MUST NOT).

It seems to me that to avoid these problematic cases, "SHOULD NOT send
but MUST accept" is better than "MUST NOT send".

Can you describe the specific fragmentation strategies that you used
for testing?  I'd expect fragmentation to probably go wrong if it
affects the very beginning of the TLS connection, when the server
still has to decide which protocol version to use.  (Support for the
SSL 2.0 client hello format possibly makes this more complicated than
it otherwise would have to be.)  If the very first handshake fragment
sent by the client contains at least six bytes to accommodate the
handshake message type (one byte), the message length (three bytes),
and the protocol version (two bytes), then things are much easier for
the server.  It's not fragmentation per se that should be a problem
for most implementations, just pathologically small fragmentation;
or so I hope.

For the first of the proposed restrictions (i.e., don't fragment
unless the message exceeds the maximum fragment length), I think that
even SHOULD NOT is too much:

- First, consider implementations that collect multiple handshake
  messages before sending these in TLS records.  The *total* length of
  these messages may exceed the maximum fragment length even if each
  *single* message is below the limit, and in this case we naturally
  would have a record boundary that is not aligned with the message
  boundary.

- Second, consider implementations designed to run with very little
  memory.  These might be allowing large fragments when receiving
  data (since they can't rely on the max_fragment_length extension
  being universally available) but still be using smaller fragments
  when sending data.

Bodo

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Nov 2006 16:56:03 +1300

>Comments?

Sounds good.  One additional comment, this is also a security issue, the more
weird bits and pieces you have to handle, the greater the chance for mis-
handling some of them, and also the greater the chance of an attacker being
able to manipulate things to get around security checks.  Look at TCP
fragmentation as an example, in particular IPv6 fragmentation, which has lead
to unfixable (without changing the spec) security holes.

Peter.

---

From: Rob Dugal <[email-masked]>
Date: Wed, 22 Nov 2006 07:08:10 -0500

>   being universally available) but still be using smaller fragments

I agree with Bodo. Our SSL product supports both of these options. 
They are usefull features I would hate to disable for TLS 1.2

---

From: <[email-masked]>
Date: Wed, 22 Nov 2006 14:53:33 +0200

Bodo Moeller wrote:

> It seems to me that to avoid these problematic cases, "SHOULD NOT
> send but MUST accept" is better than "MUST NOT send".

This is very problematic for interoperability. If practically all
implementations follow the "SHOULD NOT send" (which they seem to do
today), the part about "MUST accept" never gets tested.  This means
that even future implementations (at least those which care about 
good interoperability) cannot violate the SHOULD NOT.

And this is IMHO roughly where we are today... the spec has a feature
which nobody uses, and nobody can use. IMHO it would be better to
remove it, rather than leave it there "just in case".

> for testing?  

I fragmented every handshake message (sent by the client) to two 
fragments (split in the middle).

> I'd expect fragmentation to probably go wrong if it affects the very
> beginning of the TLS connection, when the server still has to decide
> which protocol version to use.  (Support for the SSL 2.0 client
> hello format possibly makes this more complicated than it otherwise
> would have to be.)

Well, SSL 2.0 client hello can be distinguished from SSLv3/TLS hello
by looking at the first byte...

> If the very first handshake fragment sent by the client contains at
> least six bytes to accommodate the handshake message type (one
> byte), the message length (three bytes), and the protocol version
> (two bytes), then things are much easier for the server.  It's not
> fragmentation per se that should be a problem for most
> implementations, just pathologically small fragmentation; or so I
> hope.

The tests I did seemed to suggest that _any_ fragmentation, not 
just pathologically small, is a problem for most implementations.
 
> unless the message exceeds the maximum fragment length), I think 
> that even SHOULD NOT is too much:
> 

The restriction would apply only to TLS 1.2, and there aren't any 
TLS 1.2 implementations yet... so we could even require that a single
fragment can't contain multiple handshake messages.
 
>   being universally available) but still be using smaller fragments

Hmm... this is a valid argument, at least when the fragments are being
encrypted/MAC'd. What if the restriction (about not fragmenting unless
needed) only applied when current ciphersuite is NULL_WITH_NULL?

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Wed, 22 Nov 2006 09:53:52 -0800

> fragment can't contain multiple handshake messages.

I think this would be taking it too far (consider sending
ServerHelloDone in its own packet).  Plus if you implement
TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3
which don't have the restriction.

Mike

---

From: <[email-masked]>
Date: Thu, 23 Nov 2006 11:37:38 +0200

> which don't have the restriction.

A separate record doesn't mean its own IP packet (or TCP segment);
it's just 5 bytes of record header overhead (in case of
NULL_WITH_NULL). But yes, maybe it would still be taking it too far...
 
(But TLS 1.2 spec doesn't require you to implement any older spec; and
even the older specs in reality seem to have the restriction that you
can't fragment handshake messages if you want good interoperability.)

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Thu, 23 Nov 2006 16:43:01 -0800

I clearly misunderstood what you meant, and actually agree that it
would be good to have one handshake message per record.  Practically,
though, you will need to support earlier versions for some time.
Just try to connect to the industry-leading certificate authority
with TLS 1.0: https://www.verisign.com/ for example.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Nov 2006 02:01:09 +0100 (MET)

> with TLS 1.0: https://www.verisign.com/ for example.

Talking of VeriSign...

A few years ago, www.verisign.com had been sending out an expired
rootCA certificate in the certification path of the Server, and
curiously, none of the Web Browsers complained when it had a
replacement cert (same Subject&Issuer, same key, longer validity)
in the list of trust anchors.  If the newer local key was
deleted in the browsers list of trust anchors, then the expired
rootCA cert sent by www.verisign.com became visible.

Maybe there should be some guidance, common sense doesn't seem
to be sufficient (it took VeriSign several months to fix it when
I complained to them about their server misconfiguration/misbehaviour).

-Martin

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 24 Nov 2006 17:07:00 +1300

Martin Rex <[email-masked]> writes:

>A few years ago, www.verisign.com had been sending out an expired rootCA
>certificate in the certification path of the Server, 

31 December 1999 (a built-in Y2K failure, all their roots expired on that
day).

>and curiously, none of the Web Browsers complained when it had a replacement
>cert (same Subject&Issuer, same key, longer validity) in the list of trust
>anchors.

They just checked the DN and key and left it at that, since only the date had
changed the new cert was silently accepted.

>Maybe there should be some guidance, common sense doesn't seem to be
>sufficient (it took VeriSign several months to fix it when I complained to
>them about their server misconfiguration/misbehaviour).

For root certs, the practice is to have them never expire [0].  You'll never
see this written down anywhere (you're supposed to roll over certs every few
years), but I think in practice everyone in the industry knows that root cert
replacement is so unworkable that you just give your certs an infinite
lifetime.  When it comes to security vs.availability, availability always wins
out.

Peter.

[0] I've had users complain to me that my use of time_t prevents them from
    setting lifetimes of more than 35-odd years for their root certs, and 
    would I consider moving to long long's instead.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 24 Nov 2006 17:49:51 +0100

> remove it, rather than leave it there "just in case".

Well, for certificate chains that are "long" (compared to the maximum
fragment length, or to some device's more limited maximum length for
sending fragments), fragmentation is a feature that will be used.

The minimum maximum fragment length (sic) is 2^9, so I suppose it
would be reasonable to state that fragments of "handshake", "alert",
and "change_cipher_spec" content type can't be empty and can't be
smaller than 512 bytes unless they end where a message of the
respective protocol ends.  This does not rule out fragmentation within
a message, but avoids pathological cases.

> fragments (split in the middle).

I was asking because your observations do not agree with my earlier
testing, which I repeated now: As far as I can determine, provided
that the ClientHello and ServerHello messages are not pathologically
fragmented, OpenSSL should not have problems with weird fragmentation.
For my tests, except for Hello message fragmentation, I've used
length-1 fragments and included the occasional length-0 fragment.  So
I'm not sure why you experienced problems with split-in-the-middle
fragmentation unless you used some ancient software version.  It seems
possible that the implementation that you used for testing could be
buggy, and that TLS servers don't really handle fragmentation as
poorly as your observations indicate.

> by looking at the first byte...

Sure.  However, things are more complicated if you have a mechanism
intended to decide the protocol version among SSL 2.0, SSL 3.0, TLS
1.0, TLS 1.1, etc.  Without SSL 2.0 and without the SSL 2.0 client
hello format, it would be easier because you could do the record
handling outside the version-specific stuff.  If you need to
accomodate SSL 2.0 as well, then the record handling becomes version
specific, and thus it may require additional effort if you need to
join fragments before the protocol version has actually been chosen.

> fragment can't contain multiple handshake messages.

It's still extra implementation work for implementations that don't
happen to follow the potential new requirement.  (At least they won't
have to distinguish between protocol versions for this because the
proposed behavior certainly is valid for SSL 3.0, and TLS 1.0 and
TLS 1.1 as well.)

Now that I come to think of it, if we want to change the words of
the specification for TLS 1.2, we might just as well simply take the
current description of fragmentation and add "And we mean it" ... :-)

Seriously, if we rule out some odd cases of fragmentation, I don't
think it is unreasonable to require all implementations to be able to
properly process fragmented handshake messages.

> needed) only applied when current ciphersuite is NULL_WITH_NULL?

My initial thought on this is that different rules for NULL_WITH_NULL
and for other ciphersuites are an unnecessary complication.  Also it
probably would mean that the recipient-side handling of fragmentation
wouldn't get tested as much as it otherwise could.

Bodo

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 27 Nov 2006 10:45:14 -0500

There is no misbehavior involved at all, and no reason to
complain to VeriSign about any dates contained in a rootCA
certificate.  In fact, VeriSign could have made the nature
of trust anchor information more explicitly obvious if they
had stuck in a validity period of Jan 1, 1900 0000Z -
Jan 1, 1900 0000Z.  Including nonsense in the certificate
fields that are not part of a trust anchor makes it obvious
that the certificate is just a data structure that is being
re- (or mis-)used to convey trust anchor information.

RFC 3280 (and draft 3280bis-05) clearly specify that trust
anchors are maintained out of band, and that trust anchor
information does not include a validity period any other
certificate fields except the four listed:

-----------------------------------------------------------------

      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path
      processing procedure in the form of a self-signed certificate.
      When the trust anchor information is provided in the form of a
      certificate, the name in the subject field is used as the trusted
      issuer name and the contents of the subjectPublicKeyInfo field is
      used as the source of the trusted public key algorithm and the
      trusted public key.  The trust anchor information is trusted
      because it was delivered to the path processing procedure by some
      trustworthy out-of-band procedure.

------------------------------------------------------------------

A root CA certificate transmitted in a TLS handshake is neither a
trust anchor nor a component of the path to be validated.  It is merely
a hint to the relying party as to which trust anchor to use for path
validation in case the relying party has installed more than one
trust anchor key with the same issuer name.  If every trust anchor key
has a unique issuer name, sending root CA certificates in handshakes
is a pure waste of bandwidth without even the benefit of
minimizing trial signature verifications.

Dave

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Thursday, November 23, 2006 11:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Record layer corner cases

>A few years ago, www.verisign.com had been sending out an expired
rootCA
>cert (same Subject&Issuer, same key, longer validity) in the list of
trust

They just checked the DN and key and left it at that, since only
the date had changed the new cert was silently accepted.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 27 Nov 2006 10:45:14 -0500

Dave

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Thursday, November 23, 2006 11:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Record layer corner cases

rootCA

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Nov 2006 18:12:09 +0100 (MET)

> re- (or mis-)used to convey trust anchor information.

I do not mind about not checking validity dates (or even signatures)
on trust anchors.  But when an X.509 certficates is sent as part of
a certification path, then it is not a trust anchor, but instead
a regular certificate -- and therefore MUST be a correct certificate
(or not be sent in a certification path!).

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 27 Nov 2006 13:04:42 -0500

The objective of path validation is to ensure that a valid path
exists from an end entity certificate back to a trust anchor.
If a self-issued certificate is transmitted as part of a path
and its name and key are also used as a trust anchor, then there
are many paths that will satisfy signature/name chaining:

1) TA -> CA Cert -> EE Cert
2) TA -> Root Cert -> CA Cert -> EE Cert
3) TA -> Root Cert -> Root Cert -> CA Cert -> EE Cert
4) TA -> Root Cert -> Root Cert -> Root Cert -> CA Cert -> EE
5) ...

If the root cert has a bad validity, then path 2) will not
validate.  However, in order to authenticate the end entity,
it is sufficient that path 1) validates.  The fact that there
are any number of invalid paths from EE to TA does not negate the
fact that there is at least one valid path.

Unlike S/MIME, the TLS spec requires transmission of a
complete cert chain from EE to TA.  However, if TLS requires
that a transmitted root cert be used as a component
of a path as in 2), not just a TA hint as in 1), then the
TLS spec is broken.  I don't believe that's the case:
SSL or TLS do not require that a transmitted self-issued
cert be used as both a TA hint *and* a path component.

Dave

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, November 27, 2006 12:12 PM
To: Kemp, David P.
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TLS] Record layer corner cases

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Nov 2006 20:47:20 +0100 (MET)

SSLv3 didn't say whether the certification path includes a rootCA
(=self-signed) cert or not, i.e. the spec was ambiguous.

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.

> fact that there is at least one valid path.

I don't know whether the PKI fanciers have specified this anywhere,
but I would consider it seriously braindead if there was such a
path validation algorithm.

If a path can be built, it must verify.  If a path can not be built,
it can not be verified and must be ignored.

Requiring the receiver to weed our garbage sent by the peer is
asking for (interoperability) troubles, and a serious waste of
every receives resources (especially for busy servers).

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 27 Nov 2006 16:14:47 -0500

We are not discussing weeding out garbage sent by a
peer, we are discussing a peer that sends (hypothetically)
exactly three certs: root, CA, and EE.

The sensible thing to do in such a circumstance is to
map the root certificate to a trust anchor:

   1) TA -> CA -> EE

And in fact, you indicated that that is exactly the
observed behavior:

> A few years ago, www.verisign.com had been sending
> out an expired rootCA certificate in the certification
> path of the Server, and curiously, none of the Web Browsers
> complained when it had a replacement cert (same
> Subject&Issuer, same key, longer validity) in the list
> of trust anchors.

This discussion is about why the observed behavior is correct.

You argue that a TLS receiver should go out of its way to
build a second, longer path that contains the root certificate:

   2) TA -> Root -> CA -> EE

just so it could reject that path, but that is not how either
PKI fanciers or TLS implementers intend root certificates
to be used.  Root certs are *not* part of a certification
path, they are convenient containers for conveying trust
anchor information, and everything else in them (including
signature and validity) can (and should, to minimize load
on busy servers) be safely ignored during path validation.

Dave

--------------------------------------------------
Martin Rex <[email-masked]> writes:

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Nov 2006 23:39:12 +0100 (MET)

> exactly three certs: root, CA, and EE.

I disagree.  This is about weeding out garbage.

>    2) TA -> Root -> CA -> EE

Correct.  SSLv3 (and probably TLS as well) supports only a straight
forward certification path, and if the local trust anchor happens
to be the rootCA cert, then I think it is correct to check that
rootCA cert during path validation in case the peer sends it.

>From my experience, Browsers do NOT entirely ignore a rootCA cert
sent in the SSL-Server's forward certification chain.

On a different occasion we ran into a problem with SSL server certs
issued from the GlobalSign RootCA when installed on our AppServer.

Web Browsers complained about an invalid certificate (not matching
the trust anchor) when connecting.  The problem turned out to be
that the GlobalSign RootCA cert is not valid ASN.1 DER.  Our
oem ssl software stores the RootCA (and other trust anchors)
in an unparsed format.  the signature of one's own rootCA is
retained in order to build forward certification pathes that
include the rootCA cert, however when reassembling the
GlobalSign RootCA cert with correct ASN.1 DER, the signature
no longer verifies...  And that caused the browsers to complain
(I don't remember whether all Browsers complained, and the
 original customer problem message has been moved to archive
 from our support system so I can no longer find it).

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.

Ignoring errors is only acceptable when a spec explicitly
describes the particular error and provides exact details
what to do, so that everyone knows that the designed thought
about this problem and the resulting implementations are
all going to behave the same way.

-Martin

---

From: Mike <[email-masked]>
Date: Mon, 27 Nov 2006 15:08:22 -0800

> rootCA cert during path validation in case the peer sends it.

My certificate store (which contains all the trusted certificates)
is indexed based on the DER encoding of the certificates, so if a
server includes a root certificate in its certification path, it
is easily determined to be a trust anchor.  So in my case TA ==
Root and you are left with TA -> CA -> EE.

However, this discussion pointed out that I was checking the
expiration date of the trust anchor, which apparently is not the
right thing to do, so I just eliminated that check.

Mike

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Nov 2006 14:54:14 +1300

"Kemp, David P." <[email-masked]> writes:

>RFC 3280 (and draft 3280bis-05) clearly specify that trust anchors are
>maintained out of band, and that trust anchor information does not include a
>validity period any other certificate fields except the four listed:

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?

(The correct way to handle this change would have been to stipulate the pre-
 X.509v4 behaviour by default, and then require the presence of some special
 critical extension to denote the new behaviour.  As it stands, the text is
 little better than random noise for all the effect it'll have on
 implementors.  The horse not only bolted on this one 15 years ago, it's had
 time to raise entire herds of new horses who aren't going to go back in the
 barn no matter how hard you slam the door).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 28 Nov 2006 10:32:08 -0500

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.

--------------------

-Martin

--------------------
From: pgut001 [mailto:[email-masked]] 

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.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 28 Nov 2006 20:54:13 -0700

A TA that creates a CA identification/authentication certificate in
the correct format (including proper date handling) is much more
likely to create other certificates in the correct format, and thus
NOT create issues in ASN.1 parsing.  Various ASN.1 parsers have had
security vulnerabilities that came to light.

-Kyle H

-- 

-Kyle H

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 29 Nov 2006 14:10:27 +0100

On Wed, Nov 29, 2006 at 02:51:45PM +0200, [email-masked] wrote:

>>> And this is IMHO roughly where we are today... the spec has a
>>> feature which nobody uses, and nobody can use. IMHO it would be
>>> better to remove it, rather than leave it there "just in case".

>> Well, for certificate chains that are "long" (compared to the
>> maximum fragment length, or to some device's more limited maximum
>> length for sending fragments), fragmentation is a feature that will
>> be used.

> Assuming, of course, that long certificate chains will be used in the
> first place... Typical SSL web server certs today seem to be around
> 1KB, so receiving fragments never gets tested in practice.

The maximum fragment length extension allows negotiating fragment
lengths as low as 512 bytes, so I think this length should be taken
into account.  With 512-byte fragments, those 1-KB certs will have to

> The test was done with the latest release (0.9.8d).  I did some
> debugging, and the reason why OpenSSL failed is as follows: usually
> OpenSSL (correctly) accepts any record layer version number of form
> {03,XX} for ClientHello, but if ClientHello is split to two separate
> records, it chokes on the second fragment and replies with
> "protocol_version" alert.
> 
> (My test client used TLS 1.1 version (03,02) for both fields; I guess 
> yours used TLS 1.0 which does indeed work.)

Bingo!  In the current OpenSSL server-side implementation, the server
uses the first few bytes to decide about the version, and insists on
that particular record-layer version for subsequent records -- even if
the client hasn't yet had a chance to learn about the protocol version
chosen by the server.  That's a bug, of course.

> I don't think the recipient-side code will get tested unless we
> specify "MUST randomly fragment messages" :-) And as Peter Gutmann
> pointed out, having poorly tested code for corner cases that really
> never happen is a security issue as well...

Testing with 512-byte fragments looks reasonable.  (It wouldn't have
cought the OpenSSL bug though since a typical ClientHello isn't that
long; however, with ClientHello extensions, it could become quite
large, so ClientHello fragmentation might eventually happen in some
real-life situations.)

Bodo

---

From: <[email-masked]>
Date: Wed, 29 Nov 2006 14:51:45 +0200

<snip>

<snip>

> > TLS 1.2 implementations yet... so we could even require 
> > that a single fragment can't contain multiple handshake messages.
> 

My worry is that just adding "And we mean it" wouldn't change the
current situation: since receiving-side processing is so poorly
implemented, the sending side can't really rely on it.

But yes, if we decide not to ban unnecessary fragmentation totally,
clearly such an implementation note (probably longer and more strictly
worded than just "And we mean it") would be in order.

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Wed, 29 Nov 2006 06:06:17 -0800

> chosen by the server.  That's a bug, of course.

In my implementation, I don't check the version of records prior to
establishing a secure connection.  However I found that the best
strategy for my client is to find out what version the server
supports from ServerHello, and then use that version for the rest
of the handshake.  Before I did that, I would occasionally get a
protocol_version error after sending the ChangeCipherSpec message.

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 29 Nov 2006 09:26:17 -0500

The point is that trust anchor installation is an out-of-band process:
standards say nothing about the due diligence that a relying party
should apply before deciding to accept a trust anchor.  Out-of-band
also means that if you receive a root cert that expires in 2050, you
are perfectly within your rights to configure your application to make
the corresponding TA valid until 2040, or 2060, as you see fit.

The standards also say nothing about how relying party applications
might be instrumented to perform debugging and error logging.
It is perfectly legal to check a root cert every single time you
receive it, and generate whatever error messages you wish if you
don't like what you see.  But it's also legal (according to TLS
and X.509) *and secure* to ignore a root cert received in a
handshake and validate the intermediate CA cert using just your
own pre-installed TA information.

Therefore, it is incorrect to claim that a web site or a browser
that is configured to send an expired root cert is misconfigured.
You are free to complain, but they are free, and correct, to point
out that standards do not require them to send a root cert
that is acceptable to you.  The responsibility is on you to decide
what intermediate CAs to trust based on your own TA list, not based
on the root certs someone else has installed in their applications.

Dave

-----Original Message-----
From: Kyle Hamilton [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2006 10:54 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [TLS] Record layer corner cases

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Nov 2006 02:10:49 +0100 (MET)

> The point is that trust anchor installation is an out-of-band process:

Correct!  What is a trust anchor is determined exclusively by local
configuration established through some out-of-band process.

Existing SSL/TLS protocols do NOT have a means to transfer trust anchors.

An X.509 certificate is something entirely different than a Trust Anchor.
It is just a convenience to use an X.509 container for distributing
Trust Anchors.

Whenever a Trust Anchor is wrapped in X.509 for transport, and especially
when it is tunneled through other protocols/PDUs that are specified
to carry X.509 certificates for authentication purposes (and NOT to
distribute trust anchors), then the sender MUST create a valid
X.509 cert, otherwise the sender is obviously and undoubtedly broken
and asking for interoperability problems.

SSL/TLS certainly does NOT (natively) provide a Trust Anchor transport
facility, it only provides one for X.509 certs for the purpose of
authenticating the communication peers.  Trust Anchors for an SSL/TLS
communication peer is information that is installed/configured out
of band.  Certs that arrive within forward certificate chains of
an SSL/TLS are NEVER Trust Anchors.

A SSL/TLS that verifies rootCA certs arriving in forward certification
paths and verifies them like this  TA -> rootCA -> CA -> EE
may not be "highly optimized", but is certainly working correctly.
And if it is validating the certification path in this fashion,
it certainly MUST fail validation if the rootCA is not valid.

An SSL/TLS peer that sends an invalid self-signed rootCA cert
together with a valid end-entity cert in the forward certification
path is likely broken.  It is definitely broken if it also
has a valid rootCA cert (and sends the wrong one) or if it
creates an invalid rootCA cert for inclusion from local TrustAnchor
information (which is what our OEM ssl implementation had been doing
with the GlobalSign RootCA cert).

> own pre-installed TA information.

It is legal and secure to ignore certificates that are outside of
the certification path between the peers end entity cert and the
verifiers chosen trust anchor.

Security-wise, the signature verification on the certification path
should be performed starting with the trust anchor and towards the
end entitiy certificate.

However, if a local trust anchor matches a rootCA cert, then that
rootCA cert then it is at the discretion of the verifier to consider
it part of the certification path or attempt an optimization and
eliminate it.  There certainly is no requirement that it be ignored!

> that is configured to send an expired root cert is misconfigured.

I strongly disagree.  A Server that sends a non-expired server cert
together with an expired CA cert is definitely misconfigured.
And if the servers SSL/TLS implementation has access to several
variants of the CA certs, some expired and some valid, then the
SSL/TLS implementation definitely and undoubtedly is broken
(i.e. needs a patch) if it sends the expired cert.

> on the root certs someone else has installed in their applications.

sending a valid rootCA cert is OK.

sending a trust anchor wrapped like an X.509 cert but with characteristics
that will certificate path validation is a pretty dumb idea and screaming
for interoperability problems.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Nov 2006 02:27:11 +0100 (MET)

> large, so ClientHello fragmentation might eventually happen in some

Since we had this discussion about what version number should be
used on the record protocol when sending the ClientHello -- the
case where ClientHello is fragmented is interesting:

Although most if not all SSLv3-only implementations have been patched
to accept {3,1} on the first record of a new connection, this is
not necessarily true for the additional records of a fragmented
ClientHello.

IMHO, using the lowest protocol version acceptable to the client
for all records carrying fragments of a ClientHello message is
the most interoperable and the only reasonable recommendation.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 30 Nov 2006 10:51:33 -0500

I see that Peter Williams is correct in that this topic is no
more amenable to a meeting of the minds than is religion or
politics.  There is very little to say that hasn't already
been said, except ...

> eliminate it.  There certainly is no requirement that it be ignored!

Correct, no such requirement appears in RFC 2246 or RFC 4346:

       Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

In the interest of unambiguity and interoperability, I would suggest
that the "ignore" statement you previously imputed to TLSv1 be
added as a requirement to TLS 1.2 (draft 4346bis):

       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.

Signing off,
Dave