Subject: [keyassure] Object Digest Reference

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 09:57:07 -0500

One of the components introduced in CAA-01 is the Object Digest Identifier.
Which people seem to be more comfortable renaming Object Digest Reference to
avoid confusion with OIDs.

I think it would be a good idea to use the ODR construct to identify
certificates in DANE.

While some might argue that the ODR construct guards against attacks that
may or may not be relevant, the overhead is trivial and as far as I can see
there is no room to argue that it is under-designed.

I would rather be accused of moderate over-design (ten extra bytes) than
have to go through WG discussion and then re-litigate the issue with the
IESG.

The ODR construct is:

   DNSCAA DEFINITIONS ::=

   BEGIN

    ObjectDigestReference ::= SEQUENCE {
      type             OBJECT IDENTIFIER,
      digestAlgorithm  OBJECT IDENTIFIER,
      digest           OCTET STRING
    }

   END

Provided the ODR itself is authentic, it provides a strong cryptographic
reference to a specific string of bits with a specified semantic
interpretation using a specified digest algorithm.

The OID space is extensible, anyone can register code points. X.509 certs
already use this registry so re-use does not introduce a new registry.

While it is tempting to re-use the DNSSEC code points, they serve a
different purpose in my view. Key assure is application level crypto and
should use an application level identifier registry. That is either the
ascii label registry or the OIDs.

In the future I would like to see algorithm management for application layer
crypto taken over by SAAG or some other group and managed across the whole
application space. I would like DANE to be in that pool and not an odd
appendage to DNSSEC.

The other reason for having a little more overhead here is that an ODR can
be used as a totally generic fingerprint. It is something that we can
perhaps expect a cryptographic application to emit as a matter of course. I
would like to be able to cut and paste ODRs from one place to another.

Having the semantic tag in the digest makes it secure against a semantic
substitution attack and enables cut n' paste type use.

If the group wants to go this way, I would suggest that we unhook the ODR
component from the CAA draft and make it a standards track WG document. It
is probably best that it be a separate document as the whole point is to
make it a generic construct like Base64.

In addition to the binary form, I would add in a URI encoding form and make
the relevant application.

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 08:04:16 -0800

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
>While some might argue that the ODR construct guards against attacks that may or may not be relevant,

Who is "some" here, and what kind of attacks does "some" claim that an ASN.1 sequence guards against that concatenating the three fields themselves doesn't?

> the overhead is trivial and as far as I can see there is no room to argue that it is under-designed.

The size overhead is small, the programming overhead maybe not so much.

>I would rather be accused of moderate over-design (ten extra bytes) than have to go through WG discussion and then re-litigate the issue with the IESG.

Please define "re-litigate". This is a serious matter.

>Provided the ODR itself is authentic,

What does "authentic" mean in this context?

>it provides a strong cryptographic reference to a specific string of bits with a specified semantic interpretation using a specified digest algorithm.

Do you believe that it is a stronger cryptographic reference than concatenating the three fields (the first two of which are fixed-length)? If so, why?

>The OID space is extensible, anyone can register code points. X.509 certs already use this registry so re-use does not introduce a new registry.

Fully agree. And the free extensibility leads to lack of interoperability and confusion. Many people consider those to be bad features.

>While it is tempting to re-use the DNSSEC code points, they serve a different purpose in my view. Key assure is application level crypto and should use an application level identifier registry. That is either the ascii label registry or the OIDs.

TLS is a protocol used by application-layer clients and servers. Why not reuse its registries (which are neither ASCII or OIDs)?

>In the future I would like to see algorithm management for application layer crypto taken over by SAAG or some other group and managed across the whole application space. I would like DANE to be in that pool and not an odd appendage to DNSSEC.

If that happens, DANE could certainly be updated.

>The other reason for having a little more overhead here is that an ODR can be used as a totally generic fingerprint.

It is true that an ODR can be used as a totally generic fingerprint; so can any binary or ASCII representation.

>It is something that we can perhaps expect a cryptographic application to emit as a matter of course. I would like to be able to cut and paste ODRs from one place to another.

That sounds good.

>Having the semantic tag in the digest makes it secure against a semantic substitution attack and enables cut n' paste type use.

How would such a substitution attack on an ODR or other blob happen without there being a serious degredation of the preimage strength of the digest algorithm? You claimed otherwise earlier on the list but didn't justify your argument, and some of us disagreed with you.

>If the group wants to go this way, I would suggest that we unhook the ODR component from the CAA draft and make it a standards track WG document. It is probably best that it be a separate document as the whole point is to make it a generic construct like Base64.
>
>In addition to the binary form, I would add in a URI encoding form and make the relevant application.

Can you give an example of where the URI encoded form could be useful?

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 13:59:28 -0500

On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman <[email-masked]>wrote:

> may or may not be relevant,
>
> Who is "some" here, and what kind of attacks does "some" claim that an
> ASN.1 sequence guards against that concatenating the three fields themselves
> doesn't

Some folk on this list doubted that a semantic substitution attack was an
issue for the KEYASSURE/CERT proposal.

I am pretty sure that a semantic substitution attack would be a very big
deal if multiple cert/key formats are allowed. In particular, I think we can
end up with a situation where minimal implementations could be attacked if
they have less than full X.509 / SAML / whatever stacks.

> The size overhead is small, the programming overhead maybe not so much.

A full ASN.1 stack is a PITA, agreed.

The main reason the CAA draft has the explanation it does is to show that a
full ASN.1 packer/depacker is not necessary. Everything can be handled off
fixed pre-calculated prefixes for each supported digest algorithm if that is
desired.

> Please define "re-litigate". This is a serious matter.

Well, in KeyProv we made a bunch of design decisions that nobody much cared
about very much, just provided that there was a canonical form of password
encoding. Then during last call, we discovered that it was something that
people cared very much was done in the same way that SASL is done and so
ended up changing to reference one of your own RFCs as it happens in order
to clear a DISCUSS.

Now absent some really clear indication to the contrary, using ASN.1 OIDs
for identifying cryptographic algs and formats is pretty much a slam dunk. I
can't see how anyone could say that it is not an acceptable way to go for
any application layer design.

Here we do have the other option of using the DNSSEC hash registry and
defining appropriate codes for the hash algs we want to use. But that is
going to produce a format that is only relevant to DANE and is going to have
to be managed as an adjunct to DNSSEC in perpetuity rather than as a part of
application layer crypto management.

So my view is that the ASN.1 OIDs are the way to go in this case, even
though I really dislike ASN.1.

> What does "authentic" mean in this context?

Should have been 'authenticated'. There is no digital signature in the ODR
itself, it is only useful if authenticated (e.g. DNSSEC, TLS, cert
signature, etc.).

> >it provides a strong cryptographic reference to a specific string of bits
> with a specified semantic interpretation using a specified digest algorithm.
>
> Do you believe that it is a stronger cryptographic reference than
> concatenating the three fields (the first two of which are fixed-length)? If
> so, why?
>

Nope.

The only reason for adding the enclosing SEQUENCE is so that there is an
atomic unit that can be slotted into other ASN.1 contexts (e.g. OCSP
response, X.509 cert, whatever).

> Fully agree. And the free extensibility leads to lack of interoperability
> and confusion. Many people consider those to be bad features.

They are bad within DNSSEC. But unavoidable at the upper layers. I would
prefer not to have to support PGP and other key formats in this scheme, but
they are going to be unavoidable politically.

This is an infrastructure proposal like XML Signature. We are going to have
folk come along and insist that they need specific crypto. And some are
going to be right.

In particular, we know that we are not 100% happy with the SHA-2 algorithm
and anticipate a shift to SHA3. But there may also be specific requirements
from certain countries.

I don't like having to deal with all that. But what I really, really want to
avoid is having application layer crypto impact DNSSEC.

In practice, this is self regulating. If everyone supports SHA2 then
everything else is just

> TLS is a protocol used by application-layer clients and servers. Why not
> reuse its registries (which are neither ASCII or OIDs)?

We should not tie a PKI scheme to a protocol level registry. People are
going to want to use keys with IPSEC and all sorts of other protocols.

That might be out of scope at this point, but that is not carte-blanch to
shoot ourselves in the foot.

We have only two sets of approved protocol independent crypto registries.
One is the PEM codes and the other is ASN.1.

We should not consider any others.

> >In the future I would like to see algorithm management for application
> layer crypto taken over by SAAG or some other group and managed across the
> whole application space. I would like DANE to be in that pool and not an odd
> appendage to DNSSEC.
>

Yes, I want DANE to be on the applications update schedule and not tied to
DNS, TLS or anything else.

> be used as a totally generic fingerprint.
>

Only if it has the object identifier and algorithm identifier codes in.

At the moment, most 'cryptographic fingerprints' are MD5 hex dumps or they
might be SHA-1 but only the producer knows what they are or what semantics
they relate to.

> How would such a substitution attack on an ODR or other blob happen without
> there being a serious degredation of the preimage strength of the digest
> algorithm? You claimed otherwise earlier on the list but didn't justify your
> argument, and some of us disagreed with you.

Guarding against this form of attack is most certainly best practice.

At the moment the chances are that there will be no issue because the only
formats we are likely to use are in completely different encoding spaces.
SAML is in XML, PKIX is in ASN.1 and PGP in something else again.

I think it highly likely that will continue to be the case and no issue will
arise. But there is no way any of us can predict how key formats are going
to evolve and so there is no way that either of us can guarantee that no
problem will arise in the context of DANE.

I think it is far more likely that someone will find a way to exploit a
semantic attack in the wild than they will find an attack on SHA2-256. But
that does not mean I would be happy only supporting one digest algorithm.

In the wider context that ODR is designed to address, the problem quite
definitely arises. So the choice is between a digest format that is a one
off for DANE and cannot be reused or one that maybe has 6 extra bytes that
are not absolutely necessary in DANE.

> Can you give an example of where the URI encoded form could be useful?

OK, how about on a web page. Imagine that we have a web page that is
downloaded from a TLS site but the images are stored on a separate image
server that does not have TLS.

At the moment this is such a common use case that it is really difficult to
get enforcement on because it is so common. And there is another variation
where the data linked to is not even in the same domain.

Imagine we can create a link of the form:

<img src="http://images.example.com/1.gif"
    odr="odr:woei2oqur02que0o2quefoiqwefouqwefoiu=="/>

Packaging it up as a URI is not strictly necessary but that is what it is
functionally.

One could even have a cache of content referenced by ODR lookup. So if the
content is not locatable, it can be pulled from cache.

<a href="http://tools.ietf.org/rfc6666.txt
    odr="odr:woqi12o3o12hroiqhweoiqhwe==">RFC 6666</a>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 11:41:22 -0800

At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wrote:

On Mon, Dec 13, 2010 at 11:04 AM, Paul
Hoffman <[email-masked]>
wrote:

>While some might argue that the ODR construct guards against
attacks that may or may not be relevant,

Who is "some" here, and what kind of attacks
does "some" claim that an ASN.1 sequence guards against that
concatenating the three fields themselves doesn't

Some folk on this list doubted that a
semantic substitution attack was an issue for the KEYASSURE/CERT
proposal.

I am pretty sure that a semantic
substitution attack would be a very big deal if multiple cert/key
formats are allowed. In particular, I think we can end up with a
situation where minimal implementations could be attacked if they have
less than full X.509 / SAML / whatever stacks.

If there are only two formats (full PKIX certificates and
hash-of-PKIX certificates), do you still see a substitution
attack?

> the overhead is trivial and as far as I can see there
is no room to argue that it is under-designed.

The size overhead is small, the programming overhead maybe
not so much.

A full ASN.1 stack is a PITA,
agreed.

The main reason the CAA draft has the
explanation it does is to show that a full ASN.1 packer/depacker is
not necessary. Everything can be handled off fixed pre-calculated
prefixes for each supported digest algorithm if that is
desired.

Your "precalculated prefixes" in -caa-01 only works if
the parties use the defined prefixes. What if they use something else
from the OID tree? If the standard does *not* allow the flexibility of
OIDs and requires things from a very narrow part of the OID tree (as
-caa-01 suggests but does not say so clearly), what is the advantage
of using OIDs over a registry?

>I would rather be accused of moderate over-design (ten
extra bytes) than have to go through WG discussion and then
re-litigate the issue with the IESG.

Please define "re-litigate". This is a serious
matter.

Well, in KeyProv we made a bunch of
design decisions that nobody much cared about very much, just provided
that there was a canonical form of password encoding. Then during last
call, we discovered that it was something that people cared very much
was done in the same way that SASL is done and so ended up changing to
reference one of your own RFCs as it happens in order to clear a
DISCUSS.

Now absent some really clear indication
to the contrary, using ASN.1 OIDs for identifying cryptographic algs
and formats is pretty much a slam dunk. I can't see how anyone could
say that it is not an acceptable way to go for any application layer
design.

I can. It wastes space, it allows flexibility where none is
needed, and encoding either requires a full ASN.1 stack *or* the
namespace needs to be restricted so heavily that a registry is
sufficient. These are two opposing views, and there are probably
others.

Here we do have the other option of using
the DNSSEC hash registry and defining appropriate codes for the hash
algs we want to use. But that is going to produce a format that is
only relevant to DANE and is going to have to be managed as an adjunct
to DNSSEC in perpetuity rather than as a part of application layer
crypto management.

That's not the only option: we can also use the TLS hash
registry,
<http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-17>, which is already in use by the TLS
stacks. Or we could invent our own registry, which is pretty much what
you are suggesting by your constrained-OIDs proposal in -caa-01. There
are many options.

So my view is that the ASN.1 OIDs are the
way to go in this case, even though I really dislike
ASN.1.

type             OBJECT IDENTIFIER,

digest
OCTET STRING

Should have been 'authenticated'. There
is no digital signature in the ODR itself, it is only useful if
authenticated (e.g. DNSSEC, TLS, cert signature, etc.).

Got it. Correct.

>it provides a strong cryptographic reference to a
specific string of bits with a specified semantic interpretation using
a specified digest algorithm.

Do you believe that it is a stronger cryptographic
reference than concatenating the three fields (the first two of which
are fixed-length)? If so, why?

Nope.

The only reason for adding the enclosing
SEQUENCE is so that there is an atomic unit that can be slotted into
other ASN.1 contexts (e.g. OCSP response, X.509 cert,
whatever).

What is an example where that would actually be useful? (I can't
tell if I'm being dense or you're being very general.)

>The OID space is extensible, anyone can register code
points. X.509 certs already use this registry so re-use does not
introduce a new registry.

Fully agree. And the free extensibility leads to lack of
interoperability and confusion. Many people consider those to be bad
features.

They are bad within DNSSEC. But
unavoidable at the upper layers. I would prefer not to have to support
PGP and other key formats in this scheme, but they are going to be
unavoidable politically.

That has yet to be determined. No one has given usage examples
for PGP or SPKI yet, and I certainly don't want this WG to get bogged
down in trying to work in possible uses for which there is no actual
need.

This is an infrastructure proposal like
XML Signature. We are going to have folk come along and insist that
they need specific crypto. And some are going to be
right.

Sure, but that has nothing to do with using OIDs. Any extensible
namespace would work equivalently, yes?

In particular, we know that we are not
100% happy with the SHA-2 algorithm and anticipate a shift to SHA3.
But there may also be specific requirements from certain
countries.

Right.

I don't like having to deal with all
that. But what I really, really want to avoid is having application
layer crypto impact DNSSEC.

Fully agree, but that seems like a non sequitur.

In practice, this is self regulating. If
everyone supports SHA2 then everything else is just

>While it is tempting to re-use the DNSSEC code points,
they serve a different purpose in my view. Key assure is application
level crypto and should use an application level identifier registry.
That is either the ascii label registry or the OIDs.

TLS is a protocol used by application-layer clients and
servers. Why not reuse its registries (which are neither ASCII or
OIDs)?

We should not tie a PKI scheme to a
protocol level registry. People are going to want to use keys with
IPSEC and all sorts of other protocols.

That might be out of scope at this point,
but that is not carte-blanch to shoot ourselves in the
foot.

We have only two sets of approved
protocol independent crypto registries. One is the PEM codes and the
other is ASN.1.

We should not consider any
others.

I don't agree with that, but even if I did, why are you ignoring
"we create our own IANA registry"? That seems to have the
same weight as "we use OIDs and constrain them in this particular
way".

>In the future I would like to see algorithm management
for application layer crypto taken over by SAAG or some other group
and managed across the whole application space. I would like DANE to
be in that pool and not an odd appendage to DNSSEC.

Yes, I want DANE to be on the
applications update schedule and not tied to DNS, TLS or anything
else.

>The other reason for having a little more overhead
here is that an ODR can be used as a totally generic fingerprint.

It is true that an ODR can be used as a totally generic
fingerprint; so can any binary or ASCII representation.

Only if it has the object identifier and
algorithm identifier codes in.

We fully disagree here. Constrained OIDs are no more magic than
an IANA registry.

At the moment, most 'cryptographic
fingerprints' are MD5 hex dumps or they might be SHA-1 but only the
producer knows what they are or what semantics they relate
to.

>Having the semantic tag in the digest makes it secure
against a semantic substitution attack and enables cut n' paste type
use.

How would such a substitution attack on an ODR or other
blob happen without there being a serious degredation of the preimage
strength of the digest algorithm? You claimed otherwise earlier on the
list but didn't justify your argument, and some of us disagreed with
you.

Guarding against this form of attack is
most certainly best practice.

At the moment the chances are that there
will be no issue because the only formats we are likely to use are in
completely different encoding spaces. SAML is in XML, PKIX is in ASN.1
and PGP in something else again.

I think it highly likely that will
continue to be the case and no issue will arise. But there is no way
any of us can predict how key formats are going to evolve and so there
is no way that either of us can guarantee that no problem will arise
in the context of DANE.

I think it is far more likely that
someone will find a way to exploit a semantic attack in the wild than
they will find an attack on SHA2-256. But that does not mean I would
be happy only supporting one digest algorithm.

In the wider context that ODR is designed
to address, the problem quite definitely arises. So the choice is
between a digest format that is a one off for DANE and cannot be
reused or one that maybe has 6 extra bytes that are not absolutely
necessary in DANE.

So, you still have no attack that does not involve a reduced
preimage on the hash algorithm used?

>If the group wants to go this way, I would suggest
that we unhook the ODR component from the CAA draft and make it a
standards track WG document. It is probably best that it be a separate
document as the whole point is to make it a generic construct like
Base64.

>In addition to the binary form, I would add in a URI encoding form
and make the relevant application.

Can you give an example of where the URI encoded form
could be useful?

OK, how about on a web page. Imagine that
we have a web page that is downloaded from a TLS site but the images
are stored on a separate image server that does not have
TLS.

At the moment this is such a common use
case that it is really difficult to get enforcement on because it is
so common. And there is another variation where the data linked to is
not even in the same domain.

Imagine we can create a link of the
form:

Packaging it up as a URI is not strictly
necessary but that is what it is functionally.

One could even have a cache of content
referenced by ODR lookup. So if the content is not locatable, it can
be pulled from cache.

odr="odr:woqi12o3o12hroiqhweoiqhwe==">RFC
6666</a>

I'm sorry, but I'm still completely lost. What do the
certificates in those ODRs do in those examples?

--Paul Hoffman, Director

--VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Dec 2010 21:45:01 +0200

On Mon, Dec 13, 2010 at 08:04:16AM -0800, Paul Hoffman wrote:
> ASN.1 sequence guards against that concatenating the three fields
> themselves doesn't?

The attacks guarded against here seem to be:

- Interpretting something as hash to wrong type of thing. Which I'm not
  convinced is serious problem in this case (DANE) because if the orignal
  is maliscous, all that matters is resistance against invalid input, and
  that is required anyway (and is not our responsibility, except for not
  designing formats that are overly hard to parse).
- Interpretting the value as wrong hash. Which can't happen anyway because
  there are quite a lot of hash functions for pretty much any length and one
  needs to know the hash function to use anyway. 

E.g. you see a 512-bit hash. Is it:

- SHA-512?
- BLAKE-512?
- Grøstl-512?
- JH-512?
- Keccak-512?
- Skein-512-512 (oh, and there's Skein-1024-512 too...)?
- Whirlpool?

None of those is even close of being broken and all have taken fair amount
of cryptoanalysis (5 of those 7 are the SHA-3 finalists).

> The size overhead is small, the programming overhead maybe not so much.

Even variable-length fixed prefixes can be nontrivial (at least comprared to
fixed-length fixed prefixes, especially small-integer).

> What does "authentic" mean in this context?

Presumably means the ODR itself is good (as opposed to bad/maliscous).
Pretty much obvious assumption.
 
> >it provides a strong cryptographic reference to a specific string
> >of bits with a specified semantic interpretation using a specified digest
> > algorithm.
> 
> concatenating the three fields (the first two of which are fixed-length)?
> If so, why?

And I'm not convinced the type field is needed anyway, because it is implicit
from surrounding context unless the whole thing is badly designed. And if it
is impicit, it will just be duplication of information (which is bad).

> and confusion. Many people consider those to be bad features.

There are basically two problems with such extensibility:
- Strange hash functions that use some very obscure identifiers and are very
  hard to find specs of (not a good thing, furthermore, such hash functions
  are quite often weak or at least of questionable quality).
- Identifier duplication (that is just plain bad and only leads to
  interoperability problems, and yes, it really does happen a lot with X.509).

As for the "SHA-3 problem", if you want get up and running fast after SHA-3
is announced, just reserve the codepoints for its variants, specify that
those codepoints will behave like SHA-2 codepoints, but with SHA-3 hash
functions used instead. Then after NIST annouces SHA-3, publish RFC formally
allocating those codepoints (that RFC will be like two pages including
broilerplate text, and most of it will be broilerplate text).

> reuse its registries (which are neither ASCII or OIDs)?

Ah yeah, TLS has HashAlgorithm. Presently it has MD5 (blech!), SHA-1
(hmm...) and SHA-2s (which are OK hash functions, but...).

DNSSEC really has no registry of hash functions, but if one downcasts
those signature-hash pairs into just hashes, it has SHA-1, SHA-256/512
and GOST, which is slightly better...

But on the other hand, it is logical to use TLS registry of hash algorithms
for data to be used with TLS (since you are going to have to support some
of those and have compatible interpretations because otherwise you can
screw up the TLS handshake anyway).

> whole application space. I would like DANE to be in that pool and not an
> odd appendage to DNSSEC.
> 

And SAAG appears to be overkill anyway (assuming I found the right SAAG...)

> >The other reason for having a little more overhead here is that an ODR
> >can be used as a totally generic fingerprint.
> 
> It is true that an ODR can be used as a totally generic fingerprint;
> so can any binary or ASCII representation.

Even ASCII representations are easier than variable-length fixed-prefix
representations (since most languages have at least somewhat decent
string functions).

> >It is something that we can perhaps expect a cryptographic
> >application to emit as a matter of course. I would  like to be able
> >to cut and paste ODRs from one place to another.
> 
> That sounds good.

I would like to see ASCII hexadecimal hashes together with hash function
specifier, like say "sha1:93c6a49361c7537a25ca44f98625d76537ce6b60", for
that.

> argument, and some of us disagreed with you.

As said, semantic interpretations can be app-specific or span applications.

In case of DANE, the only possible semantic attack that is forseeable (and
it isn't likely exploitable anyway because it would seem to require getting
maliscous interpretation out of honest certificate) is confusing diffrent
certifacte types. Any other semantic attack would trivially yield semantic
attack against TLS.

If honesty of originator to themselves can be assumed actually matters.
That's the reason why clients usually don't try to check asymmetric key
crypto except against basic mathematical constraints and just assume the
keys are generated well (there are many ways to totally screw up RSA
or DSA key generation or DSA key usage).

> >If the group wants to go this way, I would suggest that we unhook the
> >ODR component from the CAA draft and make it a standards track WG
> document. It is probably best that it be a separate document as the
> whole point is to make it a generic construct like Base64.
> >

There already is proposal for such form (documented in WHATWG Wiki).
Granted, it doesn't have MIME type for data specified, which opens some
theoretical attacks (that don't seem practical).

Basically the intended purpose of that is to validate downloads against
corruption (non-intentional) and tampering (intentional) when downloading
from other servers.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Dec 2010 23:01:07 +0200

> issue for the KEYASSURE/CERT proposal.

I can't find any way to perform semantic substution attack against 
draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
situations (that don't involve much easier attacks anyway).

BTW: TLS itself can't defend against such attacks, it just relies that
attacker doesn't have such capabilites.

> any application layer design.

Programming complexity. Which is big deal when you are writting this stuff
in C or C++ for practical end applications.

And yes, I'm assuming prefixes are precomputed.

I looked at piece of code I have written that handles ASN.1-encoded hashes.
All I can say is "yuck". I'd much rather deal with small integers (even
if the set has gaps).

> they are going to be unavoidable politically.

I haven't seen any overly bad stuff with DNSSEC (granted, how many
implementations support GOST, but the problem). But I have seen _PLENTY_ of
bad stuff with X.509.

> avoid is having application layer crypto impact DNSSEC.

his is just about how to denote hash algorithms. And what about fairly
reasonable hash algorithms that seeming have no OID?

>     odr="odr:woqi12o3o12hroiqhweoiqhwe==">RFC 6666</a>
 
What does that ODR encode about the semantics in both cases? That the file
is a GIF in above case (what's the OID of GIF?) and that it is text file
(what character set‽; what is say, OID of ASCII text file?).

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 17:53:45 -0500

In response to Paul:

There is absolutely no proposal to have a restricted registry of OIDs. You
keep complaining about people putting words into your mouth and then respond
to a straw man of your own invention.

OIDs are OIDs, there is no proposal to restrict them.

If someone puts something in the OID slot that a relying party can't
understand then the RP is not going to be able to use it.

The appendix that gives the algorithm IDs merely follows a longstanding
practice of specifying the small number of values that will actually be used
in practice and would be specified as MUST. Although it is the intent of the
IETF to use the NIST values for SHA2, some implementations of certain specs
did the idiot thing and defined their own.

There is not a proposal to create any form of registry whatsoever for OIDs,
never was. Please do not put words into my mouth and then argue against
them.

> All I can say is "yuck". I'd much rather deal with small integers (even

I can't quite see where the problem comes in. I have written a full X.509v3
decoder in Javascript. Why would C be an issue?

I can do this in about a screenful of code including the documentation.

> implementations support GOST, but the problem). But I have seen _PLENTY_ of

I am rather concerned about some of the peculiar ways in which X.509 has
been abused. Often times it seems to be that the main design constraint is
to produce something that will bring in repeat consulting work.

Granted nothing bad is likely to happen when competent people are doing
design and implementation. However that is not the real world. We recently
had a huge issue in XML signature space due to people making some very bad
implementation decisions.

> reasonable hash algorithms that seeming have no OID?

Like what?

Any hash alg that is used in practice is going to have at least one OID
defined.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Dec 2010 18:03:40 -0500

> The appendix that gives the algorithm IDs merely follows a longstanding practice of specifying the small number of values that will actually be used in practice and would be specified as MUST. Although it is the intent of the IETF to use the NIST values for SHA2, some implementations of certain specs did the idiot thing and defined their own. 
> 
> There is not a proposal to create any form of registry whatsoever for OIDs, never was. Please do not put words into my mouth and then argue against them.

I'm confused.  If you're going to "specify a small number of values ... as MUST", wouldn't you need a registry to keep track of which values were MUST at a given time?

I guess the benefit of OIDs in that scenario is that you don't have to create registry values for the non-MUSTs, you just use them.  But then again, you could also use an existing registry for this.  For example, are you anticipating usage of algorithms that aren't in the TLS registry [1], or which won't be added later?

--Richard 

[1] <http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-17>

> 
> On Mon, Dec 13, 2010 at 4:01 PM, Ilari Liusvaara <[email-masked]> wrote:
> 
> I can't quite see where the problem comes in. I have written a full X.509v3 decoder in Javascript. Why would C be an issue? 
> 
> I am rather concerned about some of the peculiar ways in which X.509 has been abused. Often times it seems to be that the main design constraint is to produce something that will bring in repeat consulting work. 
> 
> Granted nothing bad is likely to happen when competent people are doing design and implementation. However that is not the real world. We recently had a huge issue in XML signature space due to people making some very bad implementation decisions.
> 
>  
> Any hash alg that is used in practice is going to have at least one OID defined.
> 
> 
> -- 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 15:10:07 -0800

At 5:53 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>In response to Paul:
>
>There is absolutely no proposal to have a restricted registry of OIDs. You keep complaining about people putting words into your mouth and then respond to a straw man of your own invention.

I apologize for having made that assumption. I read the following two posts from you earlier today:

At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>The main reason the CAA draft has the explanation it does is to show that a full ASN.1 packer/depacker is not necessary. Everything can be handled off fixed pre-calculated prefixes for each supported digest algorithm if that is desired.

How can you have unrestricted OIDs and have only ten extra bytes of overhead? Some OIDs are longer than that.

If you are using unrestricted OIDs, what does "fixed pre-calculated prefixes for each supported digest algorithm" mean?

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 18:33:21 -0500

On Mon, Dec 13, 2010 at 6:03 PM, Richard L. Barnes <[email-masked]> wrote:

> > There is not a proposal to create any form of registry whatsoever for
> OIDs, never was. Please do not put words into my mouth and then argue
> against them.
>
> I'm confused.  If you're going to "specify a small number of values ... as
> MUST", wouldn't you need a registry to keep track of which values were MUST
> at a given time?
>

No. IANA registries are not normative

Only standards track RFCs are normative. The registries merely track the
status of the normative RFC text.

> I guess the benefit of OIDs in that scenario is that you don't have to
> create registry values for the non-MUSTs, you just use them.  But then
> again, you could also use an existing registry for this.  For example, are
> you anticipating usage of algorithms that aren't in the TLS registry [1], or
> which won't be added later?
>

I am anticipating use by security applications that are not TLS.

If I have records for IPSEC, TLS and S/MIME, I do not want to have to have
different handling code for each one.

And I certainly don't want to have to track TLS assignments in my IPSEC
code.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 18:44:51 -0500

Assuming that the application is finite, the number of algorithms supported
is going to be finite.

There is no need for any application to know anything about an algorithm it
does not support, other than that it is not supported.

So if the app supports 8 algorithms, a minimal implementation would contain
the 8 prefixes for those algorithms. It would never generate any other
prefix and it would be unable to verify any other prefix. So there would be
no requirement to do anything else.

If you have an application that is built on extensible crypto modules then
you are going to have to write more code anyway if you are going to use
them. But if you are playing that game you are going to have to convert any
identifiers to OIDs in any case.

On Mon, Dec 13, 2010 at 6:10 PM, Paul Hoffman <[email-masked]> wrote:

> >The main reason the CAA draft has the explanation it does is to show that
> a full ASN.1 packer/depacker is not necessary. Everything can be handled off
> How can you have unrestricted OIDs and have only ten extra bytes of
> overhead? Some OIDs are longer than that.
>
> If you are using unrestricted OIDs, what does "fixed pre-calculated
> prefixes for each supported digest algorithm" mean?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Dec 2010 21:43:14 -0500

> All I can say is "yuck". I'd much rather deal with small integers (even

+ a really large number.

ASN.1 handling is notoriously bad and horribly broken -- we should be aiming for simplicity wherever possible, both so that this actually get implemented, and because overly complex code leads to bugs and security issues...

> implementations support GOST, but the problem). But I have seen _PLENTY_ of

Yes (and, some would say that the lack of GOST support is a feature, not a bug :-))

w

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 22:38:45 -0500

On Mon, Dec 13, 2010 at 9:43 PM, Warren Kumari <[email-masked]> wrote:

> >> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman <[email-masked]
> >wrote:
> >>
> ASN.1 handling is notoriously bad and horribly broken -- we should be
> aiming for simplicity wherever possible, both so that this actually get
> implemented, and because overly complex code leads to bugs and security
> issues...

Then how are you going to be able to use the X.509v3 encoded certificates at
all?

> Yes (and, some would say that the lack of GOST support is a feature, not a

The people behind GOST will ensure that they get a code point one way or the
other.

If they get it through an IANA assignment they will claim an IETF
endorsement for their algorithm regardless of merit. Worst case they get an
RFC to boot.

If an IANA assignment is made essential, they will assign one themselves and
tell IANA what number they will be using. That sets a bad precedent in more
than one way.

If the assignment is through ASN.1 OIDs there is no reason that the IETF
need be involved in any way at all unless there is an IETF consensus to
actually support use of GOST.

The best way to control vanity crypto is to make it as easy as possible to
slot it into the spec. Let anyone use any algorithm they like.

If GOST is the only vanity crypto option that has a code point there is a
chance people might think about implementing as a matter of course.
Particularly if there is a registry of algorithms with 2 or 3 defined code
points.

If there is only SHA2 specified as MUST in the doc and no mention of
anything else whatsoever, then implementers are going to have to go to some
effort to cause problems.

The harder you try to make getting a code point, the more significant the
ones that are assigned will be. And trying to be restrictive requires
effort.

Using OIDs means that the code space is effectively infinite, anyone can get
a code point and doing so means nothing at all.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2010 19:57:43 -0800

At 10:38 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>Using OIDs means that the code space is effectively infinite, anyone can get a code point and doing so means nothing at all.

For hash algorithms, isn't "more than 100" effectively infinite? Isn't the bar of "must write a permanently available reference" the minimum anyone would want, except for private use?

You are making it sound like the registry that we have chosen in onerous without presenting any evidence.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Dec 2010 23:25:32 -0500

Well it is certainly a lot more overhead than my proposal.

And where a registry is concerned, that would be my only real consideration.

On Mon, Dec 13, 2010 at 10:57 PM, Paul Hoffman <[email-masked]>wrote:

> >Using OIDs means that the code space is effectively infinite, anyone can
> get a code point and doing so means nothing at all.
>
> For hash algorithms, isn't "more than 100" effectively infinite? Isn't the
> bar of "must write a permanently available reference" the minimum anyone
> would want, except for private use?
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Dec 2010 07:24:08 -0800

>Well it is certainly a lot more overhead than my proposal.

"A lot more"?!?! Be serious.

New hash algorithms are defined once every few years. It takes someone a couple of hours to write and pus through a two-page RFC that says "look here for the formal definition of the algorithm; now give me a number". In your model, you have to do essentially as much work to say "here is the OID that people should use to interoperably specify this hash algorithm". Where is the extra overhead?

As for your "every object that is hashed should have an OID" idea: that's a fine idea that turns out to be just as high overhead in practice. Imagine that it was already an IETF standard, and for DANE we need to come up with a small handful of OIDs for it to put in the draft. How is that any less overhead than us saying "use the integers 1 through 4"?

If this idea had any practical merit, it would have been adopted 15 years ago when OIDs hit the IETF full-force. It's failure should be an indication of its practical value, even though it makes complete sense from a semantics standpoint.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Dec 2010 13:25:46 -0500

Vanity crypto is proposed at least once a week.

My proposal has zero admin overhead for vanity crypto. The only time that
there is an admin overhead is on the rare occasion when an alg is being
considered as a MUST.

Any IANA based registry means that there will be an admin overhead to
respond to requests, even if the answer is 'no'. In fact saying 'no' is more
effort than 'yes'.

On Tue, Dec 14, 2010 at 10:24 AM, Paul Hoffman <[email-masked]>wrote:

> New hash algorithms are defined once every few years. It takes someone a
> couple of hours to write and pus through a two-page RFC that says "look here
> for the formal definition of the algorithm; now give me a number". In your
> model, you have to do essentially as much work to say "here is the OID that
> people should use to interoperably specify this hash algorithm". Where is
> the extra overhead?
>
> As for your "every object that is hashed should have an OID" idea: that's a
> fine idea that turns out to be just as high overhead in practice. Imagine
> that it was already an IETF standard, and for DANE we need to come up with a
> small handful of OIDs for it to put in the draft. How is that any less
> overhead than us saying "use the integers 1 through 4"?
>
> If this idea had any practical merit, it would have been adopted 15 years
> ago when OIDs hit the IETF full-force. It's failure should be an indication
> of its practical value, even though it makes complete sense from a semantics
> standpoint.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Dec 2010 13:29:42 -0500

> of its practical value, even though it makes complete sense from a semantics

Utter nonsense.

If the IETF had had its act together it would have done plenty of things 15
years ago - including DNSSEC.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Dec 2010 10:33:52 -0800

At 1:25 PM -0500 12/14/10, Phillip Hallam-Baker wrote:
>My proposal has zero admin overhead for vanity crypto.

Wow, that's a really great selling point!

>The only time that there is an admin overhead is on the rare occasion when an alg is being considered as a MUST.

And the same is true for using an IANA registry. In fact, if someone who does a vanity hash algorithm wants a code point, they can get it by doing the work themselves.

>Any IANA based registry means that there will be an admin overhead to respond to requests, even if the answer is 'no'. In fact saying 'no' is more effort than 'yes'.

Another baseless grand assertion. If the WG consensus is to use a new IANA registry, we get to write the rules. "Expert reviewer" as a rule means that it takes less effort to say "no" than "yes".

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Dec 2010 14:02:06 -0500

GOST has soaked up at least a thousand hours of people's time.

Under my proposal, that would be zero.

Expert review is not a cost free option, it is a permanent overhead.

On Tue, Dec 14, 2010 at 1:33 PM, Paul Hoffman <[email-masked]> wrote:

> And the same is true for using an IANA registry. In fact, if someone who
> does a vanity hash algorithm wants a code point, they can get it by doing
> the work themselves.
>
> Another baseless grand assertion. If the WG consensus is to use a new IANA
> registry, we get to write the rules. "Expert reviewer" as a rule means that
> it takes less effort to say "no" than "yes".
>
> --Paul Hoffman, Director
> --VPN Consortium
>