Guidance on End-to-End E-mail Security
draft-ietf-lamps-e2e-mail-guidance-16

Yes

Roman Danyliw
(Martin Duke)
(Robert Wilton)

No Objection

Erik Kline
Francesca Palombini
Jim Guichard
John Scudder
Murray Kucherawy
Paul Wouters
(Andrew Alston)

Note: This ballot was opened for revision 14 and is now closed.

Roman Danyliw
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2024-03-06 for -15) Not sent 
Thank you for the work on this document.

Many thanks to Bron Gondwana for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/24oSbxr5AekpwXi8-jjTugihxSU/.
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-03-06 for -15) Sent 
Thanks for working on this. Once this document has become an RFC I look forward to the day, soon I'm sure, when end-to-end e-mail [is] simple and secure for the end user.
Murray Kucherawy
(was Discuss) No Objection
Comment (2024-03-07 for -15) Sent 
Thanks for this.  It's well written and provides good coverage of the material.  I'll be going to YES once the DISCUSS is resolved.

Given the use of BCP 14 keywords in this document, I would prefer this be done as a BCP or a Standards Track document (specifically, an Applicability Statement).  It really is specifying something that's got compliance requirements and use of existing protocols to achieve a particular outcome.  You might even consider Experimental if you're simply not sure about how robust the advice in here is.  The IESG will take up some future discussion about what guidance we might want to provide for future efforts like this one.

I'm curious: If there are no committed or planned implementations, what was the source for most of this advice?  Prior working groups in the area of email security, like DKIM and DMARC, have firmly avoided providing any sort of user interface advice on the basis that we simply do not have experience from which to develop such advice.  I'm wondering what's different now.

The discussion about lock icons and such was interesting.  Over on the DKIM list, there was some recent discussion about whether such user indications are useful at all, whether they highlight security or non-security of a message.  Some studies were cited that suggest these simply have never worked.
Paul Wouters
(was Discuss) No Objection
Comment (2024-03-17) Sent 
Thanks for the discussion and the text changes. I've updated my ballot to No Objection.
Martin Duke Former IESG member
Yes
Yes (2024-03-05 for -15) Sent 
Thanks for this document.

Would it be worthwhile to discuss the handling of encrypted email with obsolete ciphers, as is done in (6.4) for signatures?
Robert Wilton Former IESG member
Yes
Yes (2024-03-04 for -15) Sent 
Hi,

Thanks for this document. I'm no expert on the email related RFCs but I found this document to be very well written, being both easy to read and understand.

I was considering balloting 'DISCUSS' on this document because I think that it should really be a BCP rather than Informational.  Was BCP considered (the shepherd writeup doesn't indicate) and dismissed?

Anyway, I have a few other minor/nit level comments for the authors consideration:


Minor level comments:

(1) p 14, sec 4.1.1.4.  S/MIME PKCS7 authEnveloped-data Cryptographic Layer

   Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data
   (Section 4.1.1.4) have identical message structure and very similar
   semantics.  The only difference between the two is ciphertext
   malleability.

I was slightly confused by the statement that they offer very similar semantics when one of them offers integrity and the other does not, at least according to the explanations accompanying them.


(2) p 26, sec 6.4.  Signature failures

   A conformant MUA MUST NOT render a message with a failed signature as
   more dangerous or more dubious than a comparable message without any
   signature at all.  In both cases, the Cryptographic Summary should be
   Unprotected.

Does it still make sense to flag the failed signature at all, e.g., so potentially the receiver can warn the sender that their signature is failing?



Nit level comments:

(3) p 30, sec 7.3.  MIME Part Examples

   In this case, parts M and N are still the Cryptographic Envelope.

are still => are still in?


(4) p 31, sec 8.1.1.  Peer Certificate Selection

   *  It must have a subjectAltName of type rfc822Name whose contents
      match the destination address.  In particular, the local-part of
      the two addresses should be an exact bytewise match, and the
      domain parts of the two addresses should be matched by ensuring
      label equivalence across the full domain name, as described in
      Section 2.3.2.4 of [RFC5890].

For clarity, perhaps "destination address" => "destination e-mail address".

Regards,
Rob
Andrew Alston Former IESG member
No Objection
No Objection (for -15) Not sent