Subject: [Curdle] Some work for the group

From: "Salz, Rich" <[email-masked]>
Date: Fri, 9 Dec 2016 00:23:00 +0000

Hi there!

We are looking for feedback on the following items, my memory spurred by the draft minutes found here:  https://datatracker.ietf.org/doc/minutes-97-curdle/

Please review the minutes by the end of the month.  Speak up on the list if anything's wrong.  Thanks to Ben Kaduk for taking them.

Has anyone (besides Kyle Rose) reviewed curdle-rsa-sha2 ?  Are we ready for WGLC?  Please respond within a week.

The text in draft-ietf-curdle-pkix says CA's MUST NOT use pre-hash version of signatures.  Does anyone object to this?  There is a mention of the trade-offs in doing that at the end of section 5.  Please respond within a week.

curdle-ssh-ext-info, curdle-ssh-kex-sha2, curdle-ssh-modp-dh-sha2
Has anyone read these?  Will one or more people commit to doing so within a week?  (Commit, not actually read)

Contexts - has anyone got a use for signature contexts? See the minutes.  If you're opposed to the (slight) consensus, speak up.

Thanks.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Dec 2016 21:18:38 -0500

I don't much care from a CA point of view unless there is going to be
difficult getting the hardware we need to implement the signatures. Since
that hardware does not currently exist and since we would assume that any
suppliers would make sure they support the required mode, I doubt that will
be an issue.

There is a modest efficiency hit.

As far as making the system more robust goes, we are going to have to drop
SHA-2 if there is any significant compromise regardless of whether this
detail makes an exploit infeasible. It is far more expensive to explain why
faulty algorithms are safe than to switch to a safe one.

We are not shutting down use of SHA-1 because there is a real risk of a
bogus cert being generated by a competent CA. The security justification
such as it is is that the system should be fail safe and require at least
two failures before a catastrophe.

What the collision resistance property does provide is a cushion that makes
a compromise during the transition highly unlikely. And given the refusal
to consider issue of code points for SHA-3, we will probably need quite a
cushion.

On Thu, Dec 8, 2016 at 7:23 PM, Salz, Rich <[email-masked]> wrote:

> Hi there!
>
>
>
> We are looking for feedback on the following items, my memory spurred by
> the draft minutes found here:  https://datatracker.ietf.org/
> doc/minutes-97-curdle/
>
>
>
> Please review the minutes by the end of the month.  Speak up on the list
> if anything’s wrong.  Thanks to Ben Kaduk for taking them.
>
>
>
> The text in draft-ietf-curdle-pkix says CA’s MUST NOT use pre-hash version
> of signatures.  Does anyone object to this?  There is a mention of the
> trade-offs in doing that at the end of section 5.  Please respond within a
> week.
>
>
>
> Contexts – has anyone got a use for signature contexts? See the minutes.
> If you’re opposed to the (slight) consensus, speak up.
>
>
>
> Thanks.
>
>
>
> --
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Dec 2016 11:42:01 -0500

> The text in draft-ietf-curdle-pkix says CA’s MUST NOT use pre-hash version of signatures.  Does anyone object to this?  There is a mention of the trade-offs in doing that at the end of section 5.  Please respond within a week.

draft-ietf-curdle-cms-eddsa-signatures is aligned with this decision.  If it changes in one of the documents, it needs to change in both.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Dec 2016 12:33:13 -0500

On Fri, Dec 9, 2016 at 11:42 AM, Russ Housley <[email-masked]> wrote:

> draft-ietf-curdle-cms-eddsa-signatures is aligned with this decision.  If
> it changes in one of the documents, it needs to change in both.
>

​I don't think it is sustainable in CMS so if it has to be the same in both
places then we have to reject it.

In order for a crypto mode to be viable, it has to be possible to implement
it in a streaming encoder. Memory is cheap but storage is cheaper. If I
have a digital camera that is signing pictures as they are taken, that
module has to be something that can be implemented in a hardware blob
somewhere close to the point the image is captured.

Another think I have great difficulty with here is actually working out
what the pure vs free hash implementation is from the specification. trying
to describe crypto in RFC plaintext isn't a good match at the best of
times. ​This is particularly hard to follow.

---

From: Russ Housley <[email-masked]>
Date: Fri, 9 Dec 2016 12:42:23 -0500

On Dec 9, 2016, at 12:33 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> ​I don't think it is sustainable in CMS so if it has to be the same in both places then we have to reject it.
> 
> In order for a crypto mode to be viable, it has to be possible to implement it in a streaming encoder. Memory is cheap but storage is cheaper. If I have a digital camera that is signing pictures as they are taken, that module has to be something that can be implemented in a hardware blob somewhere close to the point the image is captured.
> 
> Another think I have great difficulty with here is actually working out what the pure vs free hash implementation is from the specification. trying to describe crypto in RFC plaintext isn't a good match at the best of times. ​This is particularly hard to follow.

Please take a look at the document.  The content is hashed, and that hash is placed in the message digest attribute, then the set of attributes is signed with pure EdDSA.

Russ