Re: [Uta] RequireTLS: Revised text on message origination

Hi Rolf, On 4/15/19 2:06 PM, Rolf E. Sonneveld wrote: > Hi, Jim, > > On 12-04-19 21:44, Jim Fenton wrote: >> >> One of the significant discussions at the Prague meeting (and >> originally resulting from IESG comments) was that the Section 6, >> "Mailing list considerations" was incomplete because

Re: [Uta] RequireTLS: Revised text on message origination

Hi, Jim, On 12-04-19 21:44, Jim Fenton wrote: One of the significant discussions at the Prague meeting (and originally resulting from IESG comments) was that the Section 6, "Mailing list considerations" was incomplete because it didn't consider other causes of origination such as Sieve and

[Uta] RequireTLS: Revised text on message origination

One of the significant discussions at the Prague meeting (and originally resulting from IESG comments) was that the Section 6, "Mailing list considerations" was incomplete because it didn't consider other causes of origination such as Sieve and vacation programs. So I have drafted an alternative

Re: [Uta] REQUIRETLS and MX spoofing

Hi, so, I believe we have a consensus here. We have had plenty of time for everybody to express his/her opinion. Jim, please, update your draft so that I can move it forward. Regards, Valery (for the chairs). > > Chairs: Let me know when you determine that we have rough consensus > > and I'll

Re: [Uta] REQUIRETLS and MX spoofing

Exactly right on both counts. It's quite probably working as intended, but it *is* a strange user experience. I think the only alternatives (similar to my original email) would be to not do authn at all or to dictate one specific mechanism for authn, neither of which are obviously better. So I

Re: [Uta] REQUIRETLS and MX spoofing

Let me make sure I have the issue straight: A user who uses REQUIRETLS from a location (or going through a downstream mail server) that doesn't do DNSSEC verification will not be able to send to domains that don't publish MTA-STS. Is that correct? I agree, it makes sense to call this out. But

Re: [Uta] REQUIRETLS and MX spoofing

Hi Jim, > Chairs: Let me know when you determine that we have rough consensus and > I'll revise the draft. I believe we're very close to consensus here. But the I-D submission window is already closed anyway. When it's already open we'll declare the consensus. So, if someone has different

Re: [Uta] REQUIRETLS and MX spoofing

> On Oct 23, 2018, at 5:05 PM, Jim Fenton wrote: > >> And yet, my preference would have been to not take this approach. >> Rather each domain that wants to support "REQUIRETLS=YES", would >> need to implement MTA-STS or DANE. If they already have a signed >> MX RRset, they could often just add

Re: [Uta] REQUIRETLS and MX spoofing

On 10/22/18 3:02 PM, Viktor Dukhovni wrote: On Mon, Oct 22, 2018 at 11:46:27AM +0200, Daniel Margolis wrote: Close, but this conflates two issues: (1) making sure that the MX record hasn't been forged (which MTA-STS or DNSSEC in the mailbox domain will do) and authenticating the mail server

Re: [Uta] REQUIRETLS and MX spoofing

On Mon, Oct 22, 2018 at 11:46:27AM +0200, Daniel Margolis wrote: > > Close, but this conflates two issues: (1) making sure that the MX record > > hasn't been forged (which MTA-STS or DNSSEC in the mailbox domain will do) > > and authenticating the mail server (which the certificate chain or DANE

Re: [Uta] REQUIRETLS and MX spoofing

Thanks for your response, Dan. Comments inline. On 10/19/18 10:40 AM, Daniel Margolis wrote: Hey Jim, I've been too busy to follow along on REQUIRETLS closely, unfortunately, so I may be missing some context. Feel free to ignore: One caveat on your last statement is that, /alone/, you

[Uta] REQUIRETLS and MX spoofing

On 8/23/18 6:49 PM, Viktor Dukhovni wrote: This is recognized in the Security Considerations: Another active attack involves the spoofing of DNS MX records of the recipient domain. An attacker having this capability could cause the message to be redirected to a mail server under the

Re: [Uta] RequireTLS: NO

> On Mar 26, 2018, at 1:15 PM, Jim Fenton wrote: > > Header field munging is an ugly business, and (as an individual) I am > opposed to it, especially since this doesn't seem to be a very > compelling usage. As document editor, I haven't heard WG consensus to > include

Re: [Uta] RequireTLS: NO

On 3/23/18 1:19 AM, Tim Hollebeek wrote: >> to (easy with e.g. Postfix header_checks): >> >> Require-TLS: NO >> Subject: [insecure-delivery]: actual subject >> >> or (not easy with header_checks, but hides the subject tag): >> >> Require-TLS: NO >> Subject: actual subject > I

Re: [Uta] RequireTLS: NO

> On Mar 23, 2018, at 5:26 AM, Kurt Andersen (b) wrote: > > If the message is DKIM signed at the origin, then tampering with the Subject > header field will be verboten under most signing practices which include the > Subject header. Typically, both DKIM signing, and any

Re: [Uta] RequireTLS: NO

Hi, > On Mar 23, 2018, at 4:19 AM, Tim Hollebeek wrote: > > Of course, someone could add the [insecure-delivery] to the > subject using an MTA that doesn't add Require-TLS, potentially > fooling someone, but I don't offhand see any serious security > consequences of

Re: [Uta] RequireTLS: NO

On Fri, Mar 23, 2018 at 8:19 AM, Tim Hollebeek wrote: > > > to (easy with e.g. Postfix header_checks): > > > > Require-TLS: NO > > Subject: [insecure-delivery]: actual subject > > > > or (not easy with header_checks, but hides the subject tag): > > > >

Re: [Uta] RequireTLS: NO

> > On Mar 22, 2018, at 3:59 PM, Daniel Kahn Gillmor > > wrote: > > > > can't they opt-out by re-sending to their submission agent without the > > REQUIRETLS SMTP command? or is the fear that their submission agent > > will invoke REQUIRETLS on the next hop without the

Re: [Uta] RequireTLS: NO

> On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote: > >> On Mar 22, 2018, at 2:59 PM, Martin Thomson > >> wrote: > >> > >> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is > >> relevant. > > > > A reasonable guiding principle, but sometimes

Re: [Uta] RequireTLS: NO

> On Mar 22, 2018, at 3:59 PM, Daniel Kahn Gillmor > wrote: > > can't they opt-out by re-sending to their submission agent without the > REQUIRETLS SMTP command? or is the fear that their submission agent > will invoke REQUIRETLS on the next hop without the user's

Re: [Uta] RequireTLS: NO

On 3/22/18 12:59 PM, Daniel Kahn Gillmor wrote: > On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote: >>> On Mar 22, 2018, at 2:59 PM, Martin Thomson >>> wrote: >>> >>> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is >>> relevant. >> A

Re: [Uta] RequireTLS: NO

On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote: >> On Mar 22, 2018, at 2:59 PM, Martin Thomson wrote: >> >> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is >> relevant. > > A reasonable guiding principle, but sometimes *availability*

Re: [Uta] RequireTLS: NO

> On Mar 22, 2018, at 2:59 PM, Martin Thomson wrote: > > https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is > relevant. A reasonable guiding principle, but sometimes *availability* trumps security. This is sufficiently often the case with email

Re: [Uta] REQUIRETLS vs. headers

> On Nov 17, 2017, at 4:02 AM, Jim Fenton wrote: > >> b. Messages may get filtered via procmail and the like >> and then forwarded, and again the delivery channel >> has no means to preserve REQUIRETLS=YES except via a >> header. > > Let me think about

Re: [Uta] REQUIRETLS vs. headers

On 11/16/17 3:49 PM, Viktor Dukhovni wrote: > 1. I agree that REQUIRETLS=NO needs a header so it can be >tunnelled via an "agnostic" MTA. > > 2. However, even REQUIRETLS=YES needs a header, because: > >a. Within an MTA a message may make multiple internal > hops, for example

[Uta] REQUIRETLS vs. headers

1. I agree that REQUIRETLS=NO needs a header so it can be tunnelled via an "agnostic" MTA. 2. However, even REQUIRETLS=YES needs a header, because: a. Within an MTA a message may make multiple internal hops, for example processing via a loopback SMTP proxy that does virus

Re: [Uta] REQUIRETLS update

On 12/16/16 3:31 PM, Viktor Dukhovni wrote: >> On Dec 16, 2016, at 5:53 PM, Jim Fenton wrote: >> >> It seems that Viktor and I have differing views on the usefulness of >> MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense to >> have two mechanisms for

Re: [Uta] REQUIRETLS update

> On Dec 16, 2016, at 5:53 PM, Jim Fenton wrote: > > It seems that Viktor and I have differing views on the usefulness of > MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense to > have two mechanisms for this, so I will try to formulate a hybrid >

Re: [Uta] REQUIRETLS update

On 12/10/16 1:55 AM, ned+...@mrochek.com wrote: >> On Fri, Dec 09, 2016 at 04:13:08PM -, John Levine wrote: What would (for example) be the result if a client requested both the REQUIRETLS and a separate MAYTLS feature? >>> Given that mail servers will do whatever they wany with

Re: [Uta] REQUIRETLS update

> On Fri, Dec 09, 2016 at 04:13:08PM -, John Levine wrote: > > >What would (for example) be the result if a client requested both > > >the REQUIRETLS and a separate MAYTLS feature? > > > > Given that mail servers will do whatever they wany with REQUIRETLS > > suggestions, I wouldn't obsess

Re: [Uta] REQUIRETLS update

> > On Dec 9, 2016, at 5:40 PM, Arvel Hathcock wrote: > > > > +1. I'm for keeping this proposal as simple as possible. > The result would be substantial lack of orthogonality, with multiple > overlapping specifications, that would then be able to conflict with > each

Re: [Uta] REQUIRETLS update

On Fri, Dec 09, 2016 at 04:13:08PM -, John Levine wrote: > >What would (for example) be the result if a client requested both > >the REQUIRETLS and a separate MAYTLS feature? > > Given that mail servers will do whatever they wany with REQUIRETLS > suggestions, I wouldn't obsess about this.

Re: [Uta] REQUIRETLS update

>What would (for example) be the result if a client requested both >the REQUIRETLS and a separate MAYTLS feature? Given that mail servers will do whatever they wany with REQUIRETLS suggestions, I wouldn't obsess about this. R's, John ___ Uta mailing

Re: [Uta] REQUIRETLS update

> On Dec 9, 2016, at 5:40 PM, Arvel Hathcock wrote: > > +1. I'm for keeping this proposal as simple as possible. The result would be substantial lack of orthogonality, with multiple overlapping specifications, that would then be able to conflict with each other. What

Re: [Uta] REQUIRETLS update

I disagree. If that is a need, it should be a separate specification. Otherwise we bikeshed REQUIRETLS to death. +1. I'm for keeping this proposal as simple as possible. Arvel signature.asc Description: PGP signature ___ Uta mailing list

Re: [Uta] REQUIRETLS update

> On Dec 7, 2016, at 2:28 PM, Jim Fenton wrote: > > As for usefulness, I tend to think of a (potentially) multi-hop > store-and-forward protocol like SMTP as being the wrong way to send an > urgent message in the first place. There are lots of operational snafus > that

Re: [Uta] REQUIRETLS update

> On Dec 7, 2016, at 4:33 AM, Jeremy Harris wrote: > > > I disagree. If that is a need, it should be a separate specification. > Otherwise we bikeshed REQUIRETLS to death. I don't see how extending the specification to cover both of the complementary behaviours brings

Re: [Uta] REQUIRETLS update

On Tue, Dec 06, 2016 at 04:30:32PM -0800, Jim Fenton wrote: > It has been a little while, so I thought it might be appropriate to give > the WG an update on the status of REQUIRETLS > (draft-fenton-smtp-require-tls-02). Is there any new thinking on supporting user signalling of TLS opt-out?

[Uta] REQUIRETLS update

It has been a little while, so I thought it might be appropriate to give the WG an update on the status of REQUIRETLS (draft-fenton-smtp-require-tls-02). There are now two prototype implementations: - Exim implementation by Jeremy Harris (announced on UTA list on 2 September) - MDaemon

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On Sun, Mar 27, 2016 at 08:17:28PM -0700, Jim Fenton wrote: > >> I have received suggestions that there also be options to require > >> specific TLS version, cipher suites, PFS, etc. as well, and my gut feel > >> is that's getting too specific. > > > Don't let this be over-engineered. That's a

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 3/25/16 3:19 PM, Viktor Dukhovni wrote: > On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote: > >>> If the entire goal is to ensure the integrity of the RFC 6125 >>> "reference identifier" used to authenticate the nexthop SMTP >>> server, then it is perhaps a good idea to

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On March 24, 2016 at 12:42:07 , Jim Fenton (fen...@bluepopcorn.net) wrote: Not to distract from the STS discussion, but I thought I'd point out  another approach to SMTP TLS 'encouragement' that I submitted a few  weeks ago: draft-fenton-smtp-require-tls-01. There has been some  discussion of this

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote: > > If the entire goal is to ensure the integrity of the RFC 6125 > > "reference identifier" used to authenticate the nexthop SMTP > > server, then it is perhaps a good idea to say so explicitly. > > The primary purpose was

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 11:24 AM, Viktor Dukhovni wrote: > On Thu, Mar 24, 2016 at 07:12:43PM -0700, Jim Fenton wrote: > >> Not to distract from the STS discussion, but I thought I'd point out >> another approach to SMTP TLS 'encouragement' that I submitted a few >> weeks ago:

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 07:24 AM, Jeremy Harris wrote: > On 25/03/16 02:12, Jim Fenton wrote: >> draft-fenton-smtp-require-tls-01 >> The idea here is that REQUIRETLS allows the SMTP client to override the >> default "deliver even if you can't do it securely" behavior of SMTP. The >> philosophy is that the

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 03/25/2016 06:45 AM, Jeremy Harris wrote: > On 25/03/16 12:09, Aaron Zauner wrote: >>> On 25 Mar 2016, at 03:12, Jim Fenton wrote: >>> REQUIRETLS is an SMTP service extension that allows an SMTP client to >>> specify (via a MAIL FROM option) that a given message must be

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

Thank you, Jim. Definitely should be a part of the conversation. You are on the Agenda! Orit. > -Original Message- > From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Jim Fenton > Sent: Thursday, March 24, 2016 7:13 PM > To: uta@ietf.org > Subject: [Uta] REQUIRETLS: a

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

>- The draft does not mention alias-style forwarding done by an MTA; > perhaps it could? A 1-1 alias would seems to be easily covered, > but 1-to-many (mail-exploder) aliases may need more thought. The whole draft presumes that intermediate hops will follow instructions from the sender,

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 25/03/16 02:12, Jim Fenton wrote: > draft-fenton-smtp-require-tls-01 > The idea here is that REQUIRETLS allows the SMTP client to override the > default "deliver even if you can't do it securely" behavior of SMTP. The > philosophy is that the sender of the message (SMTP client) is in the >

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

On 25/03/16 12:09, Aaron Zauner wrote: >> On 25 Mar 2016, at 03:12, Jim Fenton wrote: >> REQUIRETLS is an SMTP service extension that allows an SMTP client to >> specify (via a MAIL FROM option) that a given message must be sent over >> a TLS protected session with

[Uta] REQUIRETLS: another SMTP TLS mechanism

Not to distract from the STS discussion, but I thought I'd point out another approach to SMTP TLS 'encouragement' that I submitted a few weeks ago: draft-fenton-smtp-require-tls-01. There has been some discussion of this draft, primarily on the ietf-smtp mailing list and a little on the perpass