Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 12:11:12 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-rfc5750-bis-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Lots of good comments from Ben et al; I tried to trim duplicates from my own.

Section 1.2

   The term RSA in this document almost always refers to the PKCS#1 v1.5
   RSA signature algorithm even when not qualified as such.  There are a
   couple of places where it refers to the general RSA cryptographic
   operation, these can be determined from the context where it is used.

nit: this is a comma splice; I suggest using a semicolon instead.

Section 2

   [...] Most of
   the CMS format for S/MIME messages is defined in [RFC5751].

We cite 5751bis elsewhere; is the non-bis reference intentional?

Section 2.3

   [...] Receiving S/MIME agents SHOULD be able to
   handle messages without certificates using a database or directory
   lookup scheme.

Maybe clarify that this lookup is to obtain the certificates (and chain) in
question?

Section 3

   Note that this attribute MUST be encoded as IA5String and has an
   upper bound of 255 characters.  The right side of the email address
   SHOULD be treated as ASCII-case-insensitive.

What does "treated as" mean here?  Is it limited to "for comparison
purposes"?  Am I expected to normalize for display?  (I guess enforcing the
ASCII range is inherent in IA5String, so checking that is out of scope.)
The next paragraph has a MUST-level case-insensitive comparison, so maybe
this whole sentence is redundant?

   [...] A receiving agent SHOULD provide some explicit
   alternate processing of the message if this comparison fails, this
   might be done by displaying or logging a message that shows the
   recipient the mail addresses in the certificate or other certificate
   details.

nit: This is another comma splice.

Section 4.3

Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA-PSS
with SHA-256?

Section 4.4

   The PKIX Working Group has ongoing efforts to identify and create
   extensions that have value in particular certification environments.

Isn't the PKIX WG closed?

   [...] Other extensions may be included, but those extensions
   SHOULD NOT be marked as critical.

Is this a candidate for a 2119 MAY?

Section 6

   In addition to the Security Considerations identified in [RFC5280],
   caution should be taken when processing certificates that have not
   first been validated to a trust anchor.  Certificates could be
   manufactured by untrusted sources for the purpose of mounting denial
   of service or other attacks.  For example, keys selected to require
   excessive cryptographic processing, or extensive lists of CRL
   Distribution Point (CDP) and/or Authority Information Access (AIA)
   addresses in the certificate, could be used to mount denial-of-
   service attacks.  Similarly, attacker-specified CDP and/or AIA
   addresses could be included in fake certificates to allow the
   originator to detect receipt of the message even if signature
   verification fails.

Should malformed/misencoded/strangely-encoded certificates be included in
the list of examples here?  Historically, ASN.1 parsers have been unfortunately
fragile, after all.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Jun 2018 12:34:46 -0700

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, June 20, 2018 12:11 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Russ Housley
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 

Hence why we have hired copy editors. (done)  If they change it back I am going to come and haunt you.

> We cite 5751bis elsewhere; is the non-bis reference intentional?

No this was a miss on my part.

> Maybe clarify that this lookup is to obtain the certificates (and chain) in

Nit - but ok

> ASCII range is inherent in IA5String, so checking that is out of scope.) The
> next paragraph has a MUST-level case-insensitive comparison, so maybe this
> whole sentence is redundant?
> 
> Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA-
> PSS with SHA-256?

Big long discussion on this, but mostly because EdDSA has overtaken RSASSA-PSS in the mind share of the world.

> Isn't the PKIX WG closed?

You mean that you haven't been invited to the secret PKIX WG meetings at the IETF meetings? 

Swapped to LAMPS.

> Is this a candidate for a 2119 MAY?

No not really, marking things a critical is a hinderance to interoperability rather than promoting it.  The selection of SHOULD NOT rather than MAY indicates this by saying that if you want to do this you should probably reconsider that decision unless you have a really good case to do so.

> Should malformed/misencoded/strangely-encoded certificates be included
> in the list of examples here?  Historically, ASN.1 parsers have been
> unfortunately fragile, after all.

No I don't think so.  That would really be a general warning that would apply to every thing included in an S/MIME message.  After all it cold be the CRLs or the signature info structure that could have the same problem.  I expect that people really ought to know to deal with this problem already.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 14:42:31 -0500

Trimming the easily resolved bits...

> Big long discussion on this, but mostly because EdDSA has overtaken RSASSA-PSS in the mind share of the world.

Maybe we could have a little text in Appendix A, then?

> No not really, marking things a critical is a hinderance to interoperability rather than promoting it.  The selection of SHOULD NOT rather than MAY indicates this by saying that if you want to do t…

Whoops, I was talking about "MAY be included", not the "SHOULD NOT be
marked as critical".  But I could go either way; it's kind of a statement
of fact.

-Benjamin

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Jun 2018 13:41:39 -0700

> Sent: Wednesday, June 20, 2018 12:43 PM
> To: Jim Schaad <[email-masked]>
> Cc: 'The IESG' <[email-masked]>; [email-masked];
'Russ
> Housley' <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's Yes on draft-ietf-lamps-rfc5750-bis-06:
(with
> > > Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for
> > > RSASSA- PSS with SHA-256?
> >
> > Big long discussion on this, but mostly because EdDSA has overtaken
> RSASSA-PSS in the mind share of the world.
> 

Putting it in Appendix A seems really wrong because it is not a historical
algorithm.  I am reluctant to do this because the only reason why we have
discussed why algorithms are changing is because they are no longer
considered to be of sufficient strength.  The plus basically says this is
our best guess of what is going to happen when we right the algorithm.  That
best guess has changed and different people are going to have different
ideas of why it changed.  It boils down from it was a SHOULD and it is now a
SHOULD we just don't think it is where the world is headed at the moment.
This could change next year if something really unexpected happens. 

> > No not really, marking things a critical is a hinderance to
interoperability
> rather than promoting it.  The selection of SHOULD NOT rather than MAY
> indicates this by saying that if you want to do this you should probably
> reconsider that decision unless you have a really good case to do so.
> 
of fact.

I think that is a very poor use of the word MAY.  On the other hand for the
most part I don't like MAY in general because the sentences that include it
are not written in a way which is useful.

So - No.

Jim

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Jun 2018 15:58:31 -0500

Just to close the loop: thanks for the extra responses; your proposal
to not change the document text seems reasonable to me, now.

-Benjamin