Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

[John Mattsson <[e-mail]>]

Hi Mohit,



A P-256 ECDH public key does not _require_ 33 bytes. EDHOC uses 32 bytes compact representation [RFC 6090] and there are a lot of people arguing that HPKE should do the same.



3GPP 5G already uses the 33 bytes compressed format from SECG in SUCI (I wrote part of that specification) but I now think it was a mistake.



The change from 32 to 33 bytes encoding affects more than just size. Forcing the implementation to calculate a y-coordinate significantly slows down the calculations as a x-coordinate only ladder cannot be used. I don’t think this change is good.



Also, referring to both 186-4 and SECG for the encoding seems strange. If the 33 byte encoding is kept, I think SECG only is enough.



John

From: Emu <[e-mail]> on behalf of Mohit Sethi M <mohit.m.sethi=[e-mail]>
Date: Thursday, 9 July 2020 at 08:46
To: Russ Housley <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt


Rene, Russ, and I had an offline email exchange about this issue. I think we are now in agreement that the public key for the NIST P-256 curve requires at least 33 bytes (in the compressed format).

Thus, we should update the draft to reflect the correct key size. Adding a reference to https://www.secg.org/SEC2-Ver-1.0.pdf<https://protect2.fireeye.com/v1/url?k=ee7f4584-b0df87c2-ee7f051f-86fc6812c361-2b60805fe723aebc&q=1&e=8fc33e3e-797f-4645-8a58-9177a3822ce7&u=https%3A%2F%2Fwww.secg.org%2FSEC2-Ver-1.0.pdf> and explicitly mentioning the use of the compressed format would also be beneficial.

--Mohit
On 6/24/20 11:04 PM, Russ Housley wrote:

The ECDH public value in RFC 5480 is an OCTET STRING, which means that the value is exactly 32 bytes.  When this gets carried as a subject public key in a certificate, there is an extra byte only because the type is a BIT STRING.



My conclusion is that the current draft is correct:



      *  For P-256, the length of this value is 32 bytes, encoded in

         binary as specified in [FIPS186-4].



Russ







On Jun 24, 2020, at 1:10 AM, Mohit Sethi M <mohit.m.sethi=[e-mail]><mailto:mohit.m.sethi=[e-mail]> wrote:



Hi all,



I am not a crypto expert and my knowledge of public key encodings is

based on my work with Rene Struik for a different draft.



The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the

length of this value is 32 bytes, encoded in binary". Shouldn't this be

33 bytes? And wouldn't it make sense to explicitly say that this is an

octet string in the compressed format while referencing "SEC 1: Elliptic

Curve Cryptography, Version 2.0" for the point to octet string

conversion rules?



--Mohit



On 5/26/20 9:57 AM, [e-mail]<mailto:[e-mail]> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the EAP Method Update WG of the IETF.



        Title           : Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)

        Authors         : Jari Arkko

                          Karl Norrman

                          Vesa Torvinen

       Filename        : draft-ietf-emu-aka-pfs-04.txt

       Pages           : 26

       Date            : 2020-05-25



Abstract:

   Many different attacks have been reported as part of revelations

   associated with pervasive surveillance.  Some of the reported attacks

   involved compromising smart cards, such as attacking SIM card

   manufacturers and operators in an effort to compromise shared secrets

   stored on these cards.  Since the publication of those reports,

   manufacturing and provisioning processes have gained much scrutiny

   and have improved.  However, the danger of resourceful attackers for

   these systems is still a concern.



   This specification is an optional extension to the EAP-AKA'

   authentication method which was defined in [I-D.ietf-emu-rfc5448bis].

   The extension, when negotiated, provides Perfect Forward Secrecy for

   the session key generated as a part of the authentication run in EAP-

   AKA'.  This prevents an attacker who has gained access to the long-

   term pre-shared secret in a SIM card from being able to decrypt any

   past communications.  In addition, if the attacker stays merely a

   passive eavesdropper, the extension prevents attacks against future

   sessions.  This forces attackers to use active attacks instead.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04

https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/





_______________________________________________

Emu mailing list

[e-mail]<mailto:[e-mail]>

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

_______________________________________________

Emu mailing list

[e-mail]<mailto:[e-mail]>

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

_______________________________________________

Emu mailing list

[e-mail]<mailto:[e-mail]>

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