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

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Fri, 9 Dec 2016 13:46:42 +0000

Hi Rich and all,

From: Curdle <[email-masked]<mailto:[email-masked]>> on behalf of "Salz, Rich" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 8, 2016 at 7:23 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Curdle] Some work for the group

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.

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.

We already know that there are situations people are going to use the pre-hash option and there are no security issues with it, but we say that "MUST NOT use it"  which is odd to me.

Therefore, the "MUST NOT" requirement for the pre-hash option is not appropriate in my opinion.

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]<mailto:[email-masked]> Twitter: RichSalz

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 09 Dec 2016 16:04:52 +0100

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. 
> 

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)

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.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Dec 2016 13:26:57 +0000

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

There are concerns about software being "tricked" into becoming a signing oracle, not just the data format being secure.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 12 Dec 2016 13:29:14 +0000

From: "Salz, Rich" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 12, 2016 at 8:26 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Curdle] Some work for the group

Can you explain that: I don't understand ?

Quynh.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 12 Dec 2016 14:13:03 +0000

Thank you for the explanation.

If an implementation could have that serious error, then we can say anything could happen I guess. If that happened, the signature won't get verified.

Quynh.

From: "Salz, Rich" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 12, 2016 at 8:35 AM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Curdle] Some work for the group

Software could have an API that wasn't fed the original document, but instead the pre-hashed document.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 12 Dec 2016 14:22:47 -0800

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, December 09, 2016 7:05 AM
> To: Dang, Quynh (Fed) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [Curdle] Some work for the group
> 
> Moreover, I don't quite follow the rationale for having it a must not on some
> scenarios. Of the options:

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.

> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 13 Dec 2016 12:09:21 +0000

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos Mavrogiannopoulos' <[email-masked]<mailto:[email-masked]>>, 'Quynh' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Curdle] Some work for the group

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Nikos
Mavrogiannopoulos
Sent: Friday, December 09, 2016 7:05 AM
To: Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
Subject: Re: [Curdle] Some work for the group
On Fri, 2016-12-09 at 13:46 +0000, Dang, Quynh (Fed) wrote:
> on Jim's slides.
I agree.

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.

I appreciate your work and contributions!

Quynh.

Jim

regards,
Nikos
_______________________________________________
Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: Jim Schaad <[email-masked]>
Date: Tue, 13 Dec 2016 12:30:33 -0800

From: Dang, Quynh (Fed) [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2016 4:09 AM
To: Jim Schaad <[email-masked]>; 'Nikos Mavrogiannopoulos'
<[email-masked]>; Dang, Quynh (Fed) <[email-masked]>;
[email-masked]; [email-masked]
Subject: Re: [Curdle] Some work for the group

From: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Date: Monday, December 12, 2016 at 5:22 PM
To: 'Nikos Mavrogiannopoulos' <[email-masked]>, 'Quynh'
<[email-masked] <mailto:[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >,
"[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: RE: [Curdle] Some work for the group

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

Mavrogiannopoulos

To: Dang, Quynh (Fed) <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ;

[email-masked] <mailto:[email-masked]> 

> 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

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

Quynh. 

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

option (3).

better.

create an

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

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

Jim

regards,

Nikos

Curdle mailing list

[email-masked] <mailto:[email-masked]>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 14 Dec 2016 15:02:22 +0000

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 13, 2016 at 3:30 PM
To: 'Quynh' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Curdle] Some work for the group

From: Dang, Quynh (Fed) [mailto:[email-masked]]
Sent: Tuesday, December 13, 2016 4:09 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; 'Nikos Mavrogiannopoulos' <[email-masked]<mailto:[email-masked]>>; Dang, Quynh (Fed) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Curdle] Some work for the group

-----Original Message-----
I agree.

Hi Jim,

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.

Hi Jim,

I am not sure I understand what you think is a security issue here? Could you please explain?

Thank you,
Quynh.

Jim

Quynh.

Jim

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 15 Dec 2016 09:03:12 +0100

On Mon, 2016-12-12 at 14:22 -0800, Jim Schaad wrote:

> > achieve, but

That is exactly my point with the MUST NOT requirement.

regards,
Nikos

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Dec 2016 11:33:35 -0500

It looks to me as if in effect the prehash vs pure issue is going to settle
out into a situation where all signatures are pure signatures at the
specification level with an additional hash being introduced in the
packaging layer where bulk data is involved.

I have implemented most of the popular packaging formats and most of my API
calls internally turn out to be for a 'sign and digest' operation rather
than Sign-this-digest. Most cases the bulk data is being put through a
digest that is then put into some other structure for signature. There is
almost always some sort of metadata you want in there in addition to the
content.

Another way to look at this is that Ed255x is a drop in replacement for RSA
Signature that removes the restriction on the size of the input data to be
signed but not the requirement for it to be buffered. Most packaging
formats end up being a signature over a small chunk of static data which in
the case of streamed content are virtually always reference to external
data.