Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF

[Keith Moore <[e-mail]>]

Strictly speaking, 8314 does not prefer 465 over 587.  It prefers 
Implicit TLS over STARTTLS.

The default port for submission over Implicit TLS is 465, but a client 
and server can use a different port by mutual agreement.

The default port for submission over cleartext (upgradable using 
STARTTLS if both client and server support it) is 587, but again, a 
different port can be used by mutual agreement.

8314 prefers Implicit TLS over STARTTLS (because it's harder for an 
attacker [or middlebox] to hijack a TLS connection that starts at TCP 
Open than for an attacker to hijack an ordinary TCP connection that is 
subsequently upgraded to use TLS using STARTTLS).    But either type of 
connection is permitted and considered secure for user interface 
purposes as long as the connection otherwise meets minimum 
confidentiality requirements. One implication is that there's no 
requirement in 8314 for mail service providers to shift customers to 
Implicit TLS if they're already using STARTTLS.  (But ideally mail 
service providers would support Implicit TLS if they're not already 
doing so.)

But the intention in 8314 was that this choice of Implicit TLS vs. 
STARTTLS should be made at account configuration time, NOT on a 
per-session basis.   Unfortunately it now appears to me that the 
language that should have made this clear was inadvertently removed in a 
late edit (but still prior to Last Call).

Keith

On 7/22/20 8:18 AM, Дилян Палаузов wrote:
> Hello,
>
> > G.6.  Clarify where the protocol stands with respect to submission 
> and TLS issues
> > 1.  submission on port 587 or port 465
>
> RFC 8314 says in the Introduction:
>
> “This memo now recommends that:
>
> o Connections to Mail Submission Servers and Mail Access Servers be 
> made using "Implicit TLS" (as defined below), in preference to 
> connecting to the "cleartext" port and negotiating TLS using the 
> STARTTLS command or a similar command.”
>
> My reading is thay the above text clarifies to prefer 465 over 587.
>
> Greetings
> Дилян
>
> На 22 юли 2020 г. 14:49:46 GMT+03:00, Alexey Melnikov 
> <[e-mail]> написа:
>
>     Revision of core Email specifications (emailcore) agenda for [virtual]
>     Madrid.
>
>
>     WEDNESDAY, July 29, 2020 (UTC)
>     11:00-12:40 (1 hour 40 mins)
>
>
>     Agenda bashing, introduction, meeting format (chairs) -  5 mins
>     Problem statement (chairs) -  5 mins
>
>     Review of proposed changes to "Internet Message Format" (RFC 5322)
>     draft-resnick-rfc5322bis - 15 mins
>
>        Issue with ABNF for "field":https://www.rfc-editor.org/errata/eid2950
>        Disallow empty quoted string:https://www.rfc-editor.org/errata/eid3135
>        Header field name length limit:https://www.rfc-editor.org/errata/eid5918
>
>
>     Triage of raised issues for "Simple Mail Transfer Protocol" (RFC 5321)
>     draft-klensin-rfc5321bis - 10 mins
>
>     Example topics (we tackle as many as we have time for)
>
>        G.9.  Revisiting Quoted Strings
>
>        G.7.11.  Bring back 1yz reply codes?
>
>     Core Email Applicability Statement: - 35 mins
>
>        G.6.  Clarify where the protocol stands with respect to submission and
>              TLS issues
>
>          1.  submission on port 587 or port 465
>
>          2.  TLS relay on a port different from 25 (whenever)
>
>        Suggested SMTP Extensions:
>         G.8.  Enhanced Reply Codes and DSNs
>         8BITMIME
>         SMTPUTF8 (a.k.a. EAI)
>
>        Terminology:
>         G.3.  Meaning of "MTA" and Related Terminology
>         G.7.2.  SMTP Model, terminology, and relationship to RFC 5598
>         G.11.  SMTP Clients, Servers, Senders, and Receivers
>
>        G.1.  IP Address Literals in EHLO, MAIL or RCPT
>
>        G.7.3.  Resolvable FQDNs and private domain names
>
>        G.10.  Internationalization Consideration section needed?
>
>
>     High level discussion of how the proposed WG going to decide
>     which issues to tackle (chairs) -  5 mins
>
>     Charter Review and discussion (chairs) - 25 mins
>
>
>
>     Documents:
>        https://datatracker.ietf.org/doc/draft-resnick-rfc5322bis/?include_text=1
>        https://www.rfc-editor.org/errata_search.php?rfc=5322&rec_status=15&presentation=table
>        https://datatracker.ietf.org/doc/draft-klensin-rfc5321bis/?include_text=1
>        https://www.rfc-editor.org/errata_search.php?rfc=5321&rec_status=15&presentation=table
>        https://datatracker.ietf.org/doc/draft-klensin-email-core-as/?include_text=1
>     ------------------------------------------------------------------------
>     If we go too quickly through triage of some issues, here are some others
>     that
>     we can discuss:
>
>     G.5.  Remove or deprecate the work-around from code 552 to 452
>
>          The suggestion in Section 4.5.3.1.10 may have outlived its usefulness
>          and/or be inconsistent with current practice.  Should it be removed
>          and/or explicitly deprecated?
>
>     G.7.1.  Issues with 521, 554, and 556 codes
>
>          See new Section 4.2.4.2.  More text may be needed, there or
>          elsewhere, about choices of codes in response to initial opening and
>          to EHLO, especially to deal with selective policy rejections.
>     ------------------------------------------------------------------------
>     ietf-smtp mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp