Subject: [keyassure] Cert format substitution attack

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 09:42:39 -0400

One thought that occurred to me last night was that if we are going to allow
multiple cert formats, we have to prevent an attack that works by confusing
a cert in one format with another.

While this may sound farfetched, it is less far so when you consider what a
minimal RP implementation that is only looking for the EE key might do.

So we should do one of the following

1) instead of calculating SHA256 (cert) we should have SHA256 (cert-type,
cert).

2) instead of using SHA256(cert) we should use cert-type + SHA256(cert)

Cert-type could be an asn.1 OID or a CERT cert type.

Advantage of 1 is that there are no extra bytes. Advantage of 2 is that we
can use the same OID identifier to tell the RP what type of Cert is being
assured (end entity, intermediate, self-signed signer) and add in any
additional control info we might want.

-- 
Website: http://hallambaker.com/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Sep 2010 13:48:03 -0400

It occurs to me that one advantage of just binding to keys (not certs)  
is that this sort of thing is not an issue.

--Richard

On Sep 28, 2010, at 9:42 AM, Phillip Hallam-Baker wrote:

> One thought that occurred to me last night was that if we are going  
> to allow multiple cert formats, we have to prevent an attack that  
> works by confusing a cert in one format with another.
>
> While this may sound farfetched, it is less far so when you consider  
> what a minimal RP implementation that is only looking for the EE key  
> might do.
>
>
> 1) instead of calculating SHA256 (cert) we should have SHA256 (cert- 
> type, cert).
>
> Advantage of 1 is that there are no extra bytes. Advantage of 2 is  
> that we can use the same OID identifier to tell the RP what type of  
> Cert is being assured (end entity, intermediate, self-signed signer)  
> and add in any additional control info we might want.
>
>
> -- 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Sep 2010 11:16:52 -0700

At 1:48 PM -0400 9/28/10, Richard L. Barnes wrote:
>It occurs to me that one advantage of just binding to keys (not certs) is that this sort of thing is not an issue.

Given that the "issue" assumes a successful first-preimage attack on the cert, it is not clear if it is really an issue at all. No WGs in the IETF consider hardening against first-preimage attacks other than by having algorithm agility, which is already proposed here. Put another way, if there is an attack on hash(cert), there is an equivalent attack on hash(key), but there is also an attack on TLS and PKIX and....

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 16:10:49 -0400

The attack has nothing to do with cert pre-images. It is independent of the
strength of the algorithm and it is the reason that you certainly do not
want to be signing raw keys.

The reason behind the design of the RSA signature bit packaging formats is
precisely to prevent against this form of attack. Imagine that MD4 has been
broken completely but SHA256 is secure.

If the RSA signature was calculated on  0x00 .. 0x00 <SHA256 of certdata>,
the cert would look something like:

certdata =

Issuer
Subject
Digest Algorithm = SHA256
RSA (0x00 .. 0x00 <SHA256 of certdata>)

That approach FAILS because an attacker can generate:

Issuer
Subject
Digest Algorithm = MD4
RSA (0x00 .. 0x00 <MD4 of certdata>)

So instead the packaging format is
0x00 .. 0x00 OID(SHA256) <SHA256 of certdata>

That OID value in the bit string is essential to the security of the system.

Now imagine we are using raw keys without the algorithm ID

Digest  = SHA256 (ECDSA-512 keydata)

All that is necessary for the attacker to break the system is to find an
ECDSA bit string that is sufficiently similar to an RSA512 bit-string and
forms an easily factored composite modulus.

They can now break the system entirely by asking to establish a session and
present the RSA512 bit key.

The cert attack is essentially the same except that we are going to use the
fact that a cert package in one format might be misinterpreted as another.

Proper cryptographic hygiene requires that both the certificate type and the
certificate data be properly validated.

On Tue, Sep 28, 2010 at 2:16 PM, Paul Hoffman <[email-masked]> wrote:

> Given that the "issue" assumes a successful first-preimage attack on the
> cert, it is not clear if it is really an issue at all. No WGs in the IETF
> consider hardening against first-preimage attacks other than by having
> algorithm agility, which is already proposed here. Put another way, if there
> is an attack on hash(cert), there is an equivalent attack on hash(key), but
> there is also an attack on TLS and PKIX and....
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 28 Sep 2010 16:51:51 -0400

> RSA (0x00 .. 0x00 <MD4 of certdata>) 

If we ignore the fact that SHA256 has much longer output than MD4.  :)

I think the best way to view this is as a collision in the RSA input
data, of which the primary component is the digest.  Breaking one digest
algorithm should not make it possible to generate collisions with other
algorithms.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 28 Sep 2010 16:52:14 -0400

> 2) instead of using SHA256(cert) we should use cert-type + SHA256(cert) 

I.e., the intended certificate format should be part of the assurance.
Ideally, formats would be self-identifying via magic numbers for the
convenience of file(1) and sysadmins, but specifying the certificate
format appears to be future-proof at minimal cost.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Sep 2010 13:55:30 -0700

At 9:42 AM -0400 9/28/10, Phillip Hallam-Baker wrote:
>One thought that occurred to me last night was that if we are going to allow multiple cert formats, we have to prevent an attack that works by confusing a cert in one format with another.
>
>While this may sound farfetched, it is less far so when you consider what a minimal RP implementation that is only looking for the EE key might do.
>
>
>1) instead of calculating SHA256 (cert) we should have SHA256 (cert-type, cert).
>

At 4:10 PM -0400 9/28/10, Phillip Hallam-Baker wrote:
>The attack has nothing to do with cert pre-images.

The attack you provided in your first message relies on being able to create a first preimage for SHA256 of a "bad cert", that is, creating cert[bad] that has the exact same bits as cert[good]. Yet all know certificate types have indicators in them of what signature algorithm is used, so a broken signature algorithm (like the MD4 example you gave) will still not yield the same bits.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 17:17:47 -0400

It is not a pre-image attack, it is a semantic substitution attack. See
below

Yes, this type of attack is not possible against PKCS#1 signatures because
we use bit packaging formats that tell verifiers exactly what bits have to
be specified and which bits have to be checked.

My point was that we are going to have to do the same for our scheme.

A first preimage attack is
      given a hash value v and hash function h(x),
                       find a message m such that h(m) = v.

The attack we are concerned with here is:

Let the message m represent a message that is secure under the semantic
interpretation intended by the signer S1(m), break the key represented by
the alternative semantic interpretation Sx(m) where Sx() is any semantic
interpretation supported by the verifier.

The attack is at a completely different level to a pre-image attack, please
stop calling it that you are wrong and you are confusing people.

The attack PKCS#1 is designed to guard against is algorithm substitution:
      given hash functions h1(x), h2(x) and a message m
                       find a message m' such that h2(m') = h1(m)

On Tue, Sep 28, 2010 at 4:55 PM, Paul Hoffman <[email-masked]> wrote:

> >One thought that occurred to me last night was that if we are going to
> allow multiple cert formats, we have to prevent an attack that works by
> confusing a cert in one format with another.
> >
> >While this may sound farfetched, it is less far so when you consider what
> a minimal RP implementation that is only looking for the EE key might do.
> >
> >
> The attack you provided in your first message relies on being able to
> create a first preimage for SHA256 of a "bad cert", that is, creating
> cert[bad] that has the exact same bits as cert[good]. Yet all know
> certificate types have indicators in them of what signature algorithm is
> used, so a broken signature algorithm (like the MD4 example you gave) will
> still not yield the same bits.
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 17:26:47 -0400

Agreed,

Though I prefer the term 'algorithm identifier' to magic number, since magic
number implies that this is some sort of heuristic approach which it isn't.

We have a choice of the CERT RR types or the ASN.1 OIDS.

I much prefer using ASN.1 OIDS since they allow anyone to use any algorithm
they choose without IANA having to allocate a code point. This in turn means
that IANA does not need to allocate code points for every bit of vanity
crypto people might propose and the IETF does not need to risk the
implication that assigning a code point implies endorsement.

A secondary advantage is that we can punt on the issue of flags. If we need
to encode more data we use a different OID.

On Tue, Sep 28, 2010 at 4:52 PM, Matt McCutchen <[email-masked]>wrote:

> allow
> a

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Sep 2010 01:00:09 +0300

> implication that assigning a code point implies endorsement.

I disagree. At least with TLS (Its 'TLSFP', right?) certificate type is fixed
length integer field, so best just use that. It would also mean clients don't
have to have translation tables between ASN.1 OIDs and TLS certificate types.

Now if underlying protocol uses ASN.1 OIDs for certificate types, one should
use those then. But that's not TLS.

Also, recall binary encoding of ASN.1 OID of OpenPGP offhand? :-)

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Sep 2010 15:04:34 -0700

At 5:17 PM -0400 9/28/10, Phillip Hallam-Baker wrote:
>It is not a pre-image attack, it is a semantic substitution attack. See below

This "attack" only works if there are two different certificate formats where a valid certificate under one format can also be a valid certificate under another format. There are no known instances of that, and the possibility of a new certificate format that could, for example, be different than PKIX or OpenPGP certificates but take the exact same set of bits but interpret them differently is approximately zero.

>Yes, this type of attack is not possible against PKCS#1 signatures because we use bit packaging formats that tell verifiers exactly what bits have to be specified and which bits have to be checked.

It is also not possible against any of the myriad of certificate formats known today.

>My point was that we are going to have to do the same for our scheme.

I understand that is your point. Your point is wrong.

>Let the message m represent a message that is secure under the semantic interpretation intended by the signer S1(m), break the key represented by the alternative semantic interpretation Sx(m) where Sx() is any semantic interpretation supported by the verifier.

No, that is not true. The "attack" you describe is:

C1 is a certificate that has a semantic interpretation in certificate format F1. If there is a C2 that has the exact same bits as C1 but has a different semantic interpretation under certificate format F2, then an attacker can substitute the semantics of C2 for C1 if C1 is authenticated by hash(C1).

>The attack is at a completely different level to a pre-image attack, please stop calling it that you are wrong and you are confusing people.

So far, you are the only one confused. If others are confused, please speak up.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 18:11:49 -0400

No, it is not at all clear that this is TLSFP

Tying the mechanism to one protocol seems unnecessary to me.

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 18:14:21 -0400

The chance that the security area reviewer will spot this is much closer to one.

Asserting without checking that probabilities are zero aint the way security protocols should be designed in my view.

Checking would be rather error orone and certainly tedious. Preventing the attack completely is much easier.

Sent from my iPad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 18:18:08 -0400

Oh and try to learn the terminology of the crypto field before you try to correct others with snippy put downs

You twice asserted this was a pre image attack, you were wrong 

Sent from my iPad

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Sep 2010 22:24:04 -0400

If you think about what one would have to do to exploit this supposed  
vulnerability, then it is precisely a preimage attack.  If I'm a rogue  
web server, my goal is to convince the client that the cert I present  
in TLS (Cert0) matches the cert asserted in the DNS (Cert1).  In  
TLSFP, the matching is done based on a hash of the cert, so for my  
attack to succeed I need for all of the following to be true of Cert0:
1. It is a valid certificate in a format the client supports;
2. It has a public key whose private key I control; and
3. H(Cert0) == H(Cert1)

It is (3) that makes this a preimage attack, and the combination of  
(1) and (3) that makes it practically infeasible, as Paul notes.  The  
addition of (2) makes it extra challenging because the public key  
makes up a significant chunk of the bits in a cert, and generating  
public keys is expensive.

(Note that this argument applies regardless of what aspect of the cert  
I'm trying to change -- in particular if I try to change the key.   
That's the attack we're all fundamentally here to prevent, but the  
same logic applies to other aspects of the cert.)

In any case, even if you don't buy the above argument, you don't need  
to muck around with the certificate hash in order have an assured  
statement about the certificate format.  The TLSFP record is itself  
secure, so all you would need to do is add a field to the record.

--Richard

On Sep 28, 2010, at 6:18 PM, Phillip Hallam-Baker wrote:

> Oh and try to learn the terminology of the crypto field before you  
> try to correct others with snippy put downs
>
>> This "attack" only works if there are two different certificate  
>> formats where a valid certificate under one format can also be a  
>> valid certificate under another format. There are no known  
>> instances of that, and the possibility of a new certificate format  
>> that could, for example, be different than PKIX or OpenPGP  
>> certificates but take the exact same set of bits but interpret them  
>> differently is approximately zero.
>>
>>> Yes, this type of attack is not possible against PKCS#1 signatures  
>>> because we use bit packaging formats that tell verifiers exactly  
>>> what bits have to be specified and which bits have to be checked.
>>
>>> Let the message m represent a message that is secure under the  
>>> semantic interpretation intended by the signer S1(m), break the  
>>> key represented by the alternative semantic interpretation Sx(m)  
>>> where Sx() is any semantic interpretation supported by the verifier.
>>
>> C1 is a certificate that has a semantic interpretation in  
>> certificate format F1. If there is a C2 that has the exact same  
>> bits as C1 but has a different semantic interpretation under  
>> certificate format F2, then an attacker can substitute the  
>> semantics of C2 for C1 if C1 is authenticated by hash(C1).
>>
>>> The attack is at a completely different level to a pre-image  
>>> attack, please stop calling it that you are wrong and you are  
>>> confusing people.
>>

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 28 Sep 2010 22:47:33 -0400

On Tue, 2010-09-28 at 22:24 -0400, Richard L. Barnes wrote:
> It is (3) that makes this a preimage attack

There are two subcases:

a. Cert0 == Cert1 (bitwise)
b. Cert0 != Cert1

Case (b) is a second preimage attack.  Case (a) is not, and I think
Phillip is talking about that one.  Is there any realistic possibility
of (a) happening?  Paul says not.  Still, if the TLS server presents for
the client's consideration a cert_type extension (absent treated as 0)
followed by a certificate of that type, one can argue the natural thing
to assure is a cert_type followed by a certificate of that type.

> secure, so all you would need to do is add a field to the record.

For the purpose of assurance, I don't see how it's more desirable to
have the certificate format either inside or outside the hash.  The
other considerations in Phillip's original mail apply.

-- 
Matt

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Sep 2010 23:06:39 -0400

> to assure is a cert_type followed by a certificate of that type.

Your analysis is correct, but do you really find (a) plausible?   
Certificates are highly structured data items (as I discovered the  
other day when I had to manually decode a PKIX cert), so it seems very  
unlikely that two certificates formats would accept the same string of  
bits as valid.  The PKCS#1 analogy that Phil made is incorrect,  
because this structure drastically reduces the probability of overlap  
-- certs are not hashes; they're not opaque bit strings.  Until  
there's at least an existence proof (or even a plausible argument), I  
think (a) can safely be written of.

To say this differently, the bits in the target certificate would need  
to be such that:
1. They are valid in Format1
2. They are valid in Format2
3. The public key in Format1 is the one controlled by the real domain  
owner
4. The public key in Format2 is the one controlled by the attacker
This seems even more implausible than a second preimage attack,  
especially because of (3) and (4).

Even if overlaps do exist, it seems like the space of certificate  
formats is small enough and the equivalence brittle enough that the  
domain owner could check for them and change something trivial (public  
key, serial number) to resolve it.

> other considerations in Phillip's original mail apply.

The main benefit I see is a clean separation between an identification  
of the certificate and metadata about the certificate.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Sep 2010 23:32:29 -0400

Matt is exactly right here.

The attack I was talking about was case a, which is why I keep saying that
it is not a pre-image attack, first or second.

I design cryptographic protocols, not cryptographic algorithms. That is why
I don't usually bother with pre-image attacks until a much later stage in
the design, they are the cryptographer's job, not mine. Substitution attacks
on the other hand are something that bother me a great deal. There are many
real-world attacks against real world protocols that are based on them.

Now it might seem that finding a way to leverage this into a protocol break
is 'implausible', but that is hardly an accepted criteria for security
protocol design. I would have never considered return-oriented programming
to be a plausible approach to breaking Data Execution Prevention till
someone wrote a compiler. Lots of things look implausible till you spend
time thinking hard about how to do them.

ASN.1 is a self describing data syntax, as is XML. It is really not very
improbable for someone to propose a new cert format in either syntax that
can be used to break an incomplete ASN.1 or XML stack.

Preventing the attack completely is easy and requires much less code than
doing either XML or ASN.1 completely right. Estimating the likelihood is at
best time consuming and at worst going to result in a broken protocol.

Now next time I raise a potential security issue, could people at least
consider the possibility that I might have some competence and experience in
this field before they try to tell me why I am talking about a different
attack that isn't a problem anyway?

One of the things that is worrying me here is that the response of the group
to possible design issues seems to be on list attacks and off list threats
and bullying. Now that does not discourage me, but I certainly don't pretend
to have an exhaustive knowledge of possible issues that should be
considered. But I think it would probably drive most people away.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 28 Sep 2010 23:42:52 -0400

I'm glad we finally at least agree on a description of the problem.   
That has been a significant hurdle in several threads on this list.

> I design cryptographic protocols, not cryptographic algorithms. That  
> is why I don't usually bother with pre-image attacks until a much  
> later stage in the design, they are the cryptographer's job, not  
> mine. Substitution attacks on the other hand are something that  
> bother me a great deal. There are many real-world attacks against  
> real world protocols that are based on them.

[Citation needed]

As far as I am aware, there are no examples of certificate formats  
overlapping with one another. Let's make this concrete.  TLS and IPsec  
support the following certificate formats:

TLS [1]:
X.509v3
OpenPGP

IPsec [2]:
PKCS #7 wrapped X.509 certificate
PGP Certificate
DNS Signed Key
X.509 Certificate - Signature
Kerberos Token
Certificate Revocation List (CRL)
Authority Revocation List (ARL)
SPKI Certificate
X.509 Certificate - Attribute
Raw RSA Key
Hash and URL of X.509 certificate
Hash and URL of X.509 bundle

Can you identify any instance in which the same bit sequence is valid  
in more than one of these formats?

[1] <http://tools.ietf.org/html/rfc5246#section-7.4.2>
[2] <http://tools.ietf.org/html/rfc4306#section-3.6>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Sep 2010 00:05:08 -0400

I think we can all be fairly certain that the only person that is going to
be bothered to read the relevant documents in the necessary detail to
determine the feasibility of an attack is an attacker.

The onus is on the designer of a protocol to prove that it is safe.

Since the list is extensible nobody can review all the relevant documents
without access to a time machine.

On Tue, Sep 28, 2010 at 11:42 PM, Richard L. Barnes <[email-masked]> wrote:

> I'm glad we finally at least agree on a description of the problem.  That
> has been a significant hurdle in several threads on this list.
>
>
>  I design cryptographic protocols, not cryptographic algorithms. That is
>> why I don't usually bother with pre-image attacks until a much later stage
>> in the design, they are the cryptographer's job, not mine. Substitution
>> attacks on the other hand are something that bother me a great deal. There
>> are many real-world attacks against real world protocols that are based on
>> them.
>>
>
> [Citation needed]
>
> Can you identify any instance in which the same bit sequence is valid in
> more than one of these formats?
>
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 29 Sep 2010 00:15:09 -0400

The onus on the designer of a protocol is to demonstrate that there  
are no feasible attacks based on the current known state of the art.   
I am not hearing you argue that there is a known feasible attack here  
that we need to address.

The lists are extensible, but only by limited mechanisms (TLS: Expert  
review; IPsec: IETF Consensus) that are designed to ensure that issues  
like overlapping formats don't arise.

--Richard

On Sep 29, 2010, at 12:05 AM, Phillip Hallam-Baker wrote:

> I think we can all be fairly certain that the only person that is  
> going to be bothered to read the relevant documents in the necessary  
> detail to determine the feasibility of an attack is an attacker.
>
>
> Since the list is extensible nobody can review all the relevant  
> documents without access to a time machine.
>
> overlapping with one another. Let's make this concrete.  TLS and  
> IPsec support the following certificate formats:
>
> TLS [1]:
> X.509v3
> OpenPGP
>
> IPsec [2]:
> Can you identify any instance in which the same bit sequence is  
> valid in more than one of these formats?
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Sep 2010 10:56:45 +0300

On Tue, Sep 28, 2010 at 11:06:39PM -0400, Richard L. Barnes wrote:
> 
> To say this differently, the bits in the target certificate would
> need to be such that:
> 3. The public key in Format1 is the one controlled by the real
> domain owner

OTOH, the "key" read out from certificate in wrong format is likely total
junk, but if it is read as RSA key, it might work and be breakable (if
its read as DSA key, it will not work, but there might still be way to
generate some "signatures" that "validate".)

Original certficate would also need to be non-maliscous. Because the original
cert won't be maliscous or one can't assure anything with it (and that would
be fault of "legimate" owner).
 
-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Sep 2010 13:08:10 -0400

Maintenance of security protocols is hard enough without allowing known
security errors into the protocol.

In this case your 'solution' requires that a security issue in the KEYASSURE
protocol be prevented by vigilance on the part of the TLS protocol reviewer.

We have a clean solution, why do we even need to argue about this? Are
people so invested in their code?

On Wed, Sep 29, 2010 at 12:15 AM, Richard L. Barnes <[email-masked]> wrote:

> The onus on the designer of a protocol is to demonstrate that there are no
> feasible attacks based on the current known state of the art.  I am not
> hearing you argue that there is a known feasible attack here that we need to
> address.
>
> review; IPsec: IETF Consensus) that are designed to ensure that issues like
> overlapping formats don't arise.
>
> --Richard
>
>
>
> On Tue, Sep 28, 2010 at 11:42 PM, Richard L. Barnes <[email-masked]>wrote:
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Sep 2010 10:24:54 -0700

The general trend of paring security protocols down to the bare
minimum leads to fragile protocols that fall apart when a single
building block fails. If it isn't expensive to prevent an esoteric and
unlikely attack, what is the argument for deciding to allow that
attack?

In other words, I don't really care how unlikely the attack is, it's
cheap to counter, so why not counter it?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2010 11:15:34 -0700

>cheap to counter, so why not counter it?

Because countering it has a cost. So far, there have been three proposals for how to identify the type of the cert used in TLS:
a) use the identifier used for the CERT RR
b) use an OID
c) use the TLS identifier

Choice (a) limits your TLS authentication to things that have been defined on standards track for DNS; to me, that's a layer violation that will cause some people not to be able to use the proposed solutions because we haven't kept up with new TLS certificate types. Choice (b) leads to lack of interop because there are different OIDs for the same certificate types; that's the beauty and curse of OIDs.

Choice (c) seems to be OK *if* we think that people will be able to register new types easily. If not, they will use values 224-255, probably in an inconsistent manner, and interop will go to hell in a similar fashion as it does for OIDs.

I still have not seen an argument that says that the bits-on-the-wire format for certificates is not self-defining. If it is self-defining, then there literally is no attack.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Sep 2010 14:52:16 -0400

The OIDs for use with CERT records are already in the CERT RFC.

http://tools.ietf.org/html/rfc4398#page-6

On Wed, Sep 29, 2010 at 2:15 PM, Paul Hoffman <[email-masked]> wrote:

> Because countering it has a cost. So far, there have been three proposals
> for how to identify the type of the cert used in TLS:
> Choice (a) limits your TLS authentication to things that have been defined
> on standards track for DNS; to me, that's a layer violation that will cause
> some people not to be able to use the proposed solutions because we haven't
> kept up with new TLS certificate types. Choice (b) leads to lack of interop
> because there are different OIDs for the same certificate types; that's the
> beauty and curse of OIDs.
>
> Choice (c) seems to be OK *if* we think that people will be able to
> register new types easily. If not, they will use values 224-255, probably in
> an inconsistent manner, and interop will go to hell in a similar fashion as
> it does for OIDs.
>
> I still have not seen an argument that says that the bits-on-the-wire
> format for certificates is not self-defining. If it is self-defining, then
> there literally is no attack.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2010 12:54:46 -0700

At 2:52 PM -0400 9/29/10, Phillip Hallam-Baker wrote:

The OIDs for use with CERT records are
already in the CERT RFC.

This is technically incorrect with respect to the attack you
describe in this thread. The OIDS listed in RFC 4398 only define four
sub-types of PKIX certs. For example, those OIDs listed there do not
cover non-PKIX certs such as OpenPGP.

--Paul Hoffman, Director

--VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 29 Sep 2010 23:05:12 +0300

On Wed, Sep 29, 2010 at 11:15:34AM -0700, Paul Hoffman wrote:
> register new types easily. If not, they will use values 224-255, probably
> in an inconsistent manner, and interop will go to hell in a similar fashion
> as it does for OIDs.

If client and server don't agree what some certificate type code means,
then one already has interop problems...

So I don't think the interop problems are any worse than what exists already.
Either it would work or the client would be in trouble anyway.

OIDs would have worse problems:
- Nonstandard OIDs used for something.
- Mapping tables between TLS typecodes and (possibly various) OIDs they have.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Sep 2010 13:36:16 -0700

>then one already has interop problems...

Hrm, excellent point.

>Either it would work or the client would be in trouble anyway.

Yep.

OK, I'm sold. It seems like it will be completely useless forever, but the cost is low if we just re-use the TLS cert identifier (not the CERT identifier or an OID).

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Sep 2010 16:56:45 -0400

That ties the proposal to TLS

So now what happens when someone wants to do the same thing for a non TLS
protocol?

Now they have to define a new CERT certificate type and a different code.

There is a big difference in a spec between saying that the WG is only going
to consider TLS use cases and saying that it is allowed to create a layering
dependence on TLS.

On Wed, Sep 29, 2010 at 4:36 PM, Paul Hoffman <[email-masked]> wrote:

> OK, I'm sold. It seems like it will be completely useless forever, but the
> cost is low if we just re-use the TLS cert identifier (not the CERT
> identifier or an OID).
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Sep 2010 01:04:54 +0300

> So now what happens when someone wants to do the same thing for a non TLS

As for IPSEC, it has numeric code too. If proto X has OID, then use OID.

> Now they have to define a new CERT certificate type and a different code.

Yup. Not that much work.
 
> to consider TLS use cases and saying that it is allowed to create a layering

Well, if entry subtype is TLSFP, what do you expect?

-Ilari

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Sep 2010 18:25:00 -0400

On Sep 28, 2010, at 11:42 PM, Richard L. Barnes wrote:

>> I design cryptographic protocols, not cryptographic algorithms.  
>> That is why I don't usually bother with pre-image attacks until a  
>> much later stage in the design, they are the cryptographer's job,  
>> not mine. Substitution attacks on the other hand are something that  

Thank you, I think that this has cleared things up a bunch, and moved  
the discussion into one that is more data driven...

Thanks Richard,

W

--
"Real children don't go hoppity-skip unless they are on drugs."

     -- Susan, the ultimate sensible governess (Terry Pratchett,  
Hogfather)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Sep 2010 22:26:00 -0400

Not decided that the id is TLSFP

Sent from my iPhone