Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

Apologies for the slow reply here. (I was on vacation.) Ned: thanks for the clear summary. I'll start working on those issues. Dave: thanks also for the direct feedback. To be honest, though, after all this discussion, I'm somewhat struggling to sort out what's actionable from what isn't, as I

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

On Thu, Apr 12, 2018 at 10:27:25AM +0100, Dave Cridland wrote: > > Unfortunately, per-MTA rather than per-domain policy entirely loses all > > protection against active attacks when the MX RRset is not secure. The > > MiTM just forges the MX RRset, yielding new hosts for which no policy > > is

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

On 12 April 2018 at 03:23, Viktor Dukhovni wrote: > > > > On Apr 11, 2018, at 6:52 PM, Dave Cridland wrote: > > > > Well, one assumes that an MTA gives out the policy for the MTA, not the > domain, but otherwise I take your points. I don't think that

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

> On Apr 11, 2018, at 6:52 PM, Dave Cridland wrote: > > Well, one assumes that an MTA gives out the policy for the MTA, not the > domain, but otherwise I take your points. I don't think that we'd end up in a > place markedly different, with the exception that it'd be MTA

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

> > > 2) HTTPS Call-out > > > > > Given the policy is essentially trust-on-first-use, it's not clear to me > > > why much of the STS policy cannot be transferred within SMTP itself, > > > perhaps in response to the EHLO issued after STARTTLS completes. This is > > > good enough for HTTPS's STS

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

On 11 April 2018 at 16:40, Ned Freed wrote: > > > However, it surprises me that the MTA-STS draft does not appear to note > > this prior art at all, and this makes me wonder whether it was even on > the > > radar. > > The relevance of POSH was discussed as recently as March

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

On 11 April 2018 at 19:20, Viktor Dukhovni wrote: > > > > On Apr 11, 2018, at 7:38 AM, Dave Cridland wrote: > > > > 2) HTTPS Call-out > > > > Given the policy is essentially trust-on-first-use, it's not clear to me > why much of the STS policy cannot

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

> On Apr 11, 2018, at 7:38 AM, Dave Cridland wrote: > > 2) HTTPS Call-out > > Given the policy is essentially trust-on-first-use, it's not clear to me why > much of the STS policy cannot be transferred within SMTP itself, perhaps in > response to the EHLO issued after

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

> On Apr 11, 2018, at 11:40 AM, ned+i...@mauve.mrochek.com wrote: > >> For reference, the XMPP community has a high penetration of DANE records >> (around 10% of the self-selected group who test their servers through >> community tooling) and a very high penetration of CA-signed certificates >>

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

Since this was mentioned to me at IETF 101, I managed to find the time to look it up and review. Several design decisions have left me confused; most notably the notion of a call-out to HTTPS in the first place. Much of the document is unclear to me, despite having a background of both Internet

Re: [Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

I have finally found the time to work on my own implementation of MTA-STS. As is often the case when actually implementing the specification, it has turned up a number of issues of varying levels of severity, which I'm listing in no particular order. (1) Both RFC 7405 and RFC 5234 should be

[Uta] Last Call: (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

The IESG has received a request from the Using TLS in Applications WG (uta) to consider the following document: - 'SMTP MTA Strict Transport Security (MTA-STS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please