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

[ned+uta]

> On 06/04/16 09:52, Daniel Margolis wrote:
> >  But even if we'd prefer TACK (which
> > isn't unreasonable by itself), do we really want to deviate from the
> > well-trodden path of webPKI? I think not--browser-to-webmail HTTPS is
> > already an existing piece of attack surface for most users, so reusing it
> > here is somewhat sensible.

> Speaking as the maintainer of an MTA, no it is not.  Having to add
> support for another protocol to an application which deals in SMTP,
> and knows how to use a library to get DNS, just feels wrong.

As I indicated in the Jabber chat session the other day, I'm 100% with Jeremy
on this. This expands the attack surface of the MTA considerably, and like it
or not that has to be considered as part of the security tradeoffs we're making
here.

Nor did the suggestion that prefetching, caching, and similar techniques
somehow ameliorate this impress me. While it may be possible to perform some or
even all of these http operations outside of critical SMTP client code, the MTA
has to perform them somewhere, somehow.

I briefly considered calling for a limited profile of https for this purpose,
but I don't see how that can possibly work. Just as we know that the way some
people are going to implement the client side of this is by throwing an
existing, hugely  complex https library into their SMTP client, it's even more
certain that the way people are going to implement the server part of this is
by throwing up a web server using whatever existing web server technology they
have lying around, with all that implies.

> I'd
> feel an extreme lack of enthusiasm for ever getting around to
> implementing such.

FWIW, if this comes to pass given our customer base we won't really have an
option 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 just too bad.

Ned

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

> > On 1 May 2016, at 11:29, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> >
> > Wouldn't the same argument tend to indicate SRV or a sub-domain are
> > as troublesome, given in many enterprises, mail and DNS can be in
> > different silos? After all, isn't that the core of the stated argument
> > for not doing DANE/DNSSEC? While putting up a sub-domain or an SRV
> > might be easier than signing the DNS, putting up a .well-known also
> > isn't hard.

> In my experience with large service providers, the mail team are often
> responsible for DNS, or if not, then at least close to the DNS team. Not so
> with the web team, which (again in my experience) is typically in a completely
> different part of the organisation.

The fact that operational changes to the DNS are likely to be needed on
a regular basis by any large email deployment more or less insures this
is the case. 

Of course this doesn't translate to DNSSEC magically deploying when needed.

Web services, OTOH, only intersect with webmail, and since that's usually
delivered by a separate application-specific infrastructure, the intersection
may 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

[ned+uta]

> Thanks Ned for the general feedback. We will review and get back with you.

> Did you have specific feedback for the HTTPS fetch timeouts discussion that 
> this thread is intended to address?

Not at this time.

TBH, I'm not really interested in getting in to such issues until the draft is
in a bit better shape and it's easier to visualize how the sequence of
operations fits into the SMTP client, how much of the MTA-STS procedure can be
moved to a coprocess, and what that relationship would look like. (There's no
way we're going to put a full-on HTTP client in our SMTP client, 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.

        Ned

_______
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] REQUIRETLS update

[ned+uta]

> > On Dec 9, 2016, at 5:40 PM, Arvel Hathcock <ar...@thehathcocks.com> 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 would (for example) be the result if a client requested both
> the REQUIRETLS and a separate MAYTLS feature?

> Adding the converse feature does not noticeably complicate this
> draft, it merely makes it feature complete, and would provide
> 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

[ned+uta]

> 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.

> I'm trying, without much success it seems, to explain why REQUIRETLS is
> an incomplete take on the requirements for per-message TLS policy, and
> why fragmenting the solution over multiple specificaitons would be a bad
> idea.

> I am not too worried about what MTAs will or won't do with per-message
> REQUIRETLS, just pointing out non-orthogonal features which hint at the
> need for a single spec.  I rather expect that the "require" side of the
> per-message policy will see exceedingly little use.

Yep. 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

[ned+uta]

> On Tue, Apr 04, 2017 at 04:20:59PM +0200, Daniel Margolis wrote:

> > Can you explain a little more what you mean? The mitigation is to publish a
> > new policy with the correct values, so certainly anyone who does so
> > pre-emptively is not likely to fall victim to a DoS attack.  More
> > specifically, anyone who is _aware_ of this risk should simply ensure
> > untrusted individuals cannot publish content with a certificate for *.
> > example.com on "mta-sts.example.com"; the risk is for domains like (say)
> > tumblr.com who may inadvertently allow that.

> I too found the text in question confusing.  It makes no mention
> the attacker is presumed able to obtain certificates for
> "mta-sts.example.com", but otherwise the description does not make
> much sense.  The DNS TXT record does indeed facilitate 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.

Ned

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

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 <813df83a-841e-4e6a-e3a1-f2852b20d...@bluepopcorn.net> you
> > write:
> > >3.1. MTA-STS TXT records
> > >
> > >There is no IANA registry for reserved hostnames, which is why protocols
> > >like SPF store their policies at the domain itself.
> >
> > Urrgh.  SPF is as far as I know the only protocol published by the
> > IETF that stores policies at the unprefixed hostname, and that is
> > widely agreed to be a mistake.  DKIM and DMARC use prefixes.
> >
> > There's the somewhat separate issue that if the prefixed name has to
> > be a hostname so it can be used in a URI, it can't contain an
> > underscore.
> >
> > R's,
> > John
> >
> > PS: Dave Crocker and I have been working on a prefix registry, but
> > it's a thankless task.
> >
> > ___
> > Uta mailing list
> > Uta@ietf.org
> > https://www.ietf.org/mailman/listinfo/uta
> >

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

> The obstacle in the current draft was that  the "NO"
> case appeared to over-complicate the ESMTP extension,
> but it is now clear that the "NO" case need not use
> the "ESMTP" extension and should be carried exclusively
> via a header.  However, since the same TLS policy
> header is also needed for the "YES" case (but with
> a slightly different payload), the same draft should
> specify both.  We should not force these to be separate
> just to hurry the "YES" case out the door.  Let's do
> this right.

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 specifications. Let's
please not make it more so.

    Ned

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-uta-mta-sts-17: No Objection

> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)


> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.


> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/



> --
> COMMENT:
> --

> Thanks for the well-written document!  Other people have noted some things 
> already,
> so I can only add small things.

> Section 3.1

> Did you consider ABNF that would let new versions be defined without
> having to redefine the ABNF?

First, since the cost of "redefinition" is a single line of ABNF:

  sts-version=/ %s"v=STSv2"

it's hardly high cost. As for the corresponding code, in my implementation it
would correspond to a single line change. Again, hardly high cost.

Second, this approach is used in numerous other specifications in the email
space, so it is hardly obscure. What would be obscure is some other sort of
extension mechansism. We've tried other mechanisms on several past occasions,
including the original MIME specificaiton, and the results have been poor.
Those experiences have led to the current approach.

Third, the only reasons I can think of for a version change would be to change
either some aspect of the syntax or some basic semantics of the record/object.
Those changes are almost certainly going to be a lot more difficult than
supporting an additional version number.

> Section 7.2

> It's probably better to cite this as BCP 195 than RFC 7525 directly.

Given the liklihood of BCP 195 being upgraded to TLS 1.3 at some point without
full consideration of the impace on email infrastructure,  I'm by no means sure
that's the case.

Or, to put this another way, if you want to reference a changing set of secure
substrate best practices here, that in turn imposes a requirement on future
versions of those best practices to give full consideration to email
infrastructure realities.

As the wise man once said, "Are you sure this is what you want?"

> Section 8.1

>Recipients should also prefer to update the HTTPS policy body before
>updating the TXT record; this ordering avoids the risk that senders,
>seeing a new TXT record, mistakenly cache the old policy from HTTPS.

> It seems like this risk would be mitigated if the "id" value from
> the TXT record was required to also appear in the policy body as an
> identifier.  But presumably that would cause issues elsewhere, as it
> is 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

[ned+uta]

> > On Jun 14, 2018, at 3:04 PM, James Cloos  wrote:
> >
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-smtp-tlsrpt-23
> >
> > Some newlines got lost in that update.
> >
> > The diff makes it easy to see.
> >
> > Also, the new copy needs:
> >
> >  s/by and Adler-32/by an Adler-32/
> >
> > Otherwise it looks good.

> I am surprised to see the security considerations refer to
> multi-file gzip inputs, and processing of the filename
> metadata inside the gzip stream.  I've never seen anyone
> do that.  In practice 'gzip' archives are assumed to
> contain just one "file", and the name from the gzip
> metadata is ignored, instead the user specified where
> to write the output.

If you are registering a media type suffix you have to cover all of the
format's capabilities. What has or has not been used in the past is irrelevant.

> I rather think it makes more sense here to specify that
> the "+gzip" MIME sub-type always holds exactly one
> compressed object, and that the filename hint in
> the compressed stream should be ignored.

It's not a subtype, it's a suffix that applies to all future uses of gzip
in any future media type. Are you completely confident that this will in fact
be the right choice for all future uses?

> By far the more interesting issue with compressed
> content, is potential DoS, because small inputs
> 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 do so.

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

[ned+uta]

> > On Jun 16, 2018, at 8:48 PM, Ned Freed  wrote:
> >
> >> I rather think it makes more sense here to specify that
> >> the "+gzip" MIME sub-type always holds exactly one
> >> compressed object, and that the filename hint in
> >> the compressed stream should be ignored.
> >
> > It's not a subtype, it's a suffix that applies to all future uses of gzip
> > in any future media type. Are you completely confident that this will in 
> > fact
> > be the right choice for all future uses?

> Well, if this is to be a "+gzip" suffix, it presumably represents a
> compressed form of the base media type,

This is just not how media type suffixes work. There is no "base media type"
the suffix modifies - for example, if the suffix is +xml or +ber, what's the
type underneath the XML or BER representation supposed to be?

And in the case of +zip - which is widely used - it is the rule, not
the exception, for there to be multiple "files" present, and in some
cases even a directory structure.

> which might reasonably be expected to be a single object.

No, not really.

> Certainly in the case of the motivating use-case (tlsrpt). 

That's true, but you're not defining a suffix for a single use-case. You're
defining a suffix for all future cases as well. And as I said before, are you
prepared to *guarantee* that nobody will ever use +gzip as a container for
multiple "files" - epsecially since there's running code sayng that other
similar media type suffixes are used this way all the time?

> Though, admittedly, this not a proof that some media type might not in its 
> gzip
> incarnation become multiple compressed streams. If there is a plausible
> use-case for such a thing, then the recommendation to ensure that only one
> stream be present would apply to various specific use-cases, such as "tlsrpt",
> but not generally.  Feel free to ignore or use these and the previous remarks
> as you see fit...  They 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 requirement for my approval of
the registration.

Ned

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Updated TLSRPT

[ned+uta]

> No.  You don't violate 27 years of practice based on any number of tests that
> this WG is capable of doing, just to avoid defining two content-types.

Exactly right. We couldn't possibly perform a meaningful test of this sort.

And even if we could, and if the results showed there 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.ietf.org/mailman/listinfo/uta

Re: [Uta] Updated TLSRPT

[ned+uta]

> > On Jan 31, 2018, at 2:44 PM, Keith Moore <mo...@network-heretics.com> wrote:
> >
> > You don't violate 27 years of practice based on any number of tests that 
> > this WG is capable of doing, just to avoid defining two content-types.

> I remain quite puzzled as to the nature of the violation.
> All I see is a new media type that takes an optional parameter
> which specifies that the content is gzip compressed.

> The new media type has no legacy consumers, and is not suitable
> for inline display by MUAs.  The data is intended for aggregation
> and machine analysis alongside reports from other senders.

> I fail to see any interoperability concern.  Perhaps, I'm missing
> something.  Please explain.

The +json suffix is defined to mean that the content consists of JSON,
and can be parsed as such, independent of any understanding 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

___
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

[ned+uta]

> > > 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 variant, and feels intuitively simpler for
> > MTAs
> > > to implement.
> >
> > I'm afraid you have this exactly backwards. Even if the SMTP server
> > approach
> > provided comparable security - and it doesn't -  deploying a new SMTP
> > extension
> > is quite difficult; we have an abundance of fully worked examples
> > demonstrating
> > this point. Whereas throwing up an A record, certificate, and server that
> > serves out a single document is trivially easy. These days I don't rank as
> > an
> > experienced IT person, and I was able to do it for a test domain in about
> > 20
> > minutes.
> >
> >
> I entirely agree that hosting a single document under HTTPS is trivial.


> > This is not to say that there aren't issues implementing MTA-STS. There are
> > significant issues, but they are all on the client side. Adding an HTTP
> > client
> > to your SMTP client significantly increases attack surface, so much so
> > that I'm
> > not willing to do it, and other folks have said they aren't willing to
> > either.
> >
> > The approach I'm using is to build an MTA-STS query server with integrated
> > caching support. I have one mostly coded, and while I haven't worked
> > through
> > all the caching and timeout issues yet, I have not found any significant
> > implementation obstacles.

> This workload is what I consider to be the antithesis of "intuitively
> simpler".

And once again I'm afraid what your intution is telling you is exactly the
opposite of my experience. For me implementing this using a separate query
server actually makes things much easier, not harder, in part because I'm not
constrained to code things in C/C++, which is what the SMTP client is coded in.

You might want to sit down and try mocking this up in, say, node.js. It may
change your mind about the approach.

And the client part is going to be maybe 50 lines of C code. Code of a sort
I've written many, many, many times before. Hardly difficult.

> > > c) Both/either of the above.
> >
> > > I assume the logic behind allowing a wildcard-to-wildcard match is to
> > allow
> > > a Google user to simply specify ".googlemail.com" and ".l.google.com" as
> > > their MX identity patterns; however it feels as though Google could
> > simply
> > > use a known name within the certificate for all their receiving MTAs,
> > > irrespective of the DNS records involved. This, of course, presupposes
> > that
> > > the administrator of the mail domain somehow does not know the precise
> > > names of the MTAs used in their own DNS records.
> >
> > > I further assume the logic in mandating matches against dNSName SANs is
> > > because these are readily available; however sRVName SANs, by restricting
> > > their use to a particular service, have the advantage that customers
> > giving
> > > these to their service provider might be deemed more acceptable.
> >
> > A comparable effect can be achieved by using a subdomain root reserved for
> > email server use.
> >
> > So it's a choice between an easily implemented naming convention  and a
> > bunch
> > of PKIX esoterica. This does not strike me as a difficult choice.
> >
> >
> Well, being *able* to use sRVName would be nice at least. The specification
> as written prevents it, which seems unfortunate.

I have to say I like the simplicity of the current specification, and I don't
want to see added complexity in this regard without a compelling reason for
adding it.

> > >o  MTA-STS Policy: A commitment by the Policy Domain to support PKIX
> > >   [RFC5280] authenticated TLS for the specified MX hosts.
> >
> > > Impressively, by my reading, the commitment is for the Policy Domain to
> > > support PKIX for all SMTP; and 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

[ned+uta]

  ; chars, excluding CTLs and no
; leading/trailing spaces

It also may be worth considering allowing UTF-8 in extension values.
Once the syntax rules are set theybre very difficult to change.

(10) The production for mx values:

 sts-policy-mx-value  = 1*(ALPHA / DIGIT / "_" / "-" / ".")

 seems overly lax to me, especially since the DNS-ID fields being
 compared against are constrained to valid domain syntax. Rather
 than once again specifying productions for a domain, I would
 suggest importing the definition of Domain from RFC 5321. This
 then becomes:

 sts-policy-mx-value  = ["."] Domain
 Domain   = 

(11) For completeness, section 3.4 should contain a note about the handling
 of domain literals. I suggest "this specification does not provide a
 means of associating policies with address that employ 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

[ned+uta]

> On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote:
> >> On Mar 22, 2018, at 2:59 PM, Martin Thomson <martin.thom...@gmail.com> 
> >> 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 to make explicit preference 
> > for
> > delivery above all other concerns a necessary feature.
> >
> > When a user gets a delay warning for their initial attempt to send a 
> > time-sensitive
> > message, it should be possible to resend the message with an explicit 
> > opt-out of
> > enhanced security protections (beyond unauthenticated opportunistic 
> > STARTTLS).

> can't they opt-out by re-sending to their submission agent without the
> REQUIRETLS SMTP command?

You're assuming that the only TLS-related failure case that could occur
is when REQUIRETLS is used. I can assure this is not the case. TLS failures
occur all the time, and as things stand we deal with them by falling back
to no-TLS transfer. In such cases we cannot tell whether it's an attacker
or a received-side problem.

MTA-STS changes this: It provides a way for receivers to state that they
want TLS used and senders should assume a problem is caused by an attacker.

The problem is they are still going to be screwups - in fact they are likely to
increase in number - and this combined with MTA-STS is going to be an issue.

>  or is the fear that their submission agent
> will invoke REQUIRETLS on the next hop without the user's permission?

The REQUIRETLS SMTP extension isn't even on my radar. My only interest in this
draft is that it provides a way for senders to say "screw privacy, I want my
message delivered".

> fwiw, i think troubleshooting alone might be sufficient reason to
> document the "RequireTLS: NO" message header, but i'm pretty unclear 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, security layers, and other technical matters. A presentation along
the lines of "favor delivery over privacy" would seem to make at least some
sense.

Ned

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] RequireTLS: NO

[ned+uta]

> > On Mar 22, 2018, at 3:59 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> > 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 permission?

> No, the user is opting out of a TLS security policy he did not request,
> one published by the receiving domain via DANE or STS.  Clearly if you
> don't want secure delivery, don't ask for it.

> > fwiw, i think troubleshooting alone might be sufficient reason to
> > document the "RequireTLS: NO" message header, but i'm pretty unclear 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).

> When this becomes an RFC MUAs could add the feature.  Also MTAs running
> milters or similar content processing could implement a content
> transformation from:

>   Subject: [insecure-delivery]: actual subject

> 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

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

[ned+uta]

> >AFAIK, the relevant Let's Encrypt limits are:
  
> That might be right, it might not.

It's the value they document. Here's a link:

   https://letsencrypt.org/docs/rate-limits/

I also note that I missed the point that this limit only applies on creation,
not renewal. So it doesn't look like it it's even relevant.

> Making deployment policies based on soft guidelines is probably not going to
> scale well.

Let me guess - you haven't operated a high end messaging system recently that
sends lot of mail, have you? Because if you had, you'd know that setting
deployment policies based not just on completely squishy guidelines, but based
on constantly changing operational data is an absolute requirement.

Compared to other stuff the rules for using Let's Encrypt might as well be
chiseled in stone.

> Yes, if we made everyone use TLS for all inter-node transport, 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

[ned+uta]

On 01/09/2019 08:04 PM, John Levine wrote:
> Since MUAs don't talk to MXes, I have no idea what this is supposed to mean.



MUAs talk to MSA's, which in my experience are usually also an MTA.
Even if inbound and outbound MTAs are separated, they are usually
administered in the same manner.


Not in my experience, they aren't. In fact it's pretty much the opposite -
changes that are needed on both often only get made on one of them.

If they are separate it's for a reason, and implementing that typically
requires different configurations.


So if you need to do something on an
MSA, chances 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.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

On 01/09/2019 06:11 AM, John Levine wrote:
> Yes, I know.  The chances of verifying 80 names in a row without one of
> them glitching does not seem high.  I'd probably get rate limited first.
> The usual LE rollover for a single cert starts quite a long time before
> the old cert expires so if it fails, you can try again tomorrow.



I thought the rate limit was the number of certs /issued/ a week.  So I
would expect that validation failure before issuance wouldn't count
against the rate limit.


Yes, and I missed the /issued/ part in my original response; sorry.

There's 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

[ned+uta]

> In article <01r1svv1718u000...@mauve.mrochek.com> you write:
> >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.

> Hmmn.  I do LE validation with DNS records.  How do they even know what IPs
> the certs will be served on?

DNS validation still starts with a request from an ACME client. That's the IP
that matters. And as I have subsequently noted, I misread the text; the limit
only applies when creating an account for the first time, so it's actually
irrelevant.

>From what I can tell there is no limit that would prevent you from maintaining
as many domains as you want, even in the presence of a 2% valiation failure
rate - a rate which, if I had it, I would 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



_______
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

> On 8 Jan 2019 15:59:30 -0500
> "John R Levine"  wrote:

> > I can set up the TXT records easily enough, but it looks like I need
> > an HTTPS server with 80 names and 80 certficates, or one certificate
> > with 80 alt names.  That doesn't scale very well.

> I believe the thing you want is automation.

> There's no technical scalability issue here, a certificate is just a
> bunch of bytes you get for free. The only issue is that configuring 80
> hosts and certs manually is a lot of work. Take the "manually" out and
> you don't have 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

___
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

[ned+uta]

> I think the better approach here is to say that SNI logging adds to the
> information about the message's origins and history, and the same
> considerations as to whether or not to include things like server IPs also
> apply to SNI information.



Seems reasonable.  In the usual case that you can tell who the recipient
of the message was, does the MX name or SNI or ESNI tell you anything of
interest that you didn't already know (other than that the client does
SNI?)  I'm having trouble thinking of a plausible case.


The case that comes to mind is some sort of alias or list 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

[ned+uta]

After reading all the discussion I posted an -02 which takes out all
mention of ESNI.  Here's why.



The most important issue is process.  ESNI is currently described only in
an early I-D which will not turn into an RFC for a long time.  If I
reference it, this draft will be stuck behind ESNI, also for a long time.
If I don't, this draft should be able to progress quickly.  Once it's
published, if you want to add an ESNI clause, you can do so by expert
review, no RFC needed.


I agree this is the most important issue, and is more than sufficient to
preclude mentioning it, but even if ESNI was to progress tomorrow and mail
systems were to implement it, I think there's a compelling case not to log its
use in trace fields.


More substantively, I would be surprised if any MTA ever implements ESNI
because it makes no sense for mail.  On the web, different hostnames lead
to different web sites, and clients expect the name in the TLS cert to
match the hostname in the request.  In mail, we've never expected the name
of the MTA to match the domain of the recpient, and it is quite normal for
a million different domains to point their MXes at the same host with the
same name, e.g. aspmx.l.google.com.



If you don't want your SNI to give anything away, you just do what mail
systems have done all along, use the same MX names for everyone.  There's
no problem for ESNI to solve and certainly no reason to go to the effort
to put all the ESNI glop in the DNS.


I suggested this approach in an earlier response. But the counterargument was
that you can't assume any particular certificate naming model for SMTP in
general. I think that's a stretch, but once again even if it were true and ESNI
were to deploy to address some case we're missing in mail, I don't
think we can assume 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

[ned+uta]

>> By the nature of e-mail, the recipient of a message already knows who
>> the sender sent it to, since he or she got it.  The Received headers go
>> into the message itself, not third party logs.
>
> Mail list archives and mail corpus leaks do expose that to more
> than one recipient.



Indeed, but unless they remove the Received: headers (in which case this
debate is irrelevant) they also expose the recipient and so forth.



To the extent that list archives have those headers, they disclose the
address of the list and perhaps an internal address used to forward mail
from the list to the archive.  BFD, I'd think.  The corpora I've seen have
no Received headers and the addresses in From/To/CC redacted, too.



> But, if someone has decided to setup ESNI for an MTA (which will
> need them to take action to do that), then I'd assume they have
> a reason. At that point, exposing the ESNI value in the message
> is what I'm arguing to not recommend.



Naah, it just means they upgraded to a new library version that supports
it.



Here's a thought experiment: try and construct a plausible Received header
that would tell you more about the recipient with SNI than without,
keeping in mind that the IP address of the server is mandatory,


First, I don't think that's the case. But even if it is, how about a server
servicing multiple domains, some sensitive and some not, and each domain set up
with different MX records?

I'll also note that servers often omit or obfuscate IP address information for
security reasons, irrespective of what the standards say.


and the
server name and recipient (the "for" clause) are usually included.  I
think you'll find it's quite hard unless you do things that MTAs don't
normally do.


Actually I'm seeing fewer and fewer for clauses over time. But regardless,
as I noted in my previous message, the security considerations of including
SNI information aren't really separable from the security considerations
of what to include in trace fields in general, and don't 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

[ned+uta]

> I suggest calling out ESNI specifically as a reason to not log the
> SNI in the security considerations, e.g. via:

> OLD:

>In a few
>circumstances, a new Additional-registered-clause might disclose
>information to a recipient that was otherwise unavailable.

> NEW:

>In a few
>circumstances, a new Additional-registered-clause might disclose
>information to a recipient or other actor (via data leaks) that
>was otherwise unavailable. In particular, if the SNI value was
>encrypted in the TLS handshake [ESNI] then logging is NOT
>RECOMMENDED.

> [ESNI] would point at draft-ietf-tls-esni

I don't see how this recommendation makes sense given the stated goals
of ESNI. As I understand it, the goal of ESNI is to keep observers of
the TLS connection from being able to determine the server identity via the
SNI information exchange, especially in cases where this is sensitive
information.

This does seem like something you'd want to do SMTP, given that there are an
adundance of servers out there handling many domains with multiple identities.

However, the draft also says:

   The design in this document takes a different approach: it assumes
   that private origins will co-locate with or hide behind a provider
   (CDN, app server, etc.) which is able to activate encrypted SNI
   (ESNI) for all of the domains it hosts.  Thus, the use of encrypted
   SNI does not indicate that the client is attempting to reach a
   private origin, but only that it is going to a particular service
   provider, which the observer could already tell from the IP address.

And this seems applicable as well, since MTAs handling traffic from many
clients is the rule, not the exception.

But the "hide in plain sight" aspect of this means that ESNI needs to be used
for everything on a given server, not just in cases where the domain needs to
be kept private. So if ESNI deploys in SMTP according to this model, it may
erase many/most of the benefits of this draft.

(I note that in SMTP the hide in plain sight aspect might be better implemented
by having shared MX host names between private and public domains - no need to
wait for TLS extension to be fully fleshed out and deploy.)

This limitation might be acceptable if the security considerations for on-wire
exposure are the same as for trace fields. But AFAICT they aren't even close to
comparable. With trace fields the risk is that they can potentially betray the 
message's origins and transfer history to anyone who subsequently sees the
message. These concerns apply regardless of whether or not ESNI is used - and
remember that ESNI won't be available in SMTP for quite a while, if ever.

I think the better approach here is to say that SNI logging adds to the
information about the message's origins and history, and the same
considerations as to whether or not to include things like server IPs also
apply to SNI information.

As to whether 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

[ned+uta]

IMO RFC7525 and this new draft both suffer from dubious assumptions and
make poor recommendations because of those assumptions.  In particular,
there are many cases for which using an old version of TLS is suboptimal
and it shouldn't be considered as secure, but it may still be better
than deprecating old versions of TLS that might be the only ones
supported by the peer.


Whether or not to ban SSL v2 and v3 is a tough call, but not for the reasons
given in RFC 7525. Yes, these are weak mechanisms, but in the absence of other
considerations weak is better than no security at all.

However, because of the way the negotations work supporting all of these stuff
simultaneously has proven to be difficult to get right. The fact that these old
versions can cause interop failures with later versions is arguably sufficient
cause for a MUST NOT. 


People do not always have the luxury of upgrading their clients and
servers to versions that support the recent TLS.    Some legacy hardware
has firmware that cannot be upgraded because no upgrades are
available.   Service providers do not always have the leverage to insist
that their customers upgrade, or the luxury of abandoning customers. etc.


Shorter version: Once again the IETF is letting the best be the enemy of the
good.


I therefore find it difficult to make good advice of the form "don't use
TLS version x.y" that is appropriate across all applications and all
usage scenarios.   Again, there's an important difference between "don't
use TLS x.y" and "don't consider TLS x.y secure".


Agreed.


I also think it's odd that there are recommendations like this that say
"don't support TLS x.y" but say nothing about not supporting cleartext
for protocols that still have a cleartext mode.   Even SSL 1.0 is
probably better than cleartext (at least from a security perspective, if
not from a support burden perspective) as long as it's not trusted to be
secure.


Agreed as well.


So in summary, either I don't support adoption of this draft, or I
support adoption of this draft only to 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

___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

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

[ned+uta]

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 not in a good position
to do that.   It is generally better to submit the message to a service
that is well-connected and well-provisioned for relaying.



Mail submission should be a distinct service from mail relaying, and
done on separate ports so that they're easily distinguishable.  
Combining the two services, as was once common, results in more damage
to messages in transit.



I'm sympathetic to the idea that multihop mail relaying produces more
opportunities for surveillance of message content, but the right
solution to that problem is e2e encryption.



As much as I dislike port blocking as any kind of general strategy, I
strongly suspect that port 25 blocking is helpful even if it doesn't
eliminate all spam.   (The spam situation would be even worse without it.)



So I emphatically do not support the proposed changes.



Keith




___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta


___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta