Subject: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Jan 2011 15:00:20 -0500

Hello all,

I'd like us to start working through the issues that we have listed in  
the tracker (http://trac.tools.ietf.org/wg/dane/trac/report/1) -- this  
will hopefully allow us to actually come to some consensus and avoid  
having the same set of discussions over and over again...

Matt will be adding additional issues to the tracker but for now can  
we try and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 
  ? Hopefully this will be one of the easier / less controversial  
issues to address, and we can quickly wrap it up and move on...

Please excuse the poor quality of the description -- the issue was  
created from the thread: "Object Digest Reference"  (started here: http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) 
  -- as with many of our threads this went off the rails and didn't  
come to clear consensus.
I'd like us to revisit this and decide on a means of identifying what  
the hash /  cert type are.

W

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

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 15:56:21 +0000

On 5 January 2011 20:00, Warren Kumari <[email-masked]> wrote:
> Matt will be adding additional issues to the tracker but for now can we try
> and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 ?
> Hopefully this will be one of the easier / less controversial issues to
> address, and we can quickly wrap it up and move on...
>
> Please excuse the poor quality of the description -- the issue was created
> from the thread: "Object Digest Reference"  (started here:
> http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- as
> with many of our threads this went off the rails and didn't come to clear
> consensus.
> I'd like us to revisit this and decide on a means of identifying what the
> hash /  cert type are.

It seems to me there's a simplifying decision we can take, namely: our
own registry or someone else's? If we choose our own, then a lot of
pointless debate about which someone else can be avoided.

I vote for our own registry, the reason being that we will have to, in
any case, choose which entries in someone else's are valid, and which
are mandatory. By the time we've specified that we might as well
allocate our own identifiers, too.

Cheers,

Ben.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 06 Jan 2011 11:08:18 -0500

> allocate our own identifiers, too.

I don't think this is a valid argument, in light of Phill's previous
comments on the subject.  Why would we have to choose which entries are
valid, and not just state that any entry representing a hash algorithm
is potentially valid and let each implementation choose which ones to
support?

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 08:11:57 -0800

> allocate our own identifiers, too.

+1

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 08:14:35 -0800

> is potentially valid and let each implementation choose which ones to

If our registry (a) is easy for someone to add to and (b) has plenty of 
private use values pre-allocated, "we" would not have to choose which 
entries are valid. Regardless, implementations would choose which ones 
to support. Someone might make an applicability profile (like has just 
been done in the DNSEXT WG for DNSSEC), and someone else might make a 
different profile.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 16:20:11 +0000

> is potentially valid and let each implementation choose which ones to

Someone has to choose which ones are actually valid - you can't punt
to implementations, because then interop is impossible.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 06 Jan 2011 11:26:52 -0500

> been done in the DNSEXT WG for DNSSEC), and someone else might make a 

Sure.  So:

Benefits of operating our own registry:
- ?

Benefits of reusing another appropriate registry:
- Less work for us and for registrants (though maybe not by much, you
have said)
- We don't have to deal with political issues regarding "vanity crypto"
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html)

As Phill has pointed out
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html),
OIDs are not any harder to use than any other registry because any given
application can just recognize the hard-coded prefixes for the
algorithms it supports.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 06 Jan 2011 11:31:06 -0500

> to implementations, because then interop is impossible.

The mandatory algorithms provide interop.  If some parties wish to use
another algorithm, it is their responsibility to make sure the peer
supports it.

-- 
Matt

---

From: Ben Laurie <[email-masked]>
Date: Thu, 6 Jan 2011 16:35:47 +0000

> another algorithm, it is their responsibility to make sure the peer

This is how you end up with people using CRC-32 as a cryptographic
hash. I don't think it is acceptable to burden developers with such
decisions.

I do agree that a route needs to be provided for those who want to do
their own thing, though. But it must be clear that they're doing their
own thing.

Unless there's a registry which has appropriate policies around
strength already in existence, that means its our problem to define
what is OK to use and what is not.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 08:37:02 -0800

> Benefits of operating our own registry:

- Developers know how to interoperate with each other when they are 
using the same hash algorithm

- When a developer sees a record with a value for the hash algorithm 
that they don't know, that developer can quickly determine if he cares 
enough to update his implementation.

> - Less work for us and for registrants (though maybe not by much, you

True.

> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html)

False: we are just exporting the problem to whomever is running the 
registry we are using.

That is, I have no problem with using someone else's registry, but the 
overhead of creating our own (Jakob and I spend 10 minutes writing an 
IANA Considerations section) is probably worth the benefit of us being 
sure that it contains what we want for first developers.

> application can just recognize the hard-coded prefixes for the

"hard-coded prefixes" means "our own registry", by definition. We gain 
nothing by using OIDs other than bytes of overhead plus forcing 
developers to understand their encoding.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 06 Jan 2011 12:39:16 -0500

> using the same hash algorithm

What do you mean?  A hash algorithm is just a mathematical function, no
matter where it is defined.  It's not as if anything extra has to be
specified in order to use it with DANE.

> enough to update his implementation.

See below (*)

> False: we are just exporting the problem to whomever is running the 

Indeed.  I said "we" meaning the DANE group.

> IANA Considerations section)

Be sure to count maintenance over time.

> is probably worth the benefit of us being 

(*) You are proposing that the registry constitute implicit advice about
what algorithms developers should consider implementing beyond the
mandatory ones.  Alternatively, we could use a wide-open registry and
give such advice elsewhere, or not give advice at all.  Assuming we give
advice, I prefer the separation of purposes in the second approach, but
it may still lead to vanity crypto trouble, in which case the advantage
over operating our own registry would be lost.

> "hard-coded prefixes" means "our own registry", by definition.

How so?  Anyone can calculate the prefix for an OID without our
involvement.

> We gain nothing by using OIDs

Assuming we want a completely open registry, the OID registry is a
popular one in which organizations can get their own subtrees (e.g., my
university has one) and then allocate globally unique identifiers.

> other than bytes of overhead

It comes to about 20 bytes per record, and that will go down if full
compression of DNS responses is ever implemented.  I think it's a small
price to pay for the elegance, but this is subjective.

> plus forcing developers to understand their encoding.

Not really, whoever advocates the use of a given algorithm with DANE
will publish all the information the developers need.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 10:00:05 -0800

> specified in order to use it with DANE.

Registries are for identifiers. How do you know that "17" means "SHA-1" 
and not "SHA-256"? You look it up in a registry.

> Be sure to count maintenance over time.

Ummm, how much maintenance do you think is needed for a registry? 
Someone proposes a new hash algorithm, we say "yes, here's your number", 
and don.

> mandatory ones.

No, I am *not*. Please don't put words in my mouth. I never said that.

> Alternatively, we could use a wide-open registry

Alternatively, we could (as I proposed earlier) use a registry with easy 
but not trivial registration and a bunch of pre-defined private use values.

> and
> give such advice elsewhere, or not give advice at all.

Fully agree.

> Assuming we give

Fully agree about the "advice elsewhere", but am open to what others 
might want. Different WGs in the IETF are wildly inconsistent on this.

What is "vanity crypto trouble"? Someone registers their vanity crypto 
algorithm in our registry: what is the problem?

> How so?  Anyone can calculate the prefix for an OID without our

You do want interoperability, yes? If so, how would what you just 
proposed work?

> university has one) and then allocate globally unique identifiers.

...and no one knows how to interoperate. Well, they will know because 
someone will make a registry-like system that says which OIDs means 
what, and now we have the worst of both worlds.

> price to pay for the elegance, but this is subjective.

Quite. You seem to think that the problems that we have had in the PKIX 
world with muffed OIDs is worth the "elegance"; I disagree.

> will publish all the information the developers need.

And all the developers will be able to understand the OID encoding rules 
given with no errors, of course.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Jan 2011 20:05:46 -0500

Working Groups have a limited lifespan. Which has created no end of
problem in the security area as we have groups whose primary reason
for continuing at the moment is maintaining the set of algorithms.

That type of maintenance is not something that IETF process was
designed to support and is not cost free. Because a WG that is open
for maintenance of algorithms tends to find other reasons for keeping
itself busy.

We already have S/MIME, TLS, IPSEC, DNSSEC and PKIX, choosing
algorithms. But its the same people making the choices on the basis of
the same set of criteria. And at the end of the day that particular
set of protocols really form a single family and should really be
using a common set of algorithms.

As far as interoperability is concerned, I think it is very simple:
the group mandates an initial MUST support algorithm and later RFCs
may update that requirement across the whole family of protocols.

If people want to use something that is not the mandated algorithm of
an IETF consensus successor (as I expect SHA3 will prove) then they
have to expect to pay the price of losing interoperability. But the
people who do vanity crypto know all about that from the start. That
is their own funeral.

The problem with vanity crypto is the implicit endorsement that comes
from being assigned a code point, not the possible lack of
interoperability. As people will have observed on the IETF mailing
list, some people make the strangest claims on the basis of what
appears in published RFCs.

Apart from the representatives of the government behind it, there is
not one single person who has come to me and said that they are really
keen to implement GHOST. I have however had people tell me that GHOST
is an IETF sanctioned and endorsed algorithm on the basis of the
assignment of a DNSSEC code point.

So the ODI/ODR scheme is quite explicitly and deliberately designed to
deny that type of implicit endorsement. If people want to use any
algorithm other than the standard set of algorithms they are on notice
that they are on their own with regards to both interoperability and
quality of the algorithm.

PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. I
would like to see DNSSEC and TLS eventually take the same approach to
specify non-mandatory algorithm suites.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 17:28:32 -0800

> for continuing at the moment is maintaining the set of algorithms.

This doesn't match my experience. Can you name even one WG that has that 
as a primary reason for existing? For that matter, can you name one 
whose last charter was that?

> designed to support and is not cost free.

Correct. That's why we don't do it.

> Because a WG that is open

Fully agree. That's why we don't do it.

> algorithms.

S/MINE is close. TLS hasn't done any algorithm choosing in a while; nor 
has IPsecME. DNSSEC just went through an unfortunate round of that while 
they did other work. PKIX hasn't done that in a while (although they are 
not doing anything I consider all that useful...).

> But its the same people making the choices on the basis of
> the same set of criteria.

If that were only true. Unfortunately, it is not.

> And at the end of the day that particular

But the IETF has refused to do that for over a decade, unfortunately.

> may update that requirement across the whole family of protocols.

Sounds good to me.

> have to expect to pay the price of losing interoperability.

Correct.

> But the

Correct (except if you are GOST...)

> appears in published RFCs.

They can make such claims without us. You are calling for a highly 
restricted registry that requires IETF consensus to change. This argues 
against your earlier point of the cost of doing reviews.

> assignment of a DNSSEC code point.

You probably meant "GOST" there, the Russian crypto standard. And I have 
heard from multiple vendors who want to implement GOST so that they can 
sell to the Russian market. Some are even keen to implement SEED for 
similar reasons in South Korea. And so on. The fact that they have not 
come to you to say this is somewhat off-topic.

> quality of the algorithm.

If the WG wants such restrictions, we don't need OIDs: we can just make 
entry to the registry as restrictive as we want. I propose liberalness 
so that it wastes less time arguing, but others like restrictiveness.

> specify non-mandatory algorithm suites.

Noted (although I have not seen your proposals to those WGs to do so).

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Jan 2011 21:49:42 -0500 (EST)

On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote:

> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers.

DANE should be usable for people without PKIX or ASN.1. If we get a TLS
scheme for "bare public key" then we can't use OIDs for hash references.

I'm in favour of our own registry, re-using where possible the same algo
numbers as in other dnssec registries.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 06:52:28 -0500

ODI already describes a bare key mechanism in the CAA draft.

We have not got a code point assigned yet, but I have asked the ADs about it.

I am somewhat surprised that we settled on this issue to discuss first
since it affects the whole security area.

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Jan 2011 11:16:35 -0500 (EST)

> ODI already describes a bare key mechanism in the CAA draft.

CAA is about PKIX, Dane is not exlusively PKIX.

I like my IANA registries as technology agnostic as possible, and definitely not
drag in ASN.1 for technologies that are not PKIX based.

It is certainly in line with the other DNS(SEC) related IANA registries to use
simple octet based algorithm and type definitions.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 7 Jan 2011 19:15:40 +0100

+1

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 13:19:59 -0500

The ODI spec is not tied to PKIX at all. It is expressly intended to
be totally generic. An ODI could reference a HTML document or a MIME
package.

Unless of course you know something about ODI that I do not.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Jan 2011 18:04:48 -0500

[ Resending, my mail server et the first one ]

> since it affects the whole security area.

I'm sorry, but I disagree with you here. I assume we all agree that  
folk need to be able to tell what algorithm was used to generate  
0x1234ABCD....212 ?

How does it "affect the whole security area" if we decide "We'll ask  
the IANA to please keep track of the fact that 17 means AlgorithmX" or  
"We'll choose which Smurf looks most like the algorithm in question  
and use the ROT13 encoded version of his name to identify it"?

As long as there are a base set of algorithms that implementations are  
expected to implement (and a means to get new algorithms added and old  
ones retired) and way to uniquely identify them, I fail to see how  
what the identifier is is such a big issue....

W

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Life is a concentration camp.  You're stuck here and there's no way  
out and you can only rage impotently against your persecutors.
                 -- Woody Allen

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Jan 2011 18:12:27 -0500

[  Top posting intentional -- this is a meta point and not a response  
to Paul Wouters' mail. ]
[ Resending, mail-server fun -- I've been passing outbound mail though  
SpamAssassin and spamd has started dying on messages with an (as yet  
unidentified) set of strings... ]

So far it looks to me like the group is leaning towards us having our  
own registry (and using simple ordinals from the registry to identify  
the hash / cert / algorithm), but I'd like to A: hear a few more  
voices and B: wait for Ondrej to be back.

If possible I'd like us to try and separate the discussions of "Who  
gets / how to get an identifier for an algorithm" from the question of  
how we actually identify these -- while I realize that there are  
interdependencies in the two issues and they are not fully separable,  
I'd appreciate it if we can try and separate them as much as possible  
so that it is easier to call consensus....

I'd also like to thank everyone who has contributed and to thank folk  
for staying on topic -- I know how tempting it is to go off on a  
tangent so thanks for staying focused and clearly stating preferences.

W

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny  
saved is a penny earned--"
-- Terry Pratchett

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 07 Jan 2011 15:38:04 -0800

On 1/7/11 3:12 PM, Warren Kumari wrote:

> If possible I'd like us to try and separate the discussions of "Who gets
> / how to get an identifier for an algorithm" from the question of how we
> actually identify these -- while I realize that there are
> I'd appreciate it if we can try and separate them as much as possible so
> that it is easier to call consensus....

Just to be clear, my preferences are:

- Somewhat liberal policy for assigning: "RFC published", not "IETF 
consensus" or "expert review"

- two-byte integers for identifying, with 1000 reserved for private use

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Jan 2011 20:18:30 -0500

Awesome, thanks for the clarity...

W

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

On Jan 7, 2011, at 6:38 PM, Paul Hoffman <[email-masked]> wrote:

> - Somewhat liberal policy for assigning: "RFC published", not "IETF consensus" or "expert review"
>

---

From: John Gilmore <[email-masked]>
Date: Fri, 07 Jan 2011 19:23:22 -0800

Let's be sure I understand the issue before jumping in.

Some people want to use a small numerical value, such as one octet, to
designate which hash or crypto algorithm is in use in a DNS record.
For example, the DNSKEY record contains a 1-octet "algorithm" field,
defined in RFC 4034.  The field's initial definition was in the RFC,
Appendix A.1, and subsequent assignments are done by IANA.  There are
reserved values for subsequent extension of the protocol by IETF, for
private extensions, and values reserved for the indefinite future.

Other people want to use an ASN.1 "OID" (or "ODR"), which is a
multibyte sequence of arbitrary length, each subsequence of which
defines a code point for allocating sub-code-points.  Sort of like a
domain name system for naming things in binary.  For example, (someone
come up with a field in an existing approved Standards Track RFC,
please).  This field would be restricted to have a known prefix of a
number of fixed byte values (specified in its RFC), and a set of known
suffixes, which are fixed byte strings, each of which would represent
an algorithm.  The organization identified by the initial prefix would
have the power to define additional suffixes that identify additional
algorithms, without amendment of the RFC and without further action
by IETF.

Is that really the issue?  If not, please edit and repost similar text
to provide a succinct 2-paragraph description of the issue.

	John Gilmore

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 09:07:42 -0500

Since this is precisely the type of change that KEYPROV was required
to make during IESG review, I would have to disagree.

We had specified our own password string prep, we were told we had to
use the existing string prep from another spec.

>From a process point of view I think that the chances of being told to
move from ASN.1 to a custom registry are essentially 0% while the
chance of being told to move from a custom registry to ASN.1 is
approximately 50:50%

Proliferating crypto registries imposes a cost on the whole
organization. It is making busy-work that is not necessary.

The point of working in the IETF as opposed to doing a roll your own
standards organization is meant to be building on the work of others.
ODI is designed to be a re-usable building block that can be used in
other places. It builds on ASN.1 which is itself a frequently used
building block that is essentially a standard in the crypto world.

So far I have given concrete benefits for my design choices. In
contrast the opposition has been 'well I prefer' without giving actual
benefits. The nearest we got was Paul's rather silly claim that ODI is
difficult to code (false) and the vague idea that having a registry
puts you in control.

On Fri, Jan 7, 2011 at 6:04 PM, Warren Kumari <[email-masked]> wrote:
> I'm sorry, but I disagree with you here. I assume we all agree that folk
> need to be able to tell what algorithm was used to generate
> 0x1234ABCD....212 ?
>
> How does it "affect the whole security area" if we decide "We'll ask the
> IANA to please keep track of the fact that 17 means AlgorithmX" or "We'll
> choose which Smurf looks most like the algorithm in question and use the
> ROT13 encoded version of his name to identify it"?
>
> expected to implement (and a means to get new algorithms added and old ones
> retired) and way to uniquely identify them, I fail to see how what the
> identifier is is such a big issue....
>
> W
>
>
>>
>>
> Life is a concentration camp.  You're stuck here and there's no way out and
> you can only rage impotently against your persecutors.
>                -- Woody Allen
>
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 09:34:30 -0500

On Fri, Jan 7, 2011 at 6:12 PM, Warren Kumari <[email-masked]> wrote:

> If possible I'd like us to try and separate the discussions of "Who gets /
> how to get an identifier for an algorithm" from the question of how we
> actually identify these -- while I realize that there are interdependencies
> in the two issues and they are not fully separable, I'd appreciate it if we
> can try and separate them as much as possible so that it is easier to call
> consensus....

The technical impact of this choice is

1) Whether the identifier is 1 or 2 bytes or an average of about 8.
2) Whether the identifier space can be exhausted or not
3) What are the criteria for gating access to the registry.

I don't think that the shaving of a few bytes here is relevant. If we
go for 1 byte it is very likely we end up with an exhaustion issue
down the line.

If we go for a self-describing length scheme we endup with something
that looks like ASN.1

If people want we could have a hybrid scheme in which we asked IANA to
establish a registry of the ASN.1 identifiers for the mandatory to
implement and preferred algorithms for use.

This registry would then ideally have two initial entries as followed

SHA2 256bits  MANDATORY ...
SHA2 512bits  MANDATORY ...

Anyone who wants to use vanity crypto simply uses their own code
point. It is possible to use any algorithm people like in private
between consenting adults. But the registry only has to track the ones
that are either mentioned in a spec or have been added because there
is a consensus they should be supported.

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 08 Jan 2011 09:34:55 -0500

> organization. It is making busy-work that is not necessary.

I agree.

> other places.

Right, but it is a /new/ re-usable building block.  Reusing the DNSSEC
registry would be a more conservative choice than inventing ODI and
would still achieve the goal of not proliferating crypto registries.
There is a trade-off.

> benefits.

In order to verify this kind of claim, I have to dig back through the
mail and assess whether the benefits claimed for the alternative
solution are "actual", etc., and possibly miss something.  This is
frustrating and leads to discussions that go around in circles.  Could
we perhaps maintain a list of benefits for each solution in one place on
the wiki?  (I am having trouble with loginmgr though; I contacted
[email-masked] on Wednesday and haven't heard back yet.)

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 09:41:13 -0500

> would still achieve the goal of not proliferating crypto registries.

The problem with attempting to re-use the DNSSEC registries is that
the DNSEXT people presumably chose to have their own registry so as to
have control themselves.

What happens if we want to use an algorithm and they do not?

What happens if they add a code point for an algorithm that we do not want?

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 08 Jan 2011 09:46:10 -0500

> 1) Whether the identifier is 1 or 2 bytes or an average of about 8.

No, it's more than 8; for example, here is the 20-byte prefix for a "CA
certificate" with SHA-256:

30 12 06 03 55 04 25 06 09 60 86 48 01 65 03 04 02 01 04 20

> go for 1 byte it is very likely we end up with an exhaustion issue

I don't think so.  Are hash algorithms really being invented at such a
rate that over the likely lifespan of DANE (is 30 years a safe high
estimate?) more than 200 or so algorithms would be registered?  There
are only 10 entries in the DNSSEC registry so far.  On the other hand,
using OIDs lets us do slick things like let organizations assign their
own globally unique algorithm IDs.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 08 Jan 2011 09:51:55 -0500

> the DNSEXT people presumably chose to have their own registry so as to

I wouldn't presume that.  We would have to look back through their
discussion.  They may have just thought that the use of one-byte values
was more in keeping with the design of DNS.

Even so, if we determine that our goals are the same as theirs (as I
would guess), there is no issue.

> What happens if we want to use an algorithm and they do not?

That would be problematic.

> What happens if they add a code point for an algorithm that we do not want?

We just publish advice for people not to use it.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 10:00:33 -0500

> certificate" with SHA-256:

ODI has two identifiers in it. The algorithm ones are from the NIST
arc so are the shorter ones.

We do need to have a mechanism to identify both parts.

> own globally unique algorithm IDs.

We need to have a different identifier for each strength. So we have
six slots taken by SHA2 and the expected SHA3 for a start. There are
currently 5 finalists, that would be 18 identifiers used if we did
them all.

The risk of exhaustion may not be very high, but fixed length fields
make many of us nervous.

I expect to be around in 30 years time. I don't expect there will have
been major changes to IP or HTTP in that time. I have been writing
HTTP code 19 years now and that has not changed.

My personal design horizon for protocols is never less than a
millennia, Having had to deal with other people's short sightedness I
would argue against a design horizon of less than 200 years.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 08 Jan 2011 08:07:53 -0800

> to provide a succinct 2-paragraph description of the issue.

You have intertwined the issues, as have others. Warren asked us to 
detwine them, which I think is good. Using your text above, one issue is 
"format is small numerical value or ASN.1 OID". The second issue is "who 
gets to put other values into the specified format, and with what 
difficulty". Hope this helps.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 08 Jan 2011 08:18:45 -0800

> use the existing string prep from another spec.

The "precisely" in the first paragraph completely disagrees with the 
second paragraph. The format of the identifier is completely dissimilar 
from a modification of a difficult internationalization process.

> chance of being told to move from a custom registry to ASN.1 is

That's fine for you to predict, but I predict differently. I think if we 
choose either a short numeric identifier (as is already used in most DNS 
protocols) or an OID (as is already used in PKIX and S/MIME), the IESG 
will be fine.

> organization. It is making busy-work that is not necessary.

And yet IETF WGs do it on a regular basis, with the full approval of the 
IESG.

> building block that is essentially a standard in the crypto world.

...and yet your ODI proposal, which you brought to many WGs, has 
garnered almost no support.

> contrast the opposition has been 'well I prefer' without giving actual

The fact that you don't like the actual benefits that we have listed 
repeatedly doesn't mean we didn't give them.

> The nearest we got was Paul's rather silly claim that ODI is

That is not a vague idea: it is one that is embraced by virtually every 
WG in the IETF. Further, the idea of "I know how to encode a two-octet 
integer" is easy to understand. The fact that they are shorter is a 
benefit, even though a small one.

As for the negatives on OIDs, your description of how to encode ODIs is, 
so far, incomplete (hint: large integers), so even you can't say how 
easy or hard it is.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 11:37:18 -0500

On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]> wrote:

> The "precisely" in the first paragraph completely disagrees with the second
> paragraph. The format of the identifier is completely dissimilar from a
> modification of a difficult internationalization process.

No, it was a change the WG debated at considerable length when there was no
need to as it was not a decision it should have made.

> protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will
> be fine.

We also had a draft written by the current IETF chair and one of the IETF
Security Area directors that converted all our XML formats into ASN.1. The
other Security AD told us to add it as a WG item.

Have you any idea how much the security area likes ASN.1?

Here you are interfacing to PKIX which is an ASN.1 spec.

> As for the negatives on OIDs, your description of how to encode ODIs is, so
> far, incomplete (hint: large integers), so even you can't say how easy or
> hard it is.
>
>
Another difference is that when I make a technical point I make a technical
point rather than asking people to play guessing games.

If you have a point then make your point.

Hint: You don't exactly have the standing in the field to be condescending
towards others.

As it is you seem to be criticizing me for not explaining how to handle an
edge case that could not possibly occur unless our entire understanding of
crypto suddenly changed.

[Since the output of all currently used digest algorithms is fixed, an
implementation that supports a fixed number of digest algorithms is not
going to require any length greater than 127 bytes and thus the large
integer issue would never occur.

Furthermore, unless there are unexpected developments in computing we really
should not be expecting to use digests of more than 256 bits. And in the
unlikely event that we did people can read the full ASN.1 documentation that
explains exactly what to do.]

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 08 Jan 2011 09:35:19 -0800

On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     second paragraph. The format of the identifier is completely
>     dissimilar from a modification of a difficult internationalization
>     process.
>
>
> No, it was a change the WG debated at considerable length when there was
> no need to as it was not a decision it should have made.

Then you should blame the WG chairs (you were one of them).

>     That's fine for you to predict, but I predict differently. I think
>     if we choose either a short numeric identifier (as is already used
>     in most DNS protocols) or an OID (as is already used in PKIX and
>     S/MIME), the IESG will be fine.
>
>
> We also had a draft written by the current IETF chair and one of the
> IETF Security Area directors that converted all our XML formats into
> ASN.1. The other Security AD told us to add it as a WG item.

Correct. If this WG was considering having our algorithm identifiers as 
XML structures, we might have the same. Fortunately, we don't.

> Have you any idea how much the security area likes ASN.1?

Having written a handful of Security Area RFCs that use ASN.1: yes, I do.

> Here you are interfacing to PKIX which is an ASN.1 spec.

So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in 
a similar fashion, and neither are in ASN.1 format. To the best of my 
knowledge, no one ever suggested that they should be.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 8 Jan 2011 14:04:59 -0500

<chair hat>
Boys! Please...
</chair hat>

<no hat>
Ok, so I'm proposing a compromise here as a third option. As this is a  
compromise, I'm assuming no-one will love it, but maybe folk will be  
willing to accept it...

We ask the IANA to create us a registry (I'm proposing 2 octet  
codespace, with some portion chopped out for experimental values --  
this gives us >65k usable values (and I don't want to live in a world  
where we approach that :-P), but that's just a thought). ODI can be  
assigned a value from this space, and once / if everyone discovers  
that they like it, folk will no longer bother trying to get  
assignments from our registry, which would remove the "registering new  
values" burden from the IANA.

The obvious downsides are:
1: If ODI becomes the standard that everyone converges on,  we will  
have burnt 16 bits for nothing.
2: In instances where ODI is used the "payload" will not be in the  
same place in the structure. Implementations that do not support ODI  
obviously just treat these as they would any other case where they do  
not understand the identified algorithm / registered value....

The parsing for this is simple (in c-ish psudocode):
switch (dane_struct->codepoint) {
   case  CP_SHA_256:
       handle_sha256(dane_struct);
       break;
   case CP_SHA_512:
       handle_sha512(dane_struct);
       break;
#ifdef HAVE_ODI
   case_CP_ODI:
       handle_odi(dane_struct);
       break;
#endif
   case default:
       debug("Not yet supported algorithm number: ", dane_struct- 
 >codepoint);
       break;
}

To my mind, these downsides are minor... Thoughts?

W
</no hat>

On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:

> Correct. If this WG was considering having our algorithm identifiers  
> as XML structures, we might have the same. Fortunately, we don't.
>
> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with  
> PKIX in a similar fashion, and neither are in ASN.1 format. To the  
> best of my knowledge, no one ever suggested that they should be.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 08 Jan 2011 11:13:28 -0800

> compromise, I'm assuming no-one will love it, but maybe folk will be

If that's the way you think the consensus is going, that's fine. I 
didn't see it going that way. Phill had one proposal with (possibly one) 
person behind it. I had another with a small handful behind it. Others 
had not weighed in yet.

Of the now three proposals for the format, I still feel that "a 
two-octet number" is better than ODI or a mixture of the two, FWIW.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jan 2011 14:40:05 -0500

OK if that is your proposal, I will take the code point 30 12 for an ODI
reference minus the initial ASN.1 SEQ identifier (30 12).

On Sat, Jan 8, 2011 at 2:04 PM, Warren Kumari <[email-masked]> wrote:

> compromise, I'm assuming no-one will love it, but maybe folk will be willing
> to accept it...
>
> We ask the IANA to create us a registry (I'm proposing 2 octet codespace,
> with some portion chopped out for experimental values -- this gives us >65k
> usable values (and I don't want to live in a world where we approach that
> :-P), but that's just a thought). ODI can be assigned a value from this
> space, and once / if everyone discovers that they like it, folk will no
> longer bother trying to get assignments from our registry, which would
> remove the "registering new values" burden from the IANA.
>
>
> 1: If ODI becomes the standard that everyone converges on,  we will have
> burnt 16 bits for nothing.
> 2: In instances where ODI is used the "payload" will not be in the same
> place in the structure. Implementations that do not support ODI obviously
> just treat these as they would any other case where they do not understand
> the identified algorithm / registered value....
>
>      debug("Not yet supported algorithm number: ", dane_struct->codepoint);
>      break;
> }
>
>
>> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in a
>> similar fashion, and neither are in ASN.1 format. To the best of my

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Jan 2011 23:23:50 -0500 (EST)

> the DNSEXT people presumably chose to have their own registry so as to

Is that really the reason?

> What happens if we want to use an algorithm and they do not?

Who is "we" and who is "they"?

DANE is about validating crypto identities via DNS? That means "we" are "they".

If I take all the SHA1 and SHA2 and SHA3 candidates, we end up with
what? 25 hashing algorithms in 25 years? So one byte would give us
about 200 years?

Add a few new container formats (eg bare public key, and some x.509 v4+ or
something) and I still don't see this hitting 256. Though I guess one more
byte to be super safe would not hurt either.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Jan 2011 23:38:21 -0500 (EST)

> Here you are interfacing to PKIX which is an ASN.1 spec.

Not only. Once bare public key TLS support is there, things could move
towards a full drop of ASN.1/PKIX.

In fact, one could argue one of the reasons we need DANE is to fix
limitations in PKIX, and the DANE spec is more then happy to provide
side benefits to the PKIX community to help address those limitations,
but DANE is clearly not a subset of PKIX protocols.

> And in the
> unlikely event that we did people can read the full ASN.1 documentation that explains exactly what to do.]

Problems, not solutions, start with the phrase "read the full ASN.1 documentation".

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 9 Jan 2011 00:06:16 -0500

Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the
packaging format.

So it really is unavoidable.

You can fake it of course (most people do in fact) but that is exactly what
I suggested for ODI

If we adopt Warren's suggestion then we only need one byte since we can
always use ODIs if the registry is exhausted.

Having seen the mess caused by the decision to use 4 byte IP addresses, I am
not keen to see a repeat. And contrary to what some may claim there were
several people who pointed out that 4 billion addresses was too small at the
time the decision was taken.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 9 Jan 2011 22:19:16 +0200

> So it really is unavoidable.

I agree that it is _currently_ unavoidable, but I don't agree that it is
_fundamental_ requirement of TLS. 

I.e. it may be avoidable in future (even without a new TLS version)!

Based on my reading of relevant RFCs:

The only reason (partial) ASN.1 decoding is _currently_ unavoidable for a
TLS v1.2 client is lack of ASN.1-free raw key format[*].

Define a ASN.1-free raw key format, get codepoint for it (IETF consensus)
and this goes away.

Bonus points for new SignatureAlgorithm that is ASN.1-free RSA (specification
required). The existing RSA there is PKCS#1 v1.5 anyway...

[*] You hit PKCS#1 signature verification in implementing OpenPGP (to handle
the case where primary key is RSA).

-Ilari

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Jan 2011 03:29:57 +0100 (MET)

> - two-byte integers for identifying, with 1000 reserved for private use

My preference would also be a fixed size integer.

Is there a problem for a registry to contain more than a
primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather
something like (IntegerValue,AlgorithmName,StandardizationLevel)
with StandardizationLevel values such as
{ required, recommended, optional, experimental, discouraged }

The problem with ASN.1 OIDs is that they wasteful (in terms of code, storage
network bandwidth, cpu cycles), variable-sized blobs and therefore a royal
PITA to use in software.

I strongly prefer

   switch(algorithm_cp) {
      case A: /* code for A */
              break;
      case B: /* code for B */
              break;
      case C: /* code for C */
              break;
      default: /* produce some useful error msg about unsupported alg */
              break;
   }

to 
   if ( 0==compare_OID(parsed_oid,A_oid) ) {
      /* code for A */
   } else if ( 0==compare_OID(parsed_oid,B_oid) ) {
      /* code for B */
   } else if ( 0==compare_OID(parsed_oid,C_oid) ) {
      /* code for C */
   } else {
      /* produce some useful error msg about unsupported alg */
   }

ASN.1 OIDs in PKIX are a pain, and they're ambiguous.

e.g. for RSA there seem to be two(!) OIDs in use in X.509,
something which is not going to happen with a single registry:

    2.5.8.1.1
    1.2.840.113549.1.1.1

Finding out the meaning of an OID you do _not_ happen to know
is far from trivial, something that will not happen with a registry.

The difficulty with OIDs (or other complex variable sized objects)
is not in sending/emitting them, but in receiving/parsing them.
The code to produce a meaningful error message for an unrecognized
value is trivial for a scalar integer value and complex for an OID
(to produce an error message that can be copy&pasted into google).

> So it really is unavoidable.

This information appears outdated.  The PKCS#1 v1.5 signature scheme
was actually tightened up in PKCS#1 v2.1 to completely obviate
the royal PITA part of ASN.1, the _parsing_: 

  http://tools.ietf.org/html/rfc3447#section-9.2

And an implementation is likely to not even attempt to decrypt
the PKCS#1 signature blob if it does not recognize the RSA-based
signature AlgID accompanying it...

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Jan 2011 07:01:31 +0200

> My preference would also be a fixed size integer.

Same (1 or 2 octets). 

The reason for this is that with 2 octets, one gets 65536 entry array
if one lays it out in full. Too large for embedded code, but any general
purpose computer has an OS capable of demand paging. And in environment
like that, the resources used by full table are penuts (and it is very
easy to program).

> { required, recommended, optional, experimental, discouraged }

Aren't registeries usually like that?

>       default: /* produce some useful error msg about unsupported alg */
 
Or even:

#define MAXHASHOUTPUT 256

struct hash_algo* dane_hashes[65536];

int h;
struct hash_algo* H;
unsigned char hashbuffer[MAXHASHOUTPUT];

h = p[2] * 256 + p[3];
H = dane_hashes[h];
if(!H)
	return -1;

H->hash(hashbuffer, data, datalen);
return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1;

> something which is not going to happen with a single registry:

What, only two? :-)

Yeah. Aliases. Brings nothing useful... Only interop problems.

> (to produce an error message that can be copy&pasted into google).

Oh, and don't forget the NULL vs. empty parameters problem. Wonder
how much code gets that wrong... Probably LOTS.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jan 2011 09:21:46 -0500

I am pretty sure that the X.500 OID and the RSADSI OID are actually for
different packaging formats.

When the X.500 directory was specified the OID did not specify the PKCS#1
bit packaging. That was specified later when Dorothy Denning pointed out
that there are security implications to the packaging format.

These should have different identifiers since they are actually different
algorithms and cannot be substituted. Later on Rogaway and Bellare came out
with important work.

RSADSI have actually assigned 6 different code points for different versions
of RSA over the years. And the differences actually matter quite a bit.

I cannot understand what you would need that 64K array for either

Crypto APIs already have code for managing OIDs. You are really not helping
anyone here. All you are doing is ensuring that the application has to be
revised to use a new algorithm rather than allowing the crypto library to
announce that it is available.

What I care about here is that people can take an ODI from another context
and cut and paste it into this use without it causing problems.

That will work perfectly provided I have the code point 0x30 or 0x30 0x12
reserved for ODI.

If people want to have additional codes for shortcuts for the mandatory
algorithms then I really don't have a problem with that. If all we are going
to do is to track the mandatory algorithms with the registry then a single
byte code will be adequate. If we do run out then people will have to use
the ODI scheme for mandatory algs as well.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 13 Jan 2011 21:22:06 -0800

Is there any reason to worry about any of the parameterized hash functions
such as the randomized hash function proposal presented at the SAAG meeting
in SFO?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> Sent: Saturday, January 08, 2011 11:13 AM
> To: [email-masked]
> Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --
> "Identification of hash and cert types."
> 
> If that's the way you think the consensus is going, that's fine. I didn't
see it
> going that way. Phill had one proposal with (possibly one) person behind
it. I
> had another with a small handful behind it. Others had not weighed in yet.
> 
> Of the now three proposals for the format, I still feel that "a two-octet
number"
> is better than ODI or a mixture of the two, FWIW.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 14 Jan 2011 09:02:51 +0200

> such as the randomized hash function proposal presented at the SAAG meeting

I think those can be handled by defining the "hashes" to include the
parameters in hash-function specific way.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Jan 2011 07:19:23 -0800

> parameters in hash-function specific way.

+1. Any parameterized hash function needs to be able to say where those 
parameters go in the the outside protocol. For example, they could be 
stuffed at the beginning or end of the hash value here.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Jan 2011 17:49:09 -0500

Ok, after discussions with my cochair, we are calling consensus.

WG consensus is that we will ask the IANA to create and maintain a  
(one octet) registry to identify the hash and cert types.
This does still allow for the registration and use of things like ODI  
(and parameterized hash functions, and other cool things) by allowing  
them to
specify how the "body" ("bytes containing the certificate or the hash  
of the associated certificate") is interpreted.

I would like to thank everyone who contributed to getting consensus on  
this issue-- don't for a minute think that you are off the hook now  
though, there are many more issues to work through :-P

W