Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

From: Martin Rex <[email-masked]>
Date: Tue, 1 Mar 2011 19:15:56 +0100 (MET)

Phillip Hallam-Baker wrote:
> 
> Currently, the only digest algorithm that can be recommended is SHA-2
> 
> We really do need SHA2 in here as a MUST, unless we are still discussing
> this when the SHA3 competition results are out.

SHA-256 looks like plenty.

You do realize, that many (if not most) implementations of TLS are going
to use SHA-1 for digital signatures for quite some time to come?

And even document like the updated TLS extensions document (rfc6066)
use SHA-1 all over the place.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Mar 2011 16:37:27 -0500

Plenty is not the point.

SHA1 is no longer regarded as acceptably secure. SHA2 is based on the
same construction and is thus similarly suspect.

We don't use SHA1 in legacy browsers because we like it. We use SHA1
in legacy browsers because we have not worked out how to transition
away from it. The transition from MD5 to SHA1 was painless only
because all browsers were required to support both standards.

This particular topic is one on which the Security ADs and the IETF
chair have very very specific opinions on. And given their role in
trying to effect an industry wide transition to stronger algorithms, I
think that they are quite right to insist on them.

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

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Mar 2011 02:50:58 +0100 (MET)

> because all browsers were required to support both standards.

Transition from MD5 to SHA1?  I seem to have missed that entirely.

MD5 was removed from the PRF in the SSLv3->TLSv1.0 protocol revision,
but even TLSv1.1 uses a combination of MD5+SHA1 for digital signatures.

And there are still a number of TrustAnchors in every Browser that
carry an md5WithRsaEncryption signature.

But it's actually worse than that -- VeriSign still has a CA cert
in service with an md2WithRsaEncryption -- and is still using it
productively (check https://www.hp.com/).

Considering the transition SHA-1 --> SHA-256.  That was goofed
in TLSv1.2, by defining the default hash algorithm for the digital
signature structs to default to SHA-1 (only) -- which is actually
weaker than SSLv3/TLSv1.0/TLSv1.1 ...

> think that they are quite right to insist on them.

DANEs security is vitally dependent on DNSSEC, and for DNSSEC, SHA-1
seems to be the mandatory-to-implement algorithm for signatures.

Inuitively, why don't we tie DANE's hash algorithm to DNSSECs algorithm?

Making DANE an early adopter of SHA-3 while DNSSEC still uses SHA-1
amounts to silicon snake oil -- i.e. needless complexity.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Mar 2011 16:29:15 +0100 (MET)

> productively (check https://www.hp.com/).

I'm terribly sorry, I mixed up the (by now long) list of VeriSign
RootCA certs.

The RootCA cert under which the server cert for https://www.hp.com
is "VeriSign Class 3 Public Primary Certification Authority - G2"
and uses sha1WithRsaEncryption.  But it still is an X.509v1 cert.

My Firefox 3.5.13 comes with these three VeriSign RooCA certs
that are X.509v1, use md2WithRsaSignature and valid until 02-Aug-2028:

   "VeriSign Class 1 Public Primary Certification Authority"
   "VeriSign Class 2 Public Primary Certification Authority"
   "VeriSign Class 3 Public Primary Certification Authority"

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 12:04:56 -0500

The use of MD2 in a self signed cert has little risk as far as use of
the cert itself goes since it only serves as proof of possession which
is only relevant when the browser provider chooses to install it in
the browser.

Under windows the cert is actually authenticated under the CTL
structure which uses SHA1 at the least.

There are certainly issues with MD2, but that is not one of them.

Argument by analogy is a really bad way to conduct a security review.
We are not at all happy with the situation with respect to digets
algorithms. Moving away from SHA1 is going to be a huge problem for
the industry.

If anyone here thinks that DANE is going to be allowed to add to that
problem, well they need learning otherwise.

Choice of the crypto alg is meant to be the easy part of the problem.

---

From: Martin Rex <[email-masked]>
Date: Wed, 2 Mar 2011 18:24:55 +0100 (MET)

> is only relevant when the browser provider chooses to install it in

In the universe where I live, there exist collision attacks against MD2.
 (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)

So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
published is a real security problem and ought to have been discarded
long ago.

Else someone could try to use the preimage attack to issue himself
an intermediate CA cert under such a root cert, reusing the md2-based
signature on the RootCA cert.

I would REALLY like to kill md2withRsaEncryption as a digital
signature algorithm from our PKI implementation, like I did
with all of md4-based digital signature algorithms.

Getting rid of "tainted" RSA keys is also important.

Why do you think that FIPS 186-3 says that you are not allowed
to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
Because you "taint" your RSA key on the first time that you use it
for a weak scheme.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 16:24:40 -0500

I was aware of that attack.

That is not a problem with the use of MD2 in a self-signed certificate.

That is a problem of having used MD2.

The problem there is that if you have a key that has been used to sign
with MD2 it is going to be permanently tainted regardless of what
place the cert is in the chain and regardless of what type of cert it
is. The attacker can 'correct' for any defect wrt cert type, validity
interval etc.

There is only one effective defense against that attack and that is to
withdraw the MD2 algorithm from service.

You don't get any additional security from adding additional stronger
algorithms to the support list. You only get additional security from
withdrawing a weak algorithm from service.

Which is why I am arguing it is time to withdraw SHA1 from service. It
is only marginally more secure than MD5.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2011 21:37:09 +0000

> is only marginally more secure than MD5.

"Marginally"? Evidence please? I dont think exageration helps your case.

S

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Mar 2011 13:41:04 -0800

> "Marginally"? Evidence please? I dont think exageration helps your case.

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

> March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.

I agree with depricating SHA-1 in DANE.

---

From: Chris Palmer <[email-masked]>
Date: Wed, 02 Mar 2011 13:56:16 -0800

> I agree with depricating SHA-1 in DANE.

Indeed, I can hardly understand why we're arguing about it. SHA-1 is
over and has no place in new protocols.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2011 22:35:49 +0000

> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

Yes, sha2 is the hash algorithm of the day. 

But where's it say there's only a marginal difference between sha1 and md5? Absent evidence that's just spreading FUD which is not a good way to argue, even for the right thing.

S

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 02 Mar 2011 13:42:06 -0800

> is only marginally more secure than MD5.

The wording for Issue #21 is:

Currently, the draft is silent on which crypto algorithms and 
certificate types must be implemented for interoperability. It should be 
specific before the document is finished.

It sounds like you want to open a different issue that deals with which 
crypto algorithms MUST NOT be supported. Does that sound correct?

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Mar 2011 14:47:22 -0800

> But where's it say there's only a marginal difference between sha1 and md5? Absent evidence that's just spreading FUD which is not a good way to argue, even for the right thing.

I'll take Ron Rivest's word on it: http://mail.python.org/pipermail/python-dev/2005-December/058850.html

> I'm curious as to the status of upgrading cryptographic
> hash function support in Python, now that md5 and sha1 are
> both clearly broken (in terms of collision-resistance).

If he puts the two in the same category of broken, I'd trust that judgement.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 01 Mar 2011 14:38:09 -0800

> think that they are quite right to insist on them.

If you can quote previous statements from any of them suggesting that 
SHA-256 is suspect, that would be more useful than you simply suggesting 
that they had said something. It would be useful to this discussion for 
each of us to speak only for ourselves and for those who have asked us 
to speak for them, or to quote others whom we think are authorities.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Mar 2011 23:03:10 +0000

> I'll take Ron Rivest's word on it: http://mail.python.org/pipermail/python-dev/2005-December/058850.html

Note the date on that is 2005. We've been moving away from sha-1
since then and continue to do so as we should. Overstating the
situation is not a good way to make progress in that.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 18:09:11 -0500

What I meant to write was that SHA1 is only marginally more secure
than MD5 was when we decided to stop using it. Obviously with 32 extra
bits it is harder to break.

If you look at the internals of SHA1-0, the original proposal, you
will find that it is in effect simply MD5 with an additional set of
state variables to extend the size to 160 bits.

The spec was amended to add in an additional expansion function before
it was approved. In a private conversation in 1995 at the time the
Dobbertin attack was first circulated, Rivest was of the opinion that
this would make it somewhat more resistant to the Dobbertin attack but
not considerably so.

While the attacks on SHA1 are currently theoretical, they are rapidly
approaching the point at which we started to decide that use of MD5
should be avoided.

Further, even though we stopped using MD5 in the mid 90s, it is still
possible to use MD5 securely but doing so requires considerable
attention to other security precautions. So even if there is a
theoretical break of SHA1 we are hardly in a situation where we will
face an immediate crisis.

If SHA1 is 'broken' tomorrow it is likely going to be 2020 before
there is a practical exploit based on that attack. But that is not
reason for complacency as it is likely to take us a decade to dig our
way out of using SHA1.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Mar 2011 23:17:09 +0000

I think this is a good enough statement of the situation as I
understand it.

Thanks,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 18:24:43 -0500

There is currently no evidence that SHA2-256 is unacceptably weak.

However it is based on the same construction as MD4, MD5 and SHA1. And
thus the reason for the current NIST competition.

Since the NIST competition is not currently complete, there is
currently no viable alternative to SHA2. While there are other
algorithms in use, I would expect the competition to supersede those
as well.

I think that what we should do here is

1) Make support for SHA2-256 and SHA2-384 REQUIRED
2) Ensure that it is feasible to transition from use of SHA2 to a new algorithm
3) Deprecate use of MD2,MD4,MD5 and SHA1.

The second point is really rather important since even though it is
possible to emit bit strings that use SHA2 in protocols such as SSL
and S/MIME, it is not feasible to use them in practice because there
is no way to know whether the other party is one of those which is
capable of using them.

On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman <[email-masked]> wrote:
> that they had said something. It would be useful to this discussion for each
> of us to speak only for ourselves and for those who have asked us to speak
> for them, or to quote others whom we think are authorities.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 2 Mar 2011 18:43:54 -0500

> 2) Ensure that it is feasible to transition from use of SHA2 to a  

<no hats>
Shouldn't this be much much more general? "Ensure that it is feasible  
to transition to new algorithms"? <note: I don't know how we do this,  
but I also don't see why "from SHA2" would be a special case>

> 3) Deprecate use of MD2,MD4,MD5 and SHA1.

Um, I'm confused by number 3 -- I think that the only things we need  
to do *here* is decide what we *do* support....
Deprecating the use of other things, while fine and good, doesn't need  
to happen *here* if we don't support them...

W
</no hats>

--
We know about as much about software quality problems as they knew  
about the Black Plague in the 1600s. We've seen the victims' agonies  
and helped burn the corpses. We don't know what causes it; we don't  
really know if there is only one disease. We just suffer -- and keep  
pouring our sewage into our water supply.

-- Tom Van Vleck

---

From: Sean Turner <[email-masked]>
Date: Wed, 02 Mar 2011 19:50:31 -0500

On 3/2/11 6:43 PM, Warren Kumari wrote:
> Shouldn't this be much much more general? "Ensure that it is feasible to
> transition to new algorithms"? <note: I don't know how we do this, but I
> also don't see why "from SHA2" would be a special case>
>
> Um, I'm confused by number 3 -- I think that the only things we need to
> do *here* is decide what we *do* support....

#3 is kind of taken care of.  MD2 and MD4 are being made historic:

http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/
http://datatracker.ietf.org/doc/draft-turner-md4-to-historic/

and the security considerations for MD5 were updated:

http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/

spt

> We know about as much about software quality problems as they knew about
> the Black Plague in the 1600s. We've seen the victims' agonies and
> helped burn the corpses. We don't know what causes it; we don't really
> know if there is only one disease. We just suffer -- and keep pouring
> our sewage into our water supply.
>
> -- Tom Van Vleck
>
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 02 Mar 2011 16:59:13 -0800

> thus the reason for the current NIST competition.

I believe that NIST said many times that it is *a* reason, not *the* reason.

> algorithms in use, I would expect the competition to supersede those

It would be useful to this discussion for each of us to speak only for 
ourselves and for those who have asked us to speak for them, or to quote 
others whom we think are authorities. NIST has not, I believe, said that 
the results of the competition will supersede SHA-2; if I'm wrong, 
please send full quotes.

> is no way to know whether the other party is one of those which is

We disagree on #1 in that I don't think that requiring SHA-384 has any 
practical value and adds a second code path where none is needed.

We agree only partially on #2. You keep saying "SHA2" when you probably 
mean "SHA-256 and SHA-384". I agree that making the transition feasible 
is good, and we already have that.

We disagree on #3, and deprecating crypto is a different issue than 
mandating crypto.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 22:55:20 -0500

On Wed, Mar 2, 2011 at 7:59 PM, Paul Hoffman <[email-masked]> wrote:
> others whom we think are authorities. NIST has not, I believe, said that the
> results of the competition will supersede SHA-2; if I'm wrong, please send
> full quotes.

Pot, kettle black.

I would really prefer it if you Paul would not take it upon yourself
to chair this particular working group because (1) you are not the
chair and (2) your contributions appear to me to be a constant stream
of personal attacks.

When I say "I would expect the competition to supersede those as
well." the group should assume that I am speaking for myself and that
I have in fact consulted myself on the topic in question.

As it happens I was probably the first person to suggest a digest
competition to NIST since I met with Bill Burr less than an hour after
the weakness in the SHA-1 construction was announced by Adi Shamir. I
had previously had discussions with Burt Kaliski, Rivest and others in
the field.

By the end of the show it was clear that there would be a digest
algorithm competition, the only question was whether it would be
sponsored by NIST or another party. I probably wasn't the only person
who had authorization to offer to underwrite a competition.

So on this particular topic, as with many others, your sniping and
carping is completely off base. I was there and you were not.

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Mar 2011 05:57:04 +0100 (MET)

> We disagree on #3, and deprecating crypto is a different issue than 

I agree to all what Paul wrote.

Iff SHA-256 is to be a mandatory to implement hash for DANE, then
I see _no_ point in supporting SHA-1 at all (and saves us migration).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Mar 2011 06:09:15 +0100 (MET)

Phillip Hallam-Baker wrote:
> 
> Further, even though we stopped using MD5 in the mid 90s

This seems wrong for most "we" and most environments
that I can think of, certainly for the use of TLS on the internet.

The very little thing that TLSv1.0 changed at the beginning
of the new millenium is that it removed MD5 from the PRF that
derives the TLS session master-secret and traffic keys.
TLS did not affect in any way the use of MD5 for digitial signatures.

On my scorecard, neither deprecation of the MD5 hash
algorithms, nor migration away from MD5 hash algorithm
has happend so far.

Firefox happily verifies md5WithRsaEncryption signatures on TLS server
certs.  Only digital signature algorithms based on MD4 and MD2
seem to have been disabled since 3.0.something.

MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers
using certs signed not only with md5WithRsaSignature, but also
md2WithRsaSignature and even (**cough**) md4WithRsaSignature!

Some may think "but Windows has a FIPS-compliant crypto algs switch".
This (carefully hidden) switch disables SSLv3, but does NOT
affect the acceptance of TLS server certificates signed with
md5withRsaEncryption, md2WithRsaEncryption or md4WithRsaEncryption.

(If it is possible to disable md5WithRsaEncryption signature verification
 in Firefox 3.5 -- then it is sufficiently well hidden that I don't
 see it.)

To me, the claim that MD5 in digital signatures was deprecated
in mid-90's is seriously defying the real world.  It may have
happened in small isolated environments, but it definitely did
not happen yet where TLS is used on the internet today.

I'm puzzled why so many commercial CAs are fiercly resisting
the deprecation of obsolete digital signature algorithms such
as md2WithRsaEncryption and md5WithRsaEncryption by continuing
to distribute TrustAnchors as self-signed X.509 certs with such
signatures on them.  Look in the cert store of your favourite
browser, or look into Microsofts TrustList distribution that
my Windows box tries polling from here:

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Mar 2011 07:46:52 +0000

> > Further, even though we stopped using MD5 in the mid 90s
<snip>
> certs.

Not for much longer.

https://wiki.mozilla.org/CA:MD5and1024 says:
"    * June 30, 2011 – Mozilla will stop accepting MD5 as a hash algorithm for 
intermediate and end-entity certificates. After this date software published 
by Mozilla will return an error when a certificate with an MD5-based signature 
is used.
          o This change is being tracked in 
https://bugzilla.mozilla.org/show_bug.cgi?id=590364"

<snip>
> md2WithRsaSignature and even (**cough**) md4WithRsaSignature!

http://technet.microsoft.com/en-us/library/cc751157.aspx#EMAA says:
"In the event of an imminent MD5 pre-image attack
Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and 
subordinate CA certificates when it has reasons to believe that successful MD5 
pre-image attacks are imminent."

Perhaps somebody should ask them to consider switching off MD2 and MD4 sooner 
than that.

<snip>
>  in Firefox 3.5 -- then it is sufficiently well hidden that I don't

https://bugzilla.mozilla.org/show_bug.cgi?id=590364 suggests setting the 
following environment variable:

NSS_HASH_ALG_SUPPORT=-MD2,-MD5

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Mar 2011 08:57:04 -0500

On another algorithm issue, certain people were waiting for CAs to
support the new algorithm before implementing them in application
software.

By support, they meant issue certificates that would break with their software.

The reason that there is concern about algorithm support in protocols
is that it takes a very very long time to get changes through the
system. It can take five years to persuade vendors to make changes and
then another ten for the old software to work through the system.

Auto update helps, but that may only prove to be a temporary change.
There are enough applications out there that do auto update very badly
that people are being taught to turn them off.

One of the very few signals available that is listened to is to stop
supporting old algorithms in new protocols.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Mar 2011 09:34:16 -0500

> supporting old algorithms in new protocols.

But as I think Warren said upthread, we simply don't need to list the
protocols we don't want _at all_.  Then they're not supported from the
get go.  We don't need to talk about algorithms we don't want to
support.

The key thing, I think we all agree, is to make sure algorithm change
can happen.  This is an area where DNSSEC is still somewhat less than
perfect, for instance.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 04 Mar 2011 13:57:53 +1300

Phillip Hallam-Baker <[email-masked]> writes:

>The reason that there is concern about algorithm support in protocols is that
>it takes a very very long time to get changes through the system. It can take
>five years to persuade vendors to make changes and then another ten for the
>old software to work through the system.

See also Question J of
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt (based on a very
ad hoc survey of a bunch of implementers, but it's good enough as a rough
guide).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 04 Mar 2011 14:19:48 +1300

>1) Make support for SHA2-256 and SHA2-384 REQUIRED

Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
enough then use the full SHA512, not some oddball variant.

In any case what we should really be specifying is SHA256 and SHA3.  If SHA256
really isn't cromulent enough for people then SHA384 won't be either, and by
the time this sees significant deployment we'll have SHA3 anyway.  How much
real-world support is there for SHA384?  I've only just seen SHA256 creeping
in here and there, but never SHA384.  Again, by the time there's even single-
digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Mar 2011 20:44:52 -0500

> enough then use the full SHA512, not some oddball variant.

Because we are working in DNS and so the number of bits is actually an
issue.

I agree that there is little point to the truncation step when the digest is
used with a digital signature. But here the extra bits do count.

> digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go.

When is your estimate for the SHA3 process completing?

I am a bit nervous having a WG depend on the output of any external process.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Mar 2011 18:26:36 -0800

On Mar 3, 2011, at 5:44 PM, Phillip Hallam-Baker wrote:

> 
> 
> On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann <[email-masked]> wrote:
> Because we are working in DNS and so the number of bits is actually an issue.
> 
> I agree that there is little point to the truncation step when the digest is used with a digital signature. But here the extra bits do count.

A whopping 16 bytes does NOT count:  In very VERY few cases will it cause the DNS message to fall past the magic ~1472B and ~4000B boundries where you start to have fragmentation & truncation, AND in those cases, the resolver damn well better be able to handle it.

We should not try to scrimp 16B out in message formatting in this case, its silly, redundant, AND encouraging brokenness (bad fragmentation & truncation behavior) to remain borken.

> I am a bit nervous having a WG depend on the output of any external process.

Why not "AND, when NIST approves it, SHA3"? in the text?

---

From: Yoav Nir <[email-masked]>
Date: Fri, 4 Mar 2011 08:07:41 +0200

> We should not try to scrimp 16B out in message formatting in this case, its silly, redundant, AND encouraging brokenness (bad fragmentation & truncation behavior) to remain borken.

I agree.

> Why not "AND, when NIST approves it, SHA3"? in the text?

That's weird text. If when SHA-3 arrives, the RFC had been published, we make a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an issue and add it.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 04 Mar 2011 23:51:10 +1300

Yoav Nir <[email-masked]> writes:
>> We should not try to scrimp 16B out in message formatting in this case, its
>> silly, redundant, AND encouraging brokenness (bad fragmentation & truncation
>> behavior) to remain borken.
>
>I agree.

Ditto.

>That's weird text. If when SHA-3 arrives, the RFC had been published, we make
>a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an issue and
>add it.

It would be good though to include a placeholder for SHA3 to that, at most,
implementations just have to drop in the implementation code.  I've had a
placeholder in my code for a while now, it's been tested throughout the code
(by using a dummy implementation that returns a constant "hash"), so when SHA3
is finalised all I need to do is plug the algorithm in.  Putting the same
thing into DANE isn't hard, and makes it easier to deploy future-compatible
implementations from day one.

Peter.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Mar 2011 07:13:18 -0500

> implementations from day one.

I don't see any reason to say specifically, "We'll be moving to _x_ so
you better have a placeholder for it".  That will simply encourage
foolish programmers to write one placeholder spot, and then when SHA-4
or whatever comes along we have a new problem.

The right way to do this is something like the unknown RRTYPE in DNS.
In that case, you have to be able to handle anything you get (within
the valid codepoint range) _even if_ you don't understand it.  By
"handle", I mean, "be able to pass messages; not spit up and die," and
so on.  It does not mean, of course, that you have to be able to do
whatever additional section processing or whatever is required, and
you don't need to be able to do anything useful (if you don't know
what NSEC3 is, you're not going to be able to validate with it).  

I'm not sure how to say something similar in this case, but I think
it's the right sort of framework.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 04 Mar 2011 06:36:42 -0800

> it's the right sort of framework.

The way I read Warren's proposal, we get exactly what you want. There 
are two different mandatory code points defined for two different 
hashes, so we are sure that the deployed code will be able to handle 
hash agility. We don't care which algorithm people use in practice 
because they are both mandatory, so there is no spitting up or dying.

Does that work for you?

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Mar 2011 09:51:29 -0500

> because they are both mandatory, so there is no spitting up or dying.

Sort of.  Maybe it's recent exposure to brain-dead programmers, but
I've encountered the situation where a spec says, "There are now two;
there might be more in the future."  What the programmer does is go
away and write an implementation that has the two, and puts a comment
in the code that says, "Future code changes may need to be here,
because there might be new things defined."  Or something like that.

As I say, I can't think of much to say about this that's different, so
maybe I'm fretting over nothing.  But algorithm maintenance is already
a headache for DNSSEC, and we've only started deployment.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Fri, 4 Mar 2011 15:19:34 +0000

> or whatever comes along we have a new problem.

	depends on how the spec is written.  you have already 
	indicated a preference for more than one algo.  Lets call
	them current & future.  for current, lets say we use SHA-256
	and future, SHA3.   we could then move SHA3 to current and
	move AndrewsKewlKode to future...  and so on...  right?