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

> 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

> 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 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] I-D Action: draft-ietf-uta-smtp-require-tls-02.txt

On 11 Apr 2018, at 14:29, Jim Fenton wrote: Thanks for your review, Chris: On 4/9/18 6:08 PM, Chris Newman wrote: 3. The IANA considerations are incomplete. For example, they are missing fields required to register in the SMTP mail system response codes registry. See RFC 5248. I'm not sure

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] I-D Action: draft-ietf-uta-smtp-require-tls-02.txt

Thanks for your review, Chris: On 4/9/18 6:08 PM, Chris Newman wrote: > On 6 Apr 2018, at 16:20, Jim Fenton wrote: >> The major change in this version is the removal of the options (CHAIN, >> DANE, and DNSSEC) from the REQUIRETLS SMTP option as discussed in >> London. There were also

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

[Uta] Digression on DANE for MTAs implementation difficulty, followups off-list are likely best.

> On Apr 11, 2018, at 11:40 AM, ned+...@mrochek.com wrote: > > I've also looked at implementing DANE, and IMO it's a major PITA to implement, > so much so that it would take substantial customer interest to make me do it - > interest that has not materialized. [ Not really on topic for this

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