Re: [Curdle] Some work for the group

From: Dang, Quynh (Fed) [mailto:quynh.dang@nist.gov] 
Sent: Tuesday, December 13, 2016 4:09 AM
To: Jim Schaad <ietf@augustcellars.com>; 'Nikos Mavrogiannopoulos'
<nmav@redhat.com>; Dang, Quynh (Fed) <quynh.dang@nist.gov>;
rsalz@akamai.com; curdle@ietf.org
Subject: Re: [Curdle] Some work for the group

From: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos Mavrogiannopoulos' <nmav@redhat.com>, 'Quynh'
<Quynh.Dang@nist.gov <mailto:Quynh.Dang@nist.gov> >, "rsalz@akamai.com
<mailto:rsalz@akamai.com> " <rsalz@akamai.com <mailto:rsalz@akamai.com> >,
"curdle@ietf.org <mailto:curdle@ietf.org> " <curdle@ietf.org
<mailto:curdle@ietf.org> >
Subject: RE: [Curdle] Some work for the group

-----Original Message-----

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Nikos

Mavrogiannopoulos

Sent: Friday, December 09, 2016 7:05 AM

To: Dang, Quynh (Fed) <quynh.dang@nist.gov <mailto:quynh.dang@nist.gov> >;
rsalz@akamai.com <mailto:rsalz@akamai.com> ;

curdle@ietf.org <mailto:curdle@ietf.org> 

Subject: Re: [Curdle] Some work for the group

On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote:

> There are no security issues with the pre-hash option. One more hash

> does not create any performance issues for the current protocols.  In

> addition, the pre-hash option provides the need for long messages as

> we know: one example is the long CRLs on small devices as pointed out

> on Jim's slides.

> 

> If I had to choose one algorithm which works well for all situations,

> I would choose the pre-hash option.

I agree.

Moreover, I don't quite follow the rationale for having it a must not on
some

scenarios. Of the options:

1. CA uses SECP256R1 (no prehash)

2. CA uses Ed25519R1 (prehash)

3. CA uses Ed25519R1 (no prehash)

I am going to assume that this is just a typo as the prehash and no prehash
are reversed on the above list.  

There is one low level argument that I have found for forbidding the
pre-hash version for Ed25519.   There is a possibility that if the pre-hash
version is allowed somebody is going to implement it incorrectly and do the
pre-hash as the item to be signed for pure mode as that is what is currently
available.  The current restrictions would avoid this possibility for
certificates but not for other uses.

Hi Jim, 

Don't people check or test their implementations.  It is hard for me to
imagine why when someone does not want to use the pre-hash, decides to
implement the non pre-hash version, but ended implementing the pre-hash
version, then don't check or test his or her implementation at all. 

Quynh,

No, this is I implement the pure version and somebody else abuses it and
uses it as a pre-hash version.  That is they do what comes naturally today.

Jim

I appreciate your work and contributions!

Quynh. 

the 3rd is banned. I kind of understand what the authors try to achieve, but

adding local policies into RFCs does not make much sense (especially if the

policy is dubious as in this case; one option with this particular curve is
banned,

with the other curves it is fine). The option (2) is apparently better than
3, but I

do not see why the existence of better option should prevent a CA from using

option (3).

Similar argumentation could be made for banning Ed25519R1 since Ed441 is

better.

I instead propose 2 alternatives, (a) remove the prehash option, or (b)
create an

RFC mandating policies for CAs, which algorithms they MUST use and which
not.

A CA can chose to follow them.

I think that option B would be more for the CA Consortium that for the IETF
to do. 

Jim

regards,

Nikos

_______________________________________________

Curdle mailing list

Curdle@ietf.org <mailto:Curdle@ietf.org> 

https://www.ietf.org/mailman/listinfo/curdle