Re: [Cfrg] I-D Action: draft-irtf-cfrg-eddsa-08.txt

[Ilari Liusvaara <[e-mail]>]

On Thu, Aug 25, 2016 at 03:02:15PM -0700, Jim Schaad wrote:
> 
> 
> > -----Original Message-----
> > From: Cfrg [mailto:[e-mail]] On Behalf Of Yoav Nir
> > Sent: Thursday, August 25, 2016 2:07 PM
> > To: <[e-mail]> <[e-mail]>
> > Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-eddsa-08.txt
> > 
> > Hi.
> > 
> > I’ve read this draft in the context of writing both RFC4492bis for TLS and draft-
> > nir-ipsecme-eddsa for IPsecME. So of course I’m mainly interested in selecting
> > the right variant for each key length. I’ll get back to that, bit first some things
> > that I found that I don’t think are clear enough:
> > 
> > Section 10.3 begins like this:
> >    Contexts can be used to separate uses of the protocol between
> >    different protocols (which is very hard to reliably do otherwise)
> > 
> > So I think you meant to separate uses of the *algorithm* between
> > different protocols.

Actually, uses of the same key between different protocols (of the level
that handle signatures).

These uses are actually very difficult to separate besides labeling
the key with the protocol it is used with (which sometimes is not an
option).
 
E.g. TLS server signatures and PKIX CSRs are signed by the same RSA or
ECDSA keypairs. No separation (nor can it reasonably be added), but
fortunately those don't seem to interact in nasty ways.

However, with some pairs that might use the same keys, one is not so
lucky... But best not to mix keys between protocols unless absolutely
necressary (given the problems signatures have).

> > The section proceeds to give some warnings about using contexts. The first
> > paragraph requires not to use parts of the message for the context, but prohibits
> > this with a SHOULD NOT. No explanation is given as to why not, nor in what
> > cases you would do so anyway (it is a SHOULD NOT rather than a MUST NOT).
> > The third paragraph is about percolating the context string through APIs which
> > currently do not have context parameters. That is pretty clear although I don’t
> > like the re-use of the word “protocol” at the very end. I think API is more
> > correct.
> > 
> > The second paragraph, I don’t understand:
> >       Contexts SHOULD NOT be used oppurtunistically, as that kind of use
> >       is very error-prone.  If contexts are used, one SHOULD require all
> >       signature schemes avaiable for use in that purpose support
> >       contexts.
> > 
> > What does that even mean? AFAIK EdDSA is the only scheme with contexts. So if
> > I plan to use EdDSA with context I SHOULD use contexts in, say, RSA? That can’t
> > work, so should I use contexts only when EdDSA is the only defined signature
> > algorithm for the protocol? I don’t think that’s what was meant.
> 
> The reading that I have from the text and which is enforced from other
> messages from Ilari is that he is saying don't use a context string unless
> all of the signature algorithms allow for the use of context strings. 
> So I believe that is exactly what is meant.

Right.

(Making contextualized RSA-based or ECDSA-based signature scheme is not
difficult).


> > Section 10.5 explains well the considerations for choosing between 25519 and
> > 448. It also makes the case for not using the pre-hashed version if it can be
> > avoided. Then there’s this text about contexts:
> >    Ed25519ctx and Ed448 have contexts.  However, this is balanced by the
> >    problems noted in section about contexts.
> >    On implementation front, Ed25519 is widely implemented, and has many
> >    high-quality implementations.  The others have much worse support.
> > 
> > I’m assuming that “section about contexts” is 10.3. Might be worth to clarify
> > that with a reference. And I’m guessing the problems noted are the ones in that
> > second paragraph, although I still don’t understand why it is error-prone.

It is not error-prone. Using contexts plays hell with interfaces (which are
usually not designed to take the new input).

> > So with all that in mind, which variants should I choose for TLS and IKE?
> > Obviously the pre-hashed variants are out, as there is a SHOULD NOT against
> > their use and neither TLS nor IKE sign any prohibitively large messages. These are
> > not like the multi-megabyte CRLs discussed recently on the curdle list. So it
> > comes down to contexts. Do I define some context strings like “IKEv2 Initiator
> > Sign”, “TLS Server Sign”, etc. Or do I use the non-context (or empty context)
> > versions because both protocols also support other signature schemes such as
> > RSA, DSA and ECDSA?
> 
> I wonder if the SHOULD NOT on pre-hash algorithms cannot be eased with the most
> recent updates to the document.

Ed25519ph is still problematic (in a different way now, an implementation
problem, not a security problem).

> At this point I am not sure that context strings are going to be useful.
> In the PKIX and CMS contexts I am planning on pushing the empty string or
> absent context.

Taking interfaces into account, contexts probably are pretty much useless.


-Ilari