Subject: [http-auth] draft-ietf-httpauth-digest-update and SHA-3

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jul 2013 08:13:06 -0700

Greetings again. draft-ietf-httpauth-digest-update has a code point for SHA-3, but there is no reference for it. There is a good reason for that: there is none yet.

NIST has said that they don't know what parameters and so on they will want people to use for SHA-3. Having a parameter for SHA-3 in this document is incredibly premature. When NIST figures out what they want, the IETF can figure out whether we want it too and update the registries of the appropriate protocols.

Please remove any mention of SHA-3 from this document.

--Paul Hoffman

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 5 Jul 2013 13:11:55 -0400

I thought we had that discussion already when we discussed Algorithm
Agility.
Take a look at the following email from Yoav around NIST's plan for SHA3:
http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html

Regards,
 Rifaat

On Fri, Jul 5, 2013 at 11:13 AM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. draft-ietf-httpauth-digest-update has a code point for
> SHA-3, but there is no reference for it. There is a good reason for that:
> there is none yet.
>
> NIST has said that they don't know what parameters and so on they will
> want people to use for SHA-3. Having a parameter for SHA-3 in this document
> is incredibly premature. When NIST figures out what they want, the IETF can
> figure out whether we want it too and update the registries of the
> appropriate protocols.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jul 2013 10:34:15 -0700

On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:

> I thought we had that discussion already when we discussed Algorithm Agility.

Yoav said "may", and he meant "may". That also means "may not", or "may take years to get this right". Yoav appears optimistic in his message; I was at the same meeting and came away very pessimistic. There are many ways that NIST can get this wrong by having too many options, just as they are doing with SHA-2 ("we didn't really mean SHA-384, we meant truncated SHA-512; err, maybe both; you figure it out").

It is inappropriate for a standards-track document to refer to a cryptographic algorithm without a precise definition of that algorithm as it will be used in the protocol. This draft is missing that, and thus should remove any discussion of SHA-3 until you can have it.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 05 Jul 2013 22:38:07 +0300

I would suggest to drop all occurrences of "SHA3-256", because it is not 
well defined today. And to add in Sec. 3.4: "a future version of this 
document might add SHA3 as a backup algorithm, once its definition has 
been finalized and published."

You can give this link as an informative reference: 
http://csrc.nist.gov/groups/ST/hash/index.html

And by the way, there is in fact a timeline for FIPS standardization at 
this link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html 
- which appears to be quite recent.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jul 2013 13:14:17 -0700

On Jul 5, 2013, at 12:38 PM, Yaron Sheffer <[email-masked]> wrote:

> I would suggest to drop all occurrences of "SHA3-256", because it is not well defined today. And to add in Sec. 3.4: "a future version of this document might add SHA3 as a backup algorithm, once its definition has been finalized and published."

+1 

> You can give this link as an informative reference: http://csrc.nist.gov/groups/ST/hash/index.html

-1 because NIST has a nasty habit of breaking URLs. It is sufficient to have the above sentence without a reference.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Fri, 5 Jul 2013 20:26:54 +0000

By the timeline in there, we should have a document to point to some time in Q3. I don't see a problem with this. Or are we ready for last call already?

Mandating just SHA2-256 and having SHA3-256 as backup was first suggested in http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and nobody seemed to object at the time.

Yoav

On Jul 5, 2013, at 10:38 PM, Yaron Sheffer <[email-masked]> wrote:

> And by the way, there is in fact a timeline for FIPS standardization at this link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html - which appears to be quite recent.
> 
> Thanks,
> 	Yaron
> 
> 
> Email secured by Check Point

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jul 2013 13:41:09 -0700

On Jul 5, 2013, at 1:26 PM, Yoav Nir <[email-masked]> wrote:

> By the timeline in there, we should have a document to point to some time in Q3.

Just because they publish some preliminary document, maybe it is not such a good idea to encase that in HTTP servers that are rarely upgraded. NIST's mandate of coming up with something secure for US government use sometimes does not align all that well with the IETF's mandate of long-term stability.

> Mandating just SHA2-256 and having SHA3-256 as backup was first suggested in http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and nobody seemed to object at the time.

http://www.ietf.org/mail-archive/web/http-auth/current/threads.html#01347

I objected, and I believe Manu did as well (although Stephen disagreed that is what Manu said).

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 05 Jul 2013 23:59:58 +0300

The way I read the timeline, 2Q 2014 is when we will have a document "to 
point to".

So although in principle I agree that having two different algorithms is 
a good thing (two, one primary and another for backup, not "a bag of 
algorithms"), in this case I wouldn't hold the document while waiting 
for SHA-3. We are gaining I18N after all, which is very important.

Thanks,
	Yaron

PS: to further support Paul's argument, let me point out that current 
implementations of PHP still have a "Rijndael-256" cipher, which is 
*not* AES-256.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 5 Jul 2013 19:09:51 -0400

I am fine with Yaron's proposal of mentioning SHA-3 as a possible future
addition as a back up algorithm. Any objection to that idea?

Regards,
 Rifaat

On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer <[email-masked]> wrote:

> So although in principle I agree that having two different algorithms is a
> good thing (two, one primary and another for backup, not "a bag of
> algorithms"), in this case I wouldn't hold the document while waiting for
> SHA-3. We are gaining I18N after all, which is very important.
>
> Thanks,
>         Yaron
>
> implementations of PHP still have a "Rijndael-256" cipher, which is *not*
> AES-256.
>
>
>> By the timeline in there, we should have a document to point to some time
>> in Q3. I don't see a problem with this. Or are we ready for last call
>> already?
>>
>> Mandating just SHA2-256 and having SHA3-256 as backup was first suggested
>> in http://www.ietf.org/mail-**archive/web/http-auth/current/**
>> msg01347.html<http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html>and nobody seemed to object at the time.
>>
>> Yoav
>>
>>> document might add SHA3 as a backup algorithm, once its definition has been
>>> finalized and published."
>>>
>>> http://csrc.nist.gov/groups/**ST/hash/index.html<http://csrc.nist.gov/groups/ST/hash/index.html>
>>>
>>> this link: http://csrc.nist.gov/groups/**ST/hash/sha-3/timeline_fips.**
>>> html <http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html> -
>>> which appears to be quite recent.
>>>
>>> Thanks,
>>>         Yaron
>>>
>>>
>>>>> http://www.ietf.org/mail-**archive/web/http-auth/current/**
>>>>> msg01374.html<http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html>
>>>>>
>>>>
>>>> Yoav said "may", and he meant "may". That also means "may not", or "may
>>>> take years to get this right". Yoav appears optimistic in his message; I
>>>> was at the same meeting and came away very pessimistic. There are many ways
>>>> that NIST can get this wrong by having too many options, just as they are
>>>> doing with SHA-2 ("we didn't really mean SHA-384, we meant truncated
>>>> SHA-512; err, maybe both; you figure it out").
>>>>
>>>> It is inappropriate for a standards-track document to refer to a
>>>> cryptographic algorithm without a precise definition of that algorithm as
>>>> it will be used in the protocol. This draft is missing that, and thus
>>>> should remove any discussion of SHA-3 until you can have it.
>>>>
>>>> --Paul Hoffman
>>>> ______________________________**_________________
>>>> http-auth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>>>
>>>>  ______________________________**_________________
>>> http-auth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>>>
>>  ______________________________**_________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/http-auth<https://www.ietf.org/mailman/listinfo/http-auth>
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 6 Jul 2013 03:53:06 +0000

Only that then we're left with no backup algorithm. (hopefully by now MD5 doesn't count)

On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
 wrote:

I am fine with Yaron's proposal of mentioning SHA-3 as a possible future addition as a back up algorithm. Any objection to that idea?

Regards,
 Rifaat

On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
The way I read the timeline, 2Q 2014 is when we will have a document "to point to".

So although in principle I agree that having two different algorithms is a good thing (two, one primary and another for backup, not "a bag of algorithms"), in this case I wouldn't hold the document while waiting for SHA-3. We are gaining I18N after all, which is very important.

Thanks,
        Yaron

PS: to further support Paul's argument, let me point out that current implementations of PHP still have a "Rijndael-256" cipher, which is *not* AES-256.

Yoav

On Jul 5, 2013, at 10:38 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
        Yaron

On 2013-07-05 20:34, Paul Hoffman wrote:
On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

--Paul Hoffman
_______________________________________________
http-auth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/http-auth

_______________________________________________
http-auth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/http-auth

_______________________________________________
http-auth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/http-auth

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 06 Jul 2013 13:28:13 +0900

> Only that then we're left with no backup algorithm. (hopefully by now MD5 doesn't count)

Just saying that SHA-3 is a backup algorithm without knowing the 
necessary details means that this is essentially the same as no backup 
algorithm.

Regards,    Martin.

> On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef<[email-masked]<mailto:[email-masked]>>
>   wrote:
>
> On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer<[email-masked]<mailto:[email-masked]>>  wrote:

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 6 Jul 2013 06:12:43 -0400

How about choosing a variant of SHA2 as a backup with some text around the
intention to replace it with SHA3 when that is ready?

Regards,
 Rifaat

On Sat, Jul 6, 2013 at 12:28 AM, "Martin J. Dürst"
<[email-masked]>wrote:

> Just saying that SHA-3 is a backup algorithm without knowing the necessary
> details means that this is essentially the same as no backup algorithm.
>
> Regards,    Martin.
>
>  On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef<rifaat.ietf@gmail.**com<[email-masked]>
>> <mailto:rifaat.ietf@gmail.**com <[email-masked]>>>
>>
>>   wrote:
>>
>> On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer<[email-masked]<**
>> mailto:[email-masked]>>  wrote:
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 06 Jul 2013 14:23:08 +0300

Hi Rifaat,

I don't think this is a good idea. The point of a backup algorithm is to 
have something that's dissimilar enough so that if algorithm A is 
broken, algorithm B is unlikely to be weakened as well.

So let's do only SHA2-256 for the time being, plus the infrastructure 
for future agility, and add SHA-3 when it is in a usable shape.

Thanks,
	Yaron

On 2013-07-06 13:12, Rifaat Shekh-Yusef wrote:
> How about choosing a variant of SHA2 as a backup with some text around
> the intention to replace it with SHA3 when that is ready?
>
> Regards,
>   Rifaat
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     necessary details means that this is essentially the same as no
>     backup algorithm.
>
>     Regards,    Martin.
>
>         On Jul 6, 2013, at 2:09 AM, Rifaat
>         Shekh-Yusef<[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>            wrote:
>
>         I am fine with Yaron's proposal of mentioning SHA-3 as a
>         possible future addition as a back up algorithm. Any objection
>         to that idea?
>
>         Regards,
>            Rifaat
>
>
>
>         On Fri, Jul 5, 2013 at 4:59 PM, Yaron
>         Sheffer<[email-masked]
>         <mailto:[email-masked]><__mailto:[email-masked]
>         <mailto:[email-masked]>>>  wrote:
>
>         So although in principle I agree that having two different
>         algorithms is a good thing (two, one primary and another for
>         backup, not "a bag of algorithms"), in this case I wouldn't hold
>         the document while waiting for SHA-3. We are gaining I18N after
>         all, which is very important.
>
>         Thanks,
>                   Yaron
>
>         PS: to further support Paul's argument, let me point out that
>         current implementations of PHP still have a "Rijndael-256"
>         cipher, which is *not* AES-256.
>
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 08:03:37 -0700

On Jul 5, 2013, at 9:28 PM, Martin J. Dürst <[email-masked]> wrote:

> Just saying that SHA-3 is a backup algorithm without knowing the necessary details means that this is essentially the same as no backup algorithm.

It's actually worse because some implementer will guess what is "obviously" meant by the unreferenced string in the RFC, but will be wrong. At that point, the string "SHA3" becomes useless for interoperability, and the update RFC will have to use a string like "SHA3-2014" or something horrid like that.

A reasonable backup hash algorithm is SHA2-512. If the WG likes this, the string names for the mandatory algorithms should be "SHA2-256" and "SHA2-256-sess", and the backups "SHA2-512" and "SHA2-512-sess".

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 08:05:44 -0700

On Jul 6, 2013, at 4:23 AM, Yaron Sheffer <[email-masked]> wrote:

> I don't think this is a good idea. The point of a backup algorithm is to have something that's dissimilar enough so that if algorithm A is broken, algorithm B is unlikely to be weakened as well.
> 
> So let's do only SHA2-256 for the time being, plus the infrastructure for future agility, and add SHA-3 when it is in a usable shape.

If both SHA2-256 and SHA2-512 have significant problems, the world will be happy to update to SHA3-whatever in all protocols.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Sat, 6 Jul 2013 15:18:43 +0000

> A reasonable backup hash algorithm is SHA2-512. If the WG likes this, the string names for the mandatory algorithms should be "SHA2-256" and "SHA2-256-sess", and the backups "SHA2-512" and "SHA2-51…

OK, but if we're going down this path, I'd suggest we use SHA2-512/256 instead of straight SHA2-512. Both are well defined, and SHA2-512/256 has shorter output. We might want a shorter string as well, though, or we'll lose all that we gain in a shorter hash to a longer name.

Also, what's "-sess"?

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 08:34:59 -0700

On Jul 6, 2013, at 8:18 AM, Yoav Nir <[email-masked]> wrote:

> OK, but if we're going down this path, I'd suggest we use SHA2-512/256 instead of straight SHA2-512. Both are well defined, and SHA2-512/256 has shorter output.

That sounds fine as well.

> We might want a shorter string as well, though, or we'll lose all that we gain in a shorter hash to a longer name.

We could shorten the names to "A", "B", "C" and so on if length is a concern.

> Also, what's "-sess"?

See Section 3.2.1 of the current draft.

--Paul Hoffman

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 6 Jul 2013 12:39:33 -0400

Ok, so SHA2-512/256 as a backup algorithm with some text around that
possibly being replaced by SHA3 in the future. Any objection to this?

Regards,
 Rifaat

On Sat, Jul 6, 2013 at 11:34 AM, Paul Hoffman <[email-masked]> wrote:

> > OK, but if we're going down this path, I'd suggest we use SHA2-512/256
> instead of straight SHA2-512. Both are well defined, and SHA2-512/256 has
> shorter output.
>
> > We might want a shorter string as well, though, or we'll lose all that
> we gain in a shorter hash to a longer name.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 06 Jul 2013 19:52:47 +0300

I think we're spending too much time on this one, but since you're asking...

As far as I know (and if there's any cryptographer in the house, please 
correct me), SHA2-512 and SHA2-256 are based on the same building 
blocks. So if something bad happens to SHA2-256, we'd better migrate 
away to another primitive. In other words, I think adding SHA2-512 
(truncated or not) would be a waste of time.

We'd better just hold our horses and add SHA3 as a backup algorithm in 
the future.

Thanks,
	Yaron

On 2013-07-06 19:39, Rifaat Shekh-Yusef wrote:
> On Sat, Jul 6, 2013 at 11:34 AM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Jul 6, 2013, at 8:18 AM, Yoav Nir <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      > OK, but if we're going down this path, I'd suggest we use
>     SHA2-512/256 instead of straight SHA2-512. Both are well defined,
>     and SHA2-512/256 has shorter output.
>
>      > We might want a shorter string as well, though, or we'll lose all
>     that we gain in a shorter hash to a longer name.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Jul 2013 10:09:17 -0700

On Jul 6, 2013, at 9:52 AM, Yaron Sheffer <[email-masked]> wrote:

> As far as I know (and if there's any cryptographer in the house, please correct me), SHA2-512 and SHA2-256 are based on the same building blocks. So if something bad happens to SHA2-256, we'd better migrate away to another primitive. In other words, I think adding SHA2-512 (truncated or not) would be a waste of time.

This is uncreative thinking. The "something bad" could be related to the key table for SHA-256, at which point the backup would be fully useful. The "something bad" could also be more severe, but completely ameliorated by the extra bits in the mix-and-mash.

> We'd better just hold our horses and add SHA3 as a backup algorithm in the future.

I'm fine with either approach (backup is SHA-512-truncated, or no backup) IN the latter case, the initial RFC needs to signal that there is an expectation that there will be additional algorithms specified in the future so that an implementer knows that they should handle unexpected strings for the hash function, and hopefully make their hash-handling code flexible.

--Paul Hoffman

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 6 Jul 2013 13:19:58 -0400

Yeah, I agree with Paul, and I am leaning towards adding SHA2-512/256 as a
backup algorithm and mentioning SHA3 as possible future replacement.

Regards,
 Rifaat

On Sat, Jul 6, 2013 at 1:09 PM, Paul Hoffman <[email-masked]> wrote:

> correct me), SHA2-512 and SHA2-256 are based on the same building blocks.
> So if something bad happens to SHA2-256, we'd better migrate away to
> another primitive. In other words, I think adding SHA2-512 (truncated or
> not) would be a waste of time.
>
> This is uncreative thinking. The "something bad" could be related to the
> key table for SHA-256, at which point the backup would be fully useful. The
> "something bad" could also be more severe, but completely ameliorated by
> the extra bits in the mix-and-mash.
>
> I'm fine with either approach (backup is SHA-512-truncated, or no backup)
> IN the latter case, the initial RFC needs to signal that there is an
> expectation that there will be additional algorithms specified in the
> future so that an implementer knows that they should handle unexpected
> strings for the hash function, and hopefully make their hash-handling code
> flexible.
>
> --Paul Hoffman

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 7 Jul 2013 09:24:12 -0400

I have just submitted a new version of the draft that removes SHA3 as a
back algorithm and uses SHA2-512/256 instead. The draft also mentions that
a future version might add SHA3 as a backup algorithm.
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/

Please, review the new draft and let me know if you have any further
comments.

Regards,
 Rifaat

On Sat, Jul 6, 2013 at 1:19 PM, Rifaat Shekh-Yusef <[email-masked]>wrote:

> On Sat, Jul 6, 2013 at 1:09 PM, Paul Hoffman <[email-masked]>wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jul 2013 07:44:08 -0700

On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:

> I have just submitted a new version of the draft that removes SHA3 as a back algorithm and uses SHA2-512/256 instead. The draft also mentions that a future version might add SHA3 as a backup algorithm.
> Please, review the new draft and let me know if you have any further comments.

This looks very good. We need a reference for SHA-512-256, but I think I remember that NIST already has one.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 07 Jul 2013 17:51:12 +0300

Hi,

The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2.

The correct notation is "SHA-512/256".

And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if 
common implementations of SHA2 support this algorithm, which is *not* 
the naive truncation that I expected it to be.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 7 Jul 2013 08:29:56 -0700

> The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2.

Good catch.

> The correct notation is "SHA-512/256".

Yes, I noticed that, but wasn't sure we wanted a "/" in our algorithm names.

> And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if common implementations of SHA2 support this algorithm, which is *not* the naive truncation that I expected it to be.

Then we should call it out. There is also a draft, draft-dang-turner-sha-512-224-256, that covers the same material, and that draft might get on RFC track before this one, given that it is uncontentious.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jul 2013 15:56:31 +0000

[with implementer hat on]

My implementation has it, although this makes little difference as it's not a public library.

OIDs are already defined for this algorithm (2.16.840.1.101.3.4.2.6 and 1.2.840.113549.1.1.16) but I'm not aware of anyone issuing certificates with it.

We could define a simple truncation of SHA2-512 ourselves, but I guess there was some method behind defining it a little differently. Anyone know?

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jul 2013 15:56:38 +0000

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jul 2013 15:56:44 +0000

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 7 Jul 2013 16:14:51 +0000

Aargh. What I tell you three times is true?

Sorry about that.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 07 Jul 2013 19:32:14 +0300

Re: notation, I meant that this is the official name of the algorithm, 
and should be used in the running text. I'm not saying it should go 
verbatim into the HTTP header.

Thanks,
	Yaron

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 7 Jul 2013 19:00:00 -0400

Thanks, I will fix the errors, add references, and add some text around the
possible lack of implementations for the SHA2-512/256 algorithm.

Regards,
 Rifaat

On Sun, Jul 7, 2013 at 12:32 PM, Yaron Sheffer <[email-masked]>wrote:

> Re: notation, I meant that this is the official name of the algorithm, and
> should be used in the running text. I'm not saying it should go verbatim
> into the HTTP header.
>
> Thanks,
>         Yaron
>
>
>>> common implementations of SHA2 support this algorithm, which is *not* the
>>> naive truncation that I expected it to be.
>>>
>>
>> Then we should call it out. There is also a draft,
>> draft-dang-turner-sha-512-224-**256, that covers the same material, and
>> that draft might get on RFC track before this one, given that it is
>> uncontentious.
>>
>> --Paul Hoffman