Hello dear John. John C Klensin wrote in <754BDA476FBC0C25FC616750@PSB>: |Personal request and request on behalf of the EMAILCORE WG. I hope |none of it is controversial. I am also assuming that everyone |participating in this discussion agrees that a revised, Internet |Standard, SMTP spec is a reasonable goal. If anyone's goal is just |to kill the document (and/or think they can kill SMTP by killing this |document), I don't have anything constructive to say to you... but I |hope there are no such people. | |It looks to me as if the best possibility for sorting out these |issues, including the boundary between the SMTP spec |(draft-ietf-emailcore-rfc5321bis) and the email Applicability |Statement (draft-ietf-emailcore-as) is going to be the EMAILCORE |meeting Thursday of next week. Unless Alexey can arrange additional |time and people can get to a second slot on short notice, that |meeting is only scheduled for an hour and efficiency and focus are |therefore important. | |Alexey has assigned ticket numbers to what seemed to be the important |issues (at least as of several days ago)[2] and I posted |draft-ietf-emailcore-rfc5321bis-32 in the hope of helping to focus |the discussions. I am still hoping to get -33 posted this weekend |with additional issues and suggestions included. | |Also, Ken posted draft-ietf-emailcore-as-12 at the beginning of last |week. It already contains text discussing opportunistic TLS and |STARTTLS. For your interest, i will also post draft-nurpmeso-smtp-tls-srv-01 on Sunday night. (Unfortunately the data tracker is closed, a circumstance that yet escaped me. Is this closing and the duration posted on announce@? Then the miss is even more fatal.) It will include (that is, i am a greenhorn, but in the end it is a greenhorn's draft) - updates="" + updates="3207 5321 5598" because + and the email architecture security considerations + (<xref target="RFC5598"/>, section 6.1) do not yet cover + explorability of transport security. as well as a very large Rationale due to some private email of an IETF reader who read my draft, and said so: + <section anchor="Rationale"> + <name>Rationale</name> + <t> + Plenty of methods have been standardized by the IETF to perform + service TLS capability discovery for SMTP. + They have in common that they represent SMTP specific solutions + to a problem that most, if not all other protocols address via + the means this document thus reiterates for SMTP. + They represent further development effort and error surfaces. + They also impose increased administration effort, + and, due to this, are inaccessible to a large number, if not + the majority, of private email server operators: + either through additional costs, the impossibility to set up + a dedicated name server, if so required, + and, also as a superset of the former, + restrictive web interfaces that support only a minimal set of + DNS<xref target="RFC1035"/> + resource record types. + Finally they, especially looking forward, disallow the business + model where a provider manages + DNSSEC<xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/> + for basic user DNS entries, + created via some kind of web interface. + </t><t> + There is for example + MTA-STS<xref target="RFC8461"/> + which requires SMTP operators to install and maintain a HTTP + protocol server, + accessible on the usual HTTP/S ports + and the same domain as the email service, + and subject to the now usual web server and DNS (traffic) attacks. + Dependent on the software this may require non-trivial and error + prone path access policy server rules. + </t><t> + Another example are the newer + SVCB<xref target="RFC9460"/> + DNS resource records. + They support a plethora of additional options, + and one could say that, with hindsight to + TLS Encrypted Client Hello<xref target="I-D.ietf-tls-svcb-ech"/>, + using SVCB would reduce DNS traffic. + SVCB, however, just like many other IETF designed DNS RR types, + is often not available in web interfaces providers make available + to normal end users. + Furthermore, and that is the authors opinion, they are problematic, + especially regarding SMTP, in that they again would represent + a special approach for SMTP compared to other email protocols, + and that includes + SUBMISSION<xref target="RFC6409"/> + which effectively is identical to SMTP. + (The author believes email should be as easy as possible to setup + and use for end users.) + </t><t> + Also in the authors opinion we now start mixing the model, view, + controller paradigm with SVCB. + Which leads to + DANE for SMTP<xref target="RFC7672"/>. + Unfortunately + DNSSEC<xref target="RFC4033"/><xref target="RFC4034"/><xref target="RFC4035"/> + is still consciously unsupported by major players as of today, + and provider web interfaces do often not allow users placement + of the necessary DANE resource records in addition, + as of the time of this writing. + However, discovering a (TLS enabled) email service via SRV records, + thereafter checking for applicability of + DNS-Based Authentication of Named Entities (DANE)<xref target="RFC6698"/>, + possibly even + Using Raw Public Keys in Transport Layer Security (TLS)<xref target="RFC7250"/> + would be a bright future that addresses a lot of today's issues. + </t> + </section> |I'm busy this week. Perhaps less busy than those who start traveling |to Dublin soon, but if I need to keep reading the "SECDIR Review.." |thread, the back-and-forth discussions, and responding when that |seems important, it is likely that I will not be able to get to -33 |early enough to be really helpful in focusing the meeting. |Similarly, if additional ticket numbers need to be assigned, |minimizing the extra traffic Alexey (and Ken) need to deal with |between a meeting they are now attending and early next week seems to |be a good idea. | |So, four requests: | |(1) Take the important parts of this discussion to the EMAILCORE list |[1] and follow that list (at least until the end of next week) |because useful discussions are likely to appear there and probably |not on the Last-Call list. | |(2) If you want to make a case for inclusion of "STARTTLS" in |rfc5321bis, explain why that is desirable and necessary and why your |reasons are stronger than the ones that have caused the WG to decide |to not do hat, reasons that have been explained in this Last Call |discussion. And propose text, if only because it is probably clear |from these discussions that I'm the wrong person to make an initial |proposal for how to include it. Real mail security lies only in end-to-end methods involving the message bodies, such as those that use digital signatures (see RFC 1847 [26] and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [50] or Secure/ Multipurpose Internet Mail Extensions (S/MIME) in RFC 8551 [46]) <<. >> as well as DKIM(6376) host signatures. Making use of encrypted transport channels(3207) reduces the risk of malicious actors breaking such signatures, or totally avoids it in one hop message transfer. Upon graceful DNSSEC(4033,4034,4035) and DANE(6698; also 7250) coverage risk reduction of encrypted channels will be very high, or at least expose malicious actors more easily. Using encrypted channels is therefore RECOMMENDET. While here i want to mention your RFC 6409 section "7. Interaction with SMTP Extensions". Something like this is well worth inclusion in 5321bis, and like this a single section could replace an entire A/S document. |(3) No matter how you feel about (2), please review Section 6 of |draft-ietf-emailcore-as-12. If you think it is adequate, the WG |should know that. If not, specific suggestions (not just complaints) |would be greatly appreciated. Also, if you have not looked at |draft-ietf-emailcore-rfc5321bis-32, or at least the diffs from -31, |this would be a good time so that any aspect of the Last Call |discussion on which I have messed up or left out can be reflected, at |least as notes, in -33. Please check the ticket list too. | |(4) For (2) and (3), try, if possible, to summarize your position |and/or suggestions in a way that would make an easy addition to an |agenda page and/or a "meeting materials" collection. If we have only |an hour and you have a position you consider important, that is the |best way to have it considered. And, if possible, try to attend next |week's meeting at IETF (in person or remote as appropriate). | |thanks, | john | |[1] https://www.ietf.org/mailman/listinfo/emailcore |[2] https://github.com/ietf-wg-emailcore/emailcore/issues Even though off-topic i cannot read github without mentioning that it blocks certain countries, for reasons which are absolutely not understandable in real reality. It violates masses of UN resolutions supported by hundreds of countries to isolate members of the given list. Which, in my opinion, counteracts the "I" in IETF. |-- |Emailcore mailing list -- emailcore@xxxxxxxx |To unsubscribe send an email to emailcore-leave@xxxxxxxx --End of <754BDA476FBC0C25FC616750@PSB> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself fore'er and e'er | |Farewell, dear collar bear -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
