[Uta] Re: Beyond DANE

It appears that Watson Ladd said: >To my mind the registry should be able to issue X509 certs for second >level domains/whoever controls a public suffix. After all, they know >where you change DNS. Haven't sorted out how to deal with the level >below that. Do others find this line of thought comp

Re: [Uta] Consensus call for proposed changes to draft-ietf-uta-rfc6125bis-10

It appears that Viktor Dukhovni said: >Though I coughed a small part of the suggested text, I am not >particulary in favour of going down this rabbit hole in the present >document. I don't think this is the place to settle the IDNA2008/UTS-46 >schism. Nor is it the role of this IETF document to

Re: [Uta] UTS-46 / WHATWG

It appears that Rob Sayre said: >I think this reference should be to UTS-46, since it allows more names. >(U+2615 ( ☕ ) HOT BEVERAGE is valid in UTS-46 but not IDNA2008). That makes no sense if your goal is to interoperate. An IDNA2008 system will reject that, and I think I am not the only pers

Re: [Uta] Browser behavior in draft-ietf-uta-rfc6125bis

It appears that Corey Bonnell said: >Thanks for the pointer to this text. It is a very interesting statement, >mainly because the illustrative example does not align >with the first sentence. The A-label “xn--53h” contains a single code point >“Hot Beverage” U+2615. This code point was >first a

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

It appears that Viktor Dukhovni said: >On Thu, Jun 23, 2022 at 01:42:46PM -0400, John R Levine wrote: > >> Among the reasons that DANE in e-mail is less common is that it is tricky. > >DANE is only "tricky" when you're trying to integrate TLSA record >updates with ACME cert rollovers and don't c

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

It appears that Viktor Dukhovni said: >- If the question is about the software stack, then: > > * Any MTA that supports STARTTLS already supports both inbound. Almost -- it needs to have a cert that matches its name and is signed and/or matches the TLSA record. A lot of the default inst

Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

It appears that Peter Saint-Andre said: >On 5/27/22 7:51 AM, Stephen Farrell wrote: > >> - section 3.2: I wondered why no mention of MTA-STS or >>   DANE? Could/should we say that MTA implementations >>   SHOULD include support for such strictness? > >Hi Stephen, > >Although these technologies (

Re: [Uta] ALPN recommendations in draft-ietf-uta-rfc7525bis-01

It appears that Martin Thomson said: >There is a piece missing. Yaron mentioned Alpaca. For that what we need to say >is what Alexey might fear: application protocols >MUST define ALPN labels and use them. Well, you know, ALPACA is the predictable result of three decades of web browsers accept

Re: [Uta] Wildcards

It appears that Viktor Dukhovni said: >That said, it'be really super if various applications profiles decided >to do away with wildcard certificates entirely. Their $$$ cost >advantage is long gone, and otherwise they just damage security by >enabling cross application protocol attacks, ... Som

Re: [Uta] RFC 8314: Don't consider supporting point-to-point delivery

>> for all mail submissions with implicit TLS in the future. This is a >> request to consider supporting point-to-point delivery of email >> directly to MX pointed server. >I believe your proposal as described will make the spam problem worse >and add no value to the email system. ... We don't

[Uta] rfc7525bis section 3.2 on strict TLS

Section 3.2 says in part: o In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers SHOULD prefer strict TLS

Re: [Uta] Smallest practical MTA-STS maximum policy age?

In article you write: >> Thus, my take is that MTA-STS policies with a max_age less than ~30 days >> are potentially ineffective, and perhaps not worth the bother. > >Sure, for production use. > >The issue I am seeing is this: New users are experimenting with MTA-STS and >wish to use a small poli

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

on the list (if they >didn't do it yet). Yes, adopt it so we can update 7525 and fix its mistakes. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

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

is from Google. Outbound is still 1.2 because I haven't gotten around to patching the code to deal with changes from openssl 1.0.2 and 1.1.1. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Pl

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

ple in the same boat. That's my impression, too. The mail software I know uses a generic SSL configuration that only says not to use pre-1.0 SSL, so if you rebuild it with a new library, you get new stuff automatically. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of

Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

ng boilerplate that any sensible recipient will ignore. As Jim knows, I've already implemented it in my MTA with that interpretation in mind. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before readin

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article you write: >Yes, we knew about STARTTLS, but we didn't understand the >impact/consequences of SNI back then. The DRUMS WG charter also >prevented the addition of new features outside specifically identified >exceptions (e.g., IPv6). Without that restriction, I doubt we could have >c

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <232fc698-bdc7-4be1-9e14-da6c788f1...@dukhovni.org> you write: >To make sure that we're talking about the same thing, I want to check >that you're proposing: > > Received: from client.example.com (client.example.com [192.0.2.1]) > by mta.example.net (split-personality-sni.example.n

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <87sgxuh82z@fifthhorseman.net> you write: >-=-=-=-=-=- > >On Mon 2019-01-14 18:09:41 -0500, John R Levine wrote: >> On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote: >>> On Mon 2019-01-14 16:43:15 -0500, John Levine wrote: >>>> To show that

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <0d79662d-d4d5-29c5-faae-12bded0f3...@wizmail.org>, Jeremy Harris wrote: >On 14/01/2019 22:39, John Levine wrote: >> now that RFC 8314 has defined the tls clause, why >> not put the data where the spec says? > >8314 talks about an MSA adding a Received: he

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <6e01e0f9-7e5a-e580-f945-9c756bcc3...@spamtrap.tnetconsulting.net> you write: >> While the Domain part of that ABNF doesn't describe how it's supposed >> to be derived from "Information derived by server from TCP connection" >> for the BY clause specifically, i think using it for SNI

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <20190114220557.gn79...@straasha.imrryr.org> you write: >On Mon, Jan 14, 2019 at 02:48:58PM -0500, John Levine wrote: > >> Today's question: I would like to log the SNI in the Received header. >> Where should I put it? >> >> One possibil

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article you write: >-=-=-=-=-=- > >On 01/14/2019 12:48 PM, John Levine wrote: >> Today's question: I would like to log the SNI in the Received header. >> Where should I put it? > >Wouldn't it go in with the rest of the TLS information? I am so sorry to

Re: [Uta] how to log, was flake ho, was MTA-STS with lots of domains

In article <20190114051526.81911200ca0...@ary.qy> you write: >>Also, keep in mind that Comcast implements DANE, and you're now >>serving a different certificate, that does not match the TLSA >>record, then all the pieces fit together... That was it. I got acme.sh to reissue the certs so that all

Re: [Uta] flake ho, was MTA-STS with lots of domains

In article you write: >Plausibly, based on the logs, the client did not like the handshake, >and sent some sort of alert. Sadly, the logging omits the crucial >alert number or description, so there's not much to go on. Yeah, tomorrow I'll try and get better logging. >Perhaps these SNI configura

Re: [Uta] flake ho, was MTA-STS with lots of domains

In my continuing effort to run my mail server the way I always have* I added SNI to my mail server, which wasn't very hard, and generated about a hundred certs. The good news is that it mostly works -- I sent myself a message from my gmail account, I can see that google does SNI, my system sends i

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

In article you write: >> If I could give LE a hint about which NS to look at, the flakiness would >> go away. > >How often do you need to update DNS records for Let's Encrypt? I use acme.sh which inserts them every time it renews the cert. I haven't looked to see whether the record changes. E

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

In article , A. Schulze wrote: > > >Am 09.01.19 um 17:34 schrieb John Levine: >> If you have to validate 80 names, and each validation works 98% of the >> time, validating all 80 alt names in a row only works 19% of the time. >> That's the scalability issue.

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

In article <893cac17-bcc8-3189-b694-1de31e5b7...@spamtrap.tnetconsulting.net> you write: >-=-=-=-=-=- > >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

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

In article you write: >-=-=-=-=-=- > >On 01/09/2019 07:22 AM, John Levine wrote: >> until STS came along there was no expectation that the name the client >> used matches the cert. > >I've been seeing MUAs complain about the CN or SAN(s) not matching t

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

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.

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

In article <20190109164709.6f869d92@computer> you write: >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

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

In article you write: >I think this is hard. You probably could get a single cert with SANs for >all of your 80 domains, or one for each new domain, but you will have to >figure out how to automate this (and I guess use SNI to pick the right cert >on the server side--note that the RFC does requir

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

pires so if it fails, you can try again tomorrow. R's, John PS: I lied, it's actually more than 80. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___

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

In article you write: >You said that you control the DNS for the 80 domains. Is there any >reason you can't use a common MX name for them? I don't want to. The current setup works fine, and the separate MX names make it somewhat easier to track down some kinds of problems.

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

ent the wheel when we just defined a fairly round one a few months ago. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ Uta m

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

In article <855a7d10-2af6-4f6b-148a-8c2f6d759...@domblogger.net> you write: >MX servers would not be violating RFC if they rejected plain text >connection attempts (over 90% of which these days are spam). 10% is a pretty fat long tail. The people I know who run production mail systems are much m

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

In article you write: >Rather than use a hostname to specify SMTPS only, how about a DNS TXT >record to indicate SMTPS only? How about a SRV lookup instead of a TXT lookup? That has the advantage that it already exists. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator o

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

In article you write: >> I stand by the "has no merit" assessment. Nobody is going to turn >> off port 25 support overnight. > >I presume you didn't read my document. It's all about turn off port 25 ten >years from the standard publication date. Not overnight. Sorry, but this is a fantasy. SMT

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

In article you write: >> For one thing, it doesn't work with IDNs. >I just tested "26pref-español.mydomain.com >" in this page > >

Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

7;t consistent? Also, more practically, anything like this requires a change to the way that mail clients look for mail servers, and if you're going to change, change to SRV which is already well defined and in use in other applications such as SIP. -- Regards, John Levine, jo...@iecc.com, Prim

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

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

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 li

Re: [Uta] review of mta-sts-01

>> So how about if we put in a note saying that the host that the SRV >> points to better be a subdomain of the original, or clients are going >> to be reluctant to believe it. >> >> Yes, that's still a kludge, but it's doesn't cause the mandatory >> collisions that a reserved hostname does. > >Th

Re: [Uta] review of mta-sts-01

>SRV cannot be used here, because presumptively DNSSEC is not in >use, and thus the client's reference identifier for the STS policy >server must be deterministically constructed from the nexthop >domain. So how about if we put in a note saying that the host that the SRV points to better be a su

Re: [Uta] review of mta-sts-01

>I'd argue to ditch the two-level thing and go to one, >e.g. "mta-sts.example.com" or whatever string you like >for that hostname. You might want to pass that by dnsop and see how much heartburn a reserved hostname is going to cause. For this application, I don't see any alternative since there a

Re: [Uta] SMTP STS: Indicating policy for subdomains

>There are public mail servers where users historically were allowed to >register subdomains to receive mail in addition to mailboxes. That's true, but that doesn't mean they use wildcards. The one ISP I know of that has user subdomains, panix, doesn't use wildcards. R's, John _

Re: [Uta] SMTP STS: Indicating policy for subdomains

>It would be rather unsafe for the client to "walk up the tree" >looking for STS records in parent domains. Where should it stop? >"com."? What about "name." where there are delegations of the >form "foo.name" and "foo.bar.name"? This is the issue that the DBOUND working group currently is not s

Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>Incompetence will show up consistently and therefore can be detected by >a considerably simpler mechanism: a testing site, like Qualys SSL Labs. >I see that there is a checktls.com that does exactly this. Incompetent >email operators will probably not implement reporting anyway. > >Reporting is, h

Re: [Uta] DNSSEC or the lack thereof, was reporting, was CBOR, XML, JSON

>> I think it's fair to say that we're still a long way away from broad >> DNSSEC adoption. This doesn't mean we should ignore it, but it does >> mean that non-DNSSEC approaches like the one here are worth thinking >> about. > >Quite fair, though DNSSEC adoption does not happen in a vacuum, there

Re: [Uta] DNSSEC or the lack thereof, was reporting, was CBOR, XML, JSON

Hmmn. >TLDDNSSEC >-- - >.bank 100.0% 3173 domains >.ovh 46.4% about 22,000 of 47,000 domains >.amsterdam 24.9% about 6200 of 25,000 domains I think it's fair to say that we're still a long way away from broad DNSSEC adoption. Th

Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>> My impression is that many, perhaps most, existing MTAs can be >> configured to do STARTTLS. But of course, at this point none of them >> have any reporting extensions. Viktor and I can write reporting >> extensions for our favorite MTAs, but under the most optimistic >> scenario it'll take qu

Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

It occurs to me that another reason to prefer out of band reporting is that it's a lot easier to ramp up. My impression is that many, perhaps most, existing MTAs can be configured to do STARTTLS. But of course, at this point none of them have any reporting extensions. Viktor and I can write repo

Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>Yes, I'm advocating for simple in-band signalling as one of the >mechanisms that should probably be supported. This won't carry >very detailed information, but will be timely and will be seen by >the *actual* MX host that is misconfigured. So long as we understand that you also need out-of-band

Re: [Uta] reporting, was CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>When an MTA is misconfigured, if reports are sent in real-time via >email, every remote site that connects to the broken MTA will >generate a new email generating a notification flood. This is >much less likely to happen with DMARC. For one thing, DMARC notifications come in clusters all the tim

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>Just a quick comment. IIRC, "the whole audience" is the mailing >list. I may not make it to Berlin, TBD. I'm pretty sure I'll be there. Perhaps I can channel Viktor's arguments. Or more realistically, Meetecho works pretty well now. R's, John ___

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>> 1. Company has lots of MTAs, collect statistics to see which ones >> are misconfigured in preparation for publishing policy statements. >> For items 1 and 2, the ESMTP extension won't work, since the MTAs as >> likely as not won't have it. >That's not a fair objection, they would have to depl

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>> The most timely reporting mechanism may be neither HTTPS nor a >> separate email report, but an ESMTP extension that can signal >> authentication errors as they occur. ... I'm getting the impression that it would be helpful to try and write down some scenarios about what the reports are for. H

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>What if I want to send sensitive information about delivery failures? I.e. the >way a MITM was attempted? It's probably not a great idea to send that kind of info unless you already have a relationship with the recipient. >See above. Opportunistic TLS is the wrong approach here in my opinion.

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

> * In the case of `https`, reports should be submitted via POST >>([@!RFC2818]) to the specified URI. By the way, that's somewhat underspecified. While the http specs say it's OK to do a POST with an arbitrary MIME type such as application/json or application/gzip, the web apps I know all ex

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>I think it's certainly different in that with DMARC we can assume the >report sender can reliably (and securely, insofar as DMARC assumes SMTP >works!) reach the report recipient; with TLSRPT that's not exactly true. >I think the primary virtue of accepting HTTP/S reports is really in the >case w

Re: [Uta] CBOR, XML, JSON (was Re: Updated SMTP STS Draft)

>Well. Depending on the channel we use for feedback, DEFLATE might be a poor >option: Well, yes, but anything can have security bugs, and I expect that the libraries for gzip which have been around for a decade have been audited a lot better than the ones for CBOR on which the paint is still wet.

Re: [Uta] special hostnames, was draft-brotman-mta-sts/

>The downside that vanilla HTTPS libraries in their default validate >and retrieve mode can will no longer work without custom overrides >for certificate validation. I've seen that done incorrectly in >many creative ways, ... If history is a guide, the number of implementations of whatever hack w

Re: [Uta] special hostnames, was draft-brotman-mta-sts/

>Has there been any effort to standardize or register the "special" >subdomains, e.g. something like *well-known*.domain.com? Having seen large >companies fail to secure the abuse@, webmaster@, security@, and other local >parts that allow "proving" domain ownership, I'm not as sanguine that >tumblr

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

>Though I am sure that John can whip up safe Python code to do HTTPS >with a hostname<->certificate mismatch, making this necessary is >best avoided. Though I am sure that some domains can delegate smtp-sts-policy. without trouble, putting a new and unprecented requirement on the DNS operator of e

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

>The documentation says: > >Changed in version 3.4.3: This class now performs all the necessary > certificate >and hostname checks by default. To revert to the previous, unverified, > behavior >ssl._create_unverified_context() can be passed to the context parameter. > >So it seems tha

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

>Cute, but likely completely insecure. I see no check that the >certificate chain is trusted. Is it really that hard to look at the documentation for the python libraries? It's right here: https://docs.python.org/3/library/http.client.html By default, the https library checks the certificate ch

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

>> With typical https libraries, I don't know how hard it'd be to check >> the second name in the certificate. I tried writing a python script to fetch an https URL and check a different domain name against the subjectAltNames in the site's certificate. It turned out to be really easy, viz. the t

Re: [Uta] Updated SMTP STS Draft

>Honestly I can't tell from the thread if there is consensus or not. I don't think it's perfect, but I do think the problem it addresses is real and the basic approach: publishing policies, and collecting reports about actual practices is sound. So yes, please adopt it so we can fix the problems,

Re: [Uta] draft-brotman-smtp-tlsrpt

>One way to dramatically simplify reporting is communicate the reports >in-band. That is, when authentication of a peer fails, complete the >TLS handshake anyway, and send a suitable SMTP command that signals >some detail of the TLS authentication failure, before sending QUIT. One of the reasons

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

>So using the domain as-is and dealing with any provisioning politics >looks to be the only sensible option. Not to put Daniel on the spot, but since he happens to work for one of the largest mail providers in the world, would it be a problem to put the STS stuff at URLs like these? https://googl

Re: [Uta] draft-brotman-smtp-tlsrpt

>We'd like others to review and encourage further discussion relating to these >drafts. Thank >you for your time. Reporting is an important part of the design and I'd like the WG to adopt the draft. Having said that, the draft is missing a lot of details on how the reports are sent. Fortunatel

Re: [Uta] Updated SMTP STS Draft

>This looks like a useful extension, analogous in some ways to the >reporting aspects of DMARC which I understand have been beneficial. I'm >not sure how reporting fits with the UTA WG's charter though: perhaps as >one of the 'best practices' that it alludes to? With that caveat, I >support adoptio

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >My suggestion would be thus to *specify that the certificate used to serve >the policy be valid for the TLD ("example.com ") *and >that we *retain the ability to serve policies from a different endpoint >than the TLD* (via either a

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

>> We talked about this at great length over dinner in Buenos Aires. >> Demanding a web server at the same domain name used in e-mail >> addresses is operationally a non-starter for large organizations. > >STS is primarily for the large email providers authoring the draft, >for whom this is not a r

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

>> I'm quite uncomfortable with the bit that says you look up the policy >> at https://policy._mta_sts.example.com/current > >That's surely a mistake. It should have been a ".well-known" >URI at the domain with no prefixes. We talked about this at great length over dinner in Buenos Aires. Demandi

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

>We'd like others to review and encourage further discussion relating to these >drafts. Thank you for your time. I'm quite uncomfortable with the bit that says you look up the policy at https://policy._mta_sts.example.com/current By my reading of RFC 3986 which defines URIs, that's not a URI. S

Re: [Uta] Updated SMTP STS Draft

>interested in in that regard. Once these reports get big, JSON might be >suboptimal. > >What's the WGs opinion on that? DMARC reports are XML and I don't know anyone who finds them too big to handle. So long as you use the application/gzip compression that I arranged for DMARC reports, the size

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

d out-of-band communication (which we do, given the assumed constraints), HTTPS seems as good as anything because there are many implementations of clients and servers and because it's well-understood and widely supported. DanOn Wed, Apr 6, 2016 at 4:52 PM, John Levine <johnl@taugh.com> w

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

>> 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. At the dinner a few nights ago we spent a lot of time thinking about this, and I believe ther

Re: [Uta] SMTP Strict Transport Security - reporting

>A way to report TLS failures is valuable. > >In addition to XML versa JSON, there are other reporting mechanisms like ARF >(see RFC 6650, for example) which seems applicable to this. ARF is about messages, this is about connections. >I am quite concern about yet another reporting mechanism, whi

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, without

Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-07.txt

>4.1. Notes on handling of SRV-ID by Certification Authorities >5.1. Notes on hosting multiple domains The multiple domain stuff still needs work, and there seems to be confusion between the domain name of the server (CN or SRV-ID) and the domain name(s) for the mail it handles (DNS-ID.) In nea

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

>1) use Server Name Indication TLS extension. At the moment none of the >email specs requires it. But maybe it is something that the draft should >encourage. >2) run each domain on its own IP/port, then each IP/port can use >separate certificate with a single domain. Given that there are mail s

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

>> What's to keep an evil MITM from putting dukhovni.org as a >> SRV-ID in its submit and imaps certificate? > >The trusted CA presumably, if it is not negligent. How is the trusted CA supposed to figure out which domains it should allow as SRV-ID? Here's a concrete real life example: I have a

Re: [Uta] UTA: Server certificate management (Re: Last Call: )

>The key word in that text is "another". This does not require the >server to have a certificate that matches this identifier, provided >there is some other some suitable identifier. It provides additional >flexibility, not a constraint. > >NOTE HOWEVER, that use of the server name from the SRV r

Re: [Uta] AD review of draft-ietf-uta-email-tls-certs-05

>IMHO, this is something for the to-be-written mail service discovery >document, which is not this spec. How does that differ from RFC 6186? I'd rather encourage people to implement the specs we already have. R's, John ___ Uta mailing list Uta@ietf.o

Re: [Uta] draft-moore-smtp-addrquery

Here's my use model: I set up my online access account at bigbank, and give them the address john+bigb...@example.com. Then they fetch my key and all the mail they send me is encrypted to my key. I'm also thinking that we should avoid making the perfect the enemy of the much better than we have n

Re: [Uta] draft-moore-smtp-addrquery

>Basically this is an extension to SMTP to allow mail exchangers to be >queried for information about the email addresses for which they accept >mail. >Such information could include public keys. >TLS is required by this extension and is used to authenticate the responses. This looks to me like