Re: [Crypto-panel] Stage 5 of PAKE selection process

[Yaron Sheffer <[e-mail]>]

Dear CFRG chairs,

Please see my review in the attached (two formats). 

Thanks,
	Yaron

PS: this is formatted as an I-D, but I have not submitted it, at least while the chairs are deliberating their selections.

On 24/10/2019, 20:00, "Crypto-panel on behalf of Russ Housley" <[e-mail] on behalf of [e-mail]> wrote:

    Reviewer: Russ Housley
    Review Date: 24 October 2019
    
    CFRG is looking for a PAKE to support TLS 1.3 and IKEv2.  TLS 1.3 has
    a very rigid handshake in terms of the number of messages that are
    exchanged.  IKEv2 has mechanisms to accomodate the exchange os many
    messages as part of authentication.  As a result, I focus on TLS 1.3.
    Any PAKE that will work with TLS 1.3 will also work with IKEv2.
    
    RECOMMENDATION: OPAQUE
    
    
    Observations about each of the candidates follow.
    
    
    J-PAKE
    
    J-PAKE requires significant computation, even when elliptic curve is
    used.
    
    J-PAKE has big messages, even when elliptic curve is used.
    
    J-PAKE is a two round (or three round) protocol, so it does not easily
    fit into the TLS handshake.
    
    
    CPace
    
    CPAKE requires two elliptic curve operations by each party, one to
    compute an ephemeral public value from the ephemeral random (private)
    value and one to compute the shared secret.
    
    CPake requires the pre-establishment of an session identifier (sid).
    Perhaps this is done when the password is established, but the
    requirements are not clear to me.  The sid is sent by both the initiator
    and the responder.  Assuming the sid is not bigger than an ephemeral
    public value, the message sizes seem reasonable.
    
    CPAKE is a one round protocol, so it easily fits into the TLS handshake.
    
    CPake requires a check that the "point order is sufficient for
    security parameter 2k".  I could not figure out the check to be
    performed.  Maybe I did not spend enough time searching for it ...
    
    
    AuCPace
    
    AuCPAKE requires two elliptic curve operations by each party, one to
    compute an ephemeral public value from the ephemeral random (private)
    value and one to compute the shared secret.
    
    AuCPake requires the pre-establishment of an session identifier (sid).
    Perhaps this is done when the password is established, but the
    requirements are not clear to me.  It also requires a sub-session
    identifier (ssid) that can be a concatenation of the nonces from the
    TLS handshake or computed from them.  Assuming the sid is not bigger
    than an ephemeral public value, the message sizes seem reasonable.
    
    AuCPAKE requires more than one round trip, so it does not easily fits
    into the TLS handshake.
    
    AuCPake requires a check that the "point order is sufficient for
    security parameter 2k".  I could not figure out the check to be
    performed.  Maybe I did not spend enough time searching for it ...
    
    
    OPAQUE
    
    OPAQUE computational cost is determined by OPRF, Diffie-Hellman, and
    authentication.  The OPRF requires two elliptic curve operations for the
    client and one for the server.  The Diffie-Hellman requires two elliptic
    curve operations for each party.  If authentication uses signature, then
    each party will have to generate and verify one signature.
    
    OPAQUE requires two private key operations by each party during
    registration, and then just one private key operation by each party
    to compute the shared secret.
    
    OPAQUE is a one round protocol; it easily fits into the TLS handshake.
    
    If one is willing to employ an extra round trip, OPAQUE can provide
    confidentiality of the user's name by encrypting it in the TLS
    handshake key.  It seems like this could be implemented as TLS-in-TLS.
    
    OPAQUE needs an AEAD that includes "key committing".  AES-GCM mode does
    not provide this property, but I think that AES-KEY-WRAP mode does.  It
    seems straightforward to enhance an AEAD to get this property by adding
    a all-zero block to the plaintext and checking it on decryption.
    
    
    SPAKE2
    
    SPAKE2 computational cost is four elliptic curve operations for each
    party after the pre-provisioning takes place.
    
    SPAKE2 is a two round protocol, but the pre-provisioning will take place
    prior to any handshake, so it easily fits into the TLS handshake.  That
    said, if the point associated with the system-wide elements M and N
    become known, then an offline dictionary attack becomes possible.
    
    I found this part odd:
    
               TT = len(A) || A || len(B) || B || len(S) || S
                 || len(T) || T || len(K) || K || len(w) || w
    
       If an identity is absent, it is omitted from the transcript entirely.
    
    So, if A or B is absent, the inputs quite similar:
    
               TT = len(B) || B || len(S) || S || len(T) || T
                 || len(K) || K || len(w) || w
    
               TT = len(A) || A || len(S) || S || len(T) || T
                 || len(K) || K || len(w) || w
    
    Somehow, using a zero length for the missing identity seems safer:
    
               TT = len(nil)    || len(B) || B || len(S) || S
                 || len(T) || T || len(K) || K || len(w) || w
    
               TT = len(A) || A || len(nil)    || len(S) || S
                 || len(T) || T || len(K) || K || len(w) || w
    
    
    SPEKE
    
    SPEKE computational cost is two elliptic curve operations for each
    party.
    
    SPEKE is a one round protocol, so it easily fits into the TLS
    handshake.  Also, the TLS 1.3 Finished message provides the
    optional key confirmation.  Finally, identity and session-unique
    values are easily accommodated by the client and server Hello
    messages.
    
    
    VTBPEKE
    
    VTBPEKE computational cost is four elliptic curve operations for each
    party.
    
    VTBPEKE is not a one round protocol, cannot be accommodated by the
    TLS 1.3 handshake.
    
    VTBPEKE offers forward secrecy.  However, if the points associated with
    the system-wide element U and V become known, then an offline dictionary
    attack becomes possible.
    
    
    BSPAKE
    
    BSPAKE computational cost is five elliptic curve operations for the
    client and four elliptic curve operations for the server.
    
    BSPAKE requires two-round trips in the protocol, so it cannot be
    accommodated by the TLS 1.3 handshake.
    
    
     
    
    _______________________________________________
    Crypto-panel mailing list
    [e-mail]
    https://www.irtf.org/mailman/listinfo/crypto-panel