Subject: [smime] [Technical Errata Reported] RFC2631 (5954)

From: RFC Errata System <[email-masked]>
Date: Thu, 2 Jan 2020 12:42:20 -0800 (PST)

The following errata report has been submitted for RFC2631,
"Diffie-Hellman Key Agreement Method".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5954

--------------------------------------
Type: Technical
Reported by: Paul Janson <[email-masked]>

Section: 2.1.5.

Original Text
-------------
     1. Verify that y lies within the interval [2,p-1]. If it does not,
        the key is invalid.
     2. Compute y^q mod p. If the result == 1, the key is valid.
        Otherwise the key is invalid.

Corrected Text
--------------
     1. Verify that y lies within the interval [2,p-1]. If it does not,
        the key is invalid.
     2. Compute y^q mod p. If the result == 1, the key is valid.
        Otherwise the key is invalid.
|    3. Verify that y does not match g.

Notes
-----
Validating that (g == received y) needs to be an additional exclusion to the valid range [2,p-1]. If party 'a' accepts received public key 'yb' matching 'g', then ZZ matches  public key 'ya'. i.e. if yb = 2, then xb = 1, therefore ZZ = ya^1 = ya

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC2631 (draft-ietf-smime-x942-07)
--------------------------------------
Title               : Diffie-Hellman Key Agreement Method
Publication Date    : June 1999
Author(s)           : E. Rescorla
Category            : PROPOSED STANDARD
Source              : S/MIME Mail Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 Jan 2020 19:36:45 -0800

I could maybe see making this Hold For Document Update, as it would
probably require some discussion, and it's hard to say that this was an
omission at the time of original publication.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Wed, 8 Jan 2020 10:17:28 -0500

Ben:

It sounds like Hold for Document Update is the best way to handle this one.

Russ

> On Jan 7, 2020, at 10:36 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 10 Jan 2020 01:41:56 +0000

>It sounds like Hold for Document Update is the best way to handle this one.

The urgency would also depend on what's affected by it, since it only affects
FIPS 186-style keys which AFAIK nothing uses for DH, everything uses PKCS #3
keys with g=2 (see e.g. RFC 2409, RFC 3526, and RFC 7919).

Peter.