Re: [Uta] New proposal: SMTP Strict Transport Security

not to implement it. But I think the way I'm going to handle it is by building on top of an existing minimal https client we already have, and adding additional capabilties as the need arises. And if that causes ongoing interoperability issues, that's

Re: [Uta] draft-brotman-mta-sts/

ay be limited to getting the necessary certificates. And DNS names, of course. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] MTA STS and HTTPS fetch timeouts

nt, and I intend to ignore anything that makes that a requirement.) In regards to timeouts, once we get down to it I'm likely to be very concerned about the need to access DNS TTL information as well. IME a lot of DNS APIs don't provide access to this information.

Re: [Uta] REQUIRETLS update

> the feature that more users would actually want more of the > time. I'm in complete agreement with Viktor here. This is a case of complification masquerading as simplicity. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] REQUIRETLS update

. To the point where I cannot possibly justify implementing this proposal unless it also includes the MAY option, which looks to me to be far more useful. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] MTA-STS-03 review

recovery > after the fact by signalling the availability of an updated policy. > I would also like to encourage the authors to post revised drafts > more frequently. Please see: > https://www.ietf.org/mail-archive/web/ietf/current/threads.html#101804 +1000.

Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

Please post a revised draft with these changes sooner rather than later. Thanks. Ned > Sounds like we go back to underscore-prefixed. Thanks for the feedback > John. > On Wed, Mar 1, 2017 at 5:55 AM, John Levine wrote: > > In article

Re: [Uta] Require TLS=NO is very much needed

ght. I'm with Viktor on this one. Having two documents where only one is needed will not only create redundant material that needs to be kept in sync, it's more stuff people implementing this have to read. This is already too complicated and spread over too many specif

Re: [Uta] Benjamin Kaduk's No Objection on draft-ietf-uta-mta-sts-17: (with COMMENT)

not the case in the current document. The problem with including the id in the policy is that now you have a gap no matter how you order the update. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-23.txt

; can uncompress to unreasonably large outputs. > Applications might want to set limits on the amount > of data they're willing to extract from the compressed > stream. That's covered in the format's security considerations, but of course it could be repeated here if you think it's important to

Re: [Uta] I-D Action: draft-ietf-uta-smtp-tlsrpt-23.txt

y are not blocking objections. Whereas in my capacity as media type suffix reviewer, it's my responsibility to make sure that security considerations cover the full range of possible isssues. As such, coverage of an obvious one, especially given the current widespread attacks on similar formats, is a

Re: [Uta] Updated TLSRPT

e were no problems currently, nothing prevents someone from writing new software based on guarantees the standards provide in regards to the meaning of media type suffixes. Ned _______ Uta mailing list Uta@ietf.org https://www.ie

Re: [Uta] Updated TLSRPT

nderstanding of the rest of the media type name or its parameters. So unless you have a time machine and can go back and change the rules defining +json, structured syntax suffixes, content type parameters, etc. this is a nonstarter. Ned _

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

d not just for specified hosts. > > > > Of course that's the commitment. How could it be otherwise? > > > Then that needs rephrasing, because I didn't see any "Of course" about it. > A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated > TLS, using reference identifiers as listed. > (I'm trying to guess what was meant by "for the specified MX hosts".) The entire point of the mechanism is to say that the policy domain supports and wants SSL/TLS transfers and that the servers have validated certs with the specified names. So I really don't understand what you're getting at here. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

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

y domain literals" or something stronger. That's it for now. I should note that my implementation is incomplete, and I expect I will have more comments once I've worked through the SMTP client additions. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] RequireTLS: NO

on > any sane UI/UX story for how a troubleshooter manages to introduce it -- > it's pretty much expert feature territory (e.g. those of us who edit our > message headers by hand). I would hope it's obvious that you don't present in a UI as having anything to do with TLS, securit

Re: [Uta] RequireTLS: NO

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 Also trivial to do with Sieve. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] MTA-STS with lots of domains

port, things would > be better. But we can't. Next! Of course we can't. But I fail to see what that has to do with the scalability of MTA STS. Ned _______ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] MTA-STS with lots of domains

ces are good that the same thing will be done on an inbound MTA that is an MX. Only if they happen to be the same system and the person running them is careless, incompetent, or both. Ned ___ Uta mailing list Uta@ietf.

Re: [Uta] MTA-STS with lots of domains

also a limit on validation failures that probably applies. But it's per-host and should not be a problem. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] MTA-STS with lots of domains

d consider unacceptable and would consider fixing it a top priority. And I'm speaking as someone who also uses DNS validation for a bunch of domains on a Frontier DSL connection that doesn't exactly deliver world-class performance or reliability. Ned _____

Re: [Uta] MTA-STS with lots of domains

e a problem. Agreed, but to be fair, there is a 500 domain per IP limit with Let's Encrypt. But 500 is a lot more than 80, and if you're servicing over 500 domains that sounds like a fairly commercial enterprise to me, with all that implies. Ned __

Re: [Uta] New Version Notification for draft-levine-additional-registered-clauses-00

the message passed through. It might be smart enough to edit the other stuff out of the Received: field but not the SNI information. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [ietf-smtp] New Version Notification for draft-levine-additional-registered-clauses-02

that any future use of ESNI would necessarily correlate with whether or not to put SNI information in trace fields. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] [ietf-smtp] New Version Notification for draft-levine-additional-registered-clauses-00

obviously align with whether or not ESNI is used. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] New Version Notification for draft-levine-additional-registered-clauses-00

hether or not ESNI is used, I actually think logging that is a bad idea, as it doesn't really any anything useful that I can see and less is more when it comes to this sort of stuff. Ned ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

the extent that it can be significantly changed. AFAICT the draft hasn't been updated beyond what RFC 7525 says, so I'm going to wait and see what those updates say before I decide if I can support the change. Ned ___

Re: [Uta] RFC 8314: Consider supporting point-to-point delivery

FWIW, you appear to have responded to a message that hasn't made it to the list yet. Ned Short version: this is, in many cases, a Bad Idea. To the extent email delivery is reliable, it is because of persistence in relaying traffic.   Many mail user agents are