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

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Jun 2018 21:06:45 -0700

Ben Campbell 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:
----------------------------------------------------------------------

Thanks for this work. I'm balloting "yes", but have a few comments. I realize
some of these may be leftovers from previous versions. None are blocking, so I
leave it to the authors, WG, and AD to choose.

Substantive:

§1.3, last paragraph: Is the "SHOULD NOT" really constrained to mail? It seems
like it should apply to other messaging systems, although I can see the need to
decrypt old messages as more important for mail than for more real-time
messaging.

§2.2.1, 2nd paragraph: "...although ignoring those
   certificates is expected behavior..."
I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to _not_
ignore these certificates?

§2.3:

- The requirement to be able to handle an arbitrary number of certificates
seems like a potential DOS vector. Aspects of that are mentioned in the
security considerations. Shouldn't a receiving agent put some limits on the
number/size it will accept? Or is "fail gracefully" an acceptable strategy to
"handle" too many certs?

- 4th paragraph: "Note that
   receiving agents SHOULD NOT simply trust any self-signed certificates
   as valid CAs, but SHOULD use some other mechanism to determine if
   this is a CA that should be trusted."

Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?

§4.4, 2nd paragraph: "Some mechanism SHOULD
   exist to gracefully handle other certificate extensions when they
   appear in end-entity or CA certificates."

Can you elaborate on that? Does it imply more than discussion of the "critical"
bit in the next paragraph?

Appendix B: It seems odd to find this in an appendix.  Does this draft actually
purport to _request_ the move to historic, or just sort of wish we would do so?

Editorial:

Abstract: Should the RFC Editor remove the "Contributing to this document..."
paragraph?

§1.1:

- The definition for AC does not contain an actual definition.
- CRL definition: " prematurely" seems an odd choice of words; one assumes the
issuer does not revoke before it needs to. I assume the intent was to describe
revoking certs prior to their expiration?

§1.4 (and subsequent change version): I infer from the section titles that the
normative keywords in these sections are intended to describe requirements
added to those versions, not new requirements in _this_ version. It would be
better to make that explicit; the body text should stand alone without the
titles.

§2.2.1, 2nd paragraph: s/parser/parse

§3: Paragraph 5: " Some localities may perform other
   transformations on the local name component before doing the
   comparison, however an S/MIME client cannot know what specific
   localities do."

That's an odd statement, since software localization rules can certainly
include comparison policies. It's not material to the document, though, so I
will leave this as an editorial comment.

§4.1, first paragraph: "get information stored away from incoming messages."
I don't understand what that means. Should "away from" simply be "in"?

§4.2, first paragraph: The first sentence seems more like a statement of
principle than a normative requirement.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Jun 2018 20:06:59 -0700

Ben,

See comments inline.

EKR, Russ

There is a question below for you

> -----Original Message-----
> From: Ben Campbell <[email-masked]>
> Sent: Monday, June 18, 2018 9:07 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Russ Housley
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Ben Campbell'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.)
> 
> 
> some of these may be leftovers from previous versions. None are blocking,
> so I leave it to the authors, WG, and AD to choose.
> 
> Substantive:
> 
> §1.3, last paragraph: Is the "SHOULD NOT" really constrained to mail? It
> seems like it should apply to other messaging systems, although I can see the
> need to decrypt old messages as more important for mail than for more real-
> time messaging.

That makes sense.  It now reads

    Support of these algorithms may be needed to support historic S/MIME artifacts such as messages or files, but SHOULD NOT be used for new artifacts.

> I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to
> _not_ ignore these certificates?

Are you reading the same version I am.  I see the following text:

Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates.

I can understand that you might think that the last sentence softens this restriction, but it is targeted at the fact that the parser has to not fail.

> number/size it will accept? Or is "fail gracefully" an acceptable strategy to

Yes I can see that this might be a potential DOS vector.  I think however that you are going to run into thing like the message file is just too large to be able to process first.  There are lots of potential DOS vectors around having large things and this is just one of those possibilities.  It is also not really a good idea to put cat videos in certificates because the certificate size is going to be too large as well.  

Failing gracefully (message cannot be displayed) is an acceptable strategy in my mind to any of the - you have a problem with certificates or CRLs that are too big or too hard to process.

> Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?

Mostly because I do not want to completely rule out any TOFU applications. 

This is the text in the previous version of the document as well as there has been no discussion I don't think that I would want to change it.

> bit in the next paragraph?

I believe that this is more than just a discussion of the 'critical' bit.  Examples of this might be:

* Allow for installation of extension handlers or implement additional extensions that are not listed as MUST handles.
* Potentially provide a display mechanism for extensions which are not evaluated so that the user has the option of doing a visual inspection
* Enforce the 'critical' bit when it is set.

> purport to _request_ the move to historic, or just sort of wish we would do

I have never made up my mind about what to do this these appendixes so I just carry them forward.  The move to historical was done a couple of iterations of this document ago.

> Abstract: Should the RFC Editor remove the "Contributing to this

Yes and it is tagged that way in the XML source as a comment.

> - The definition for AC does not contain an actual definition.

It might read better if sentence 3 came first, but I think that it does contain the definition.
(This is original text)

> - CRL definition: " prematurely" seems an odd choice of words; one assumes
> the issuer does not revoke before it needs to. I assume the intent was to
> describe revoking certs prior to their expiration?

I agree that 'prematurely' is a weird word to use here.  I am going to remove that word and add the following sentence:

Certificates which are expired might not appear on a CRL even if it was revoked.

I think that is probably what was trying to be said.

> normative keywords in these sections are intended to describe
> requirements added to those versions, not new requirements in _this_
> version. It would be better to make that explicit; the body text should stand
> alone without the titles.

Yes that is what is intended to be said.  I agree and thus did not use keywords in section 1.6.

This is historic text copied from a previous version and as such I am slightly reluctant to change.
EKR and Russ - what do you think?

> §2.2.1, 2nd paragraph: s/parser/parse

Fixed

> will leave this as an editorial comment.

There was some discussion about this both here and in DANE about this problem.  The fact that google, for example, strips periods is just one of the painful things that this is meant to iignore.

> I don't understand what that means. Should "away from" simply be "in"?

s/stored away from/stored in an/

> principle than a normative requirement.

I would not have any idea how to test that statement.  Yes I agree that this is not a normative requirement.

Jim

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Jun 2018 20:26:21 -0700

On Tue, Jun 19, 2018 at 8:06 PM, Jim Schaad <[email-masked]> wrote:

> email
>     Support of these algorithms may be needed to support historic S/MIME
> artifacts such as messages or files, but SHOULD NOT be used for new
> artifacts.
>
> >
> I can understand that you might think that the last sentence softens this
> restriction, but it is targeted at the fact that the parser has to not fail.
>
> >
> > §2.3:
> >
> Yes I can see that this might be a potential DOS vector.  I think however
> that you are going to run into thing like the message file is just too
> large to be able to process first.  There are lots of potential DOS vectors
> around having large things and this is just one of those possibilities.  It
> is also not really a good idea to put cat videos in certificates because
> the certificate size is going to be too large as well.
>
> Failing gracefully (message cannot be displayed) is an acceptable strategy
> in my mind to any of the - you have a problem with certificates or CRLs
> that are too big or too hard to process.
>
> >
> This is the text in the previous version of the document as well as there
> has been no discussion I don't think that I would want to change it.
>
> >
> * Allow for installation of extension handlers or implement additional
> extensions that are not listed as MUST handles.
> * Potentially provide a display mechanism for extensions which are not
> evaluated so that the user has the option of doing a visual inspection
> > purport to _request_ the move to historic, or just sort of wish we would
> do
> > so?
>
> I have never made up my mind about what to do this these appendixes so I
> just carry them forward.  The move to historical was done a couple of
> iterations of this document ago.
>
> >
> > Editorial:
> >
> I agree that 'prematurely' is a weird word to use here.  I am going to
> remove that word and add the following sentence:
>

I don't think it's a big deal, but maybe a note?

-Ekr

> There was some discussion about this both here and in DANE about this
> problem.  The fact that google, for example, strips periods is just one of
> the painful things that this is meant to iignore.
>
> >
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Jun 2018 23:03:23 -0500

Thanks for the response. Some followup comments inline, with sections removed that seem to be resolved:

Thanks!

Ben.

> On Jun 19, 2018, at 10:06 PM, Jim Schaad <[email-masked]> wrote:
> 
> Ben,
> 
> See comments inline.
> 
> EKR, Russ
> 

[…]

> I can understand that you might think that the last sentence softens this restriction, but it is targeted at the fact that the parser has to not fail.

Hmm, maybe I just lost state between the sentences; I agree there’s no need for normative language. But I do think “expected behavior” could be stated more strongly. Maybe “intended behavior”?

> Yes I can see that this might be a potential DOS vector.  I think however that you are going to run into thing like the message file is just too large to be able to process first.  There are lots o…

I agree with those points, but if someone interpreted “handle” to mean “process”, they could interpret this text to prohibit normal approaches for dealing with “too large” messages.  (Yes, this is pedantic, but so is normative language :-) )

> Failing gracefully (message cannot be displayed) is an acceptable strategy in my mind to any of the - you have a problem with certificates or CRLs that are too big or too hard to process.

I think some words to that effect in the draft would be helpful.

> Mostly because I do not want to completely rule out any TOFU applications.

I think a mention of TOFU would be helpful in understanding the SHOULD. (But even those do more than “simply trust”, don’t they? At least, many of them warn the user what is happening.)

> This is the text in the previous version of the document as well as there has been no discussion I don't think that I would want to change it.

It is, after all, a non-blocking comment :-)

> * Enforce the 'critical' bit when it is set.

I think some “For example…” text to that effect could be helpful.

> I have never made up my mind about what to do this these appendixes so I just carry them forward.  The move to historical was done a couple of iterations of this document ago.

Sigh—I should have checked on that before commenting. Never mind :-)

(Although it wouldn’t hurt to update it to say this has already happened.)

> It might read better if sentence 3 came first, but I think that it does contain the definition.

You are right, it does. Nevermind.

[…]

> EKR and Russ - what do you think?

It’s not a big deal one way or another, but a simple note that says “Version X.Y added the following:” would help.

[…]

> There was some discussion about this both here and in DANE about this problem.  The fact that google, for example, strips periods is just one of the painful things that this is meant to iignore.

Ah, I think the word “localities” made me think we were talking about localization in an I18n sense. Perhaps “Some domains may perform…”?

[…]

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Jun 2018 11:01:35 -0400

> EKR and Russ - what do you think?

Picking one example:

   Version 2 attribute certificates SHOULD be supported, and version 1
   attributes certificates MUST NOT be used.

This does accurately reflect the change that was made from S/MIME v3 to S/MIME v3.1.

It could be reworded to avoid the upper case words, but it might loose some important nuance.

For example, it might say instead:

  Encourage the support for version 2 attribute certificates, and
  deprecate support for version 1 attribute certificates.

Is there an IESG preference for the use of upper case words in sections that describe the history of a protocol?

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Jun 2018 11:11:52 -0400

> It’s not a big deal one way or another, but a simple note that says “Version X.Y added the following:” would help.

I do not understand your suggestion.  This document specifies Version 4.0, and these sections describe the evolution from version 3 (the first one that the IETF produced) to this version.

1.4.  Changes from S/MIME v3 to S/MIME v3.1
1.5.  Changes from S/MIME v3.1 to S/MIME v3.2
1.6.  Changes since S/MIME 3.2

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Jun 2018 08:25:56 -0700

Russ,

My understanding is that the following is all that is needed.

Add a new paragraph to the top of each of the sections which says

This section describes the changes that were made to S/MIME when it was upgraded from S/MIME 3.1 to S/MIME v3.2.

This means one is not reliant on the section title but it is part of the text.

Jim

From: Russ Housley <[email-masked]> 
Sent: Wednesday, June 20, 2018 8:12 AM
To: Ben Campbell <[email-masked]>
Cc: Jim Schaad <[email-masked]>; SPASM <[email-masked]>; IESG <[email-masked]>; [email-masked]
Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)

Ben:

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Jun 2018 11:33:27 -0400

Jim:

I see.  That is easy.

Russ

> On Jun 20, 2018, at 11:25 AM, Jim Schaad <[email-masked]> wrote:
> 
> Russ,
>  
> From: Russ Housley <[email-masked] <mailto:[email-masked]>> 
> To: Ben Campbell <[email-masked] <mailto:[email-masked]>>
> Cc: Jim Schaad <[email-masked] <mailto:[email-masked]>>; SPASM <[email-masked] <mailto:[email-masked]>>; IESG <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Jun 2018 22:11:23 -0500

Right—it’s really just a nit. The heading already has the information; but IMO it should be repeated in the body.

 Context: I (and I am given to believe I am not alone in this) seem to have some cognitive weirdness in that I often fail to notice information in headings, labels, title bars, subject lines, UI chrome, etc unless I actively look for it. Repeating the information in the body makes it easier for to read, at least for me.

> On Jun 20, 2018, at 10:25 AM, Jim Schaad <[email-masked]> wrote:
> 
> Russ,
>