IETF
uta
uta@jabber.ietf.org
Monday, April 4, 2016< ^ >
Yoav Nir has set the subject to: UTA Meeting - IETF 93
Room Configuration
Room Occupants

GMT+0
[09:23:17] dmargolis joins the room
[10:43:48] dmargolis leaves the room
[10:51:18] dmargolis joins the room
[15:54:09] Meetecho joins the room
[16:36:08] Jim Fenton joins the room
[16:36:39] dmargolis leaves the room: Replaced by new connection
[16:36:40] dmargolis joins the room
[16:37:02] dmargolis joins the room
[16:43:35] mrisher joins the room
[16:43:51] <mrisher> did I figure this out correctly?
[16:44:03] Mark Risher joins the room
[16:47:20] abrotman joins the room
[16:47:33] <mrisher> hello Alex
[16:47:35] abrotman waves
[16:47:45] <mrisher> fancy
[16:48:02] <abrotman> I'll pop out/in when I change rooms in a few minutes
[16:51:14] Mark Risher leaves the room
[16:52:46] mrisher leaves the room
[16:53:02] <dmargolis> Hi.
[16:54:59] sftcd joins the room
[16:55:43] Mark Risher joins the room
[16:56:23] Tony Hansen joins the room
[16:56:26] ned.freed@xmpp.pro joins the room
[16:56:41] Pulkit Manocha joins the room
[16:57:12] <Tony Hansen> @meetecho, meetecho did not remember my name/reg-number from this morning's session. :-(
[16:57:59] <Jim Fenton> Tony, are you here or remote?
[16:58:13] <Meetecho> Tony Hansen: have you ticked the "Remember me" checkbox when joining? that should try and remember you across sessions
[16:58:20] Binu Ramakrishnan joins the room
[16:58:23] Tom Zeller joins the room
[16:58:31] <Tony Hansen> of course
[16:58:41] Aaron Zauner joins the room
[16:58:54] NIKHIL SINGH joins the room
[16:59:06] <Tony Hansen> it did remember my picture, but nothing else
[16:59:23] Viktor Dukhovni joins the room
[16:59:39] <Tony Hansen> @Jim, I'm remote
[16:59:39] Ned Freed joins the room
[17:00:13] Ned Freed leaves the room
[17:00:14] Daniel Margolis joins the room
[17:00:45] Binu Ramakrishnan leaves the room
[17:00:48] ben joins the room
[17:00:54] Anjali Goyal joins the room
[17:01:28] Barry Leiba joins the room
[17:01:51] Ned Freed joins the room
[17:02:15] rsalz joins the room
[17:02:25] Andrew McConachie joins the room
[17:02:29] Mark Risher leaves the room
[17:02:41] <rsalz> I'm the scribe, ping me if don't recognize you in time. (r$)
[17:02:51] Ken Murchison joins the room
[17:03:10] Ned Freed leaves the room
[17:03:33] <sftcd> https://www.ietf.org/proceedings/95/slides/slides-95-uta-3.pdf
[17:03:37] Franck Martin joins the room
[17:05:07] Franck Martin_3574 joins the room
[17:06:09] Gregorio Manzano REACCIUN joins the room
[17:06:43] Joe Hall joins the room
[17:07:46] Binu Ramakrishnan joins the room
[17:07:52] <rsalz> email and tls:  https://www.ietf.org/proceedings/95/slides/slides-95-uta-4.pdf <https://www.ietf.org/proceedings/95/slides/slides-95-uta-3.pdf> mark risher
[17:07:54] JoeHallCDT joins the room
[17:08:28] Anjali Goyal leaves the room
[17:08:44] dmargolis leaves the room: Replaced by new connection
[17:08:44] dmargolis joins the room
[17:08:45] Gregorio Manzano REACCIUN leaves the room
[17:08:52] Lucy Lynch joins the room
[17:09:46] Lucy Lynch leaves the room
[17:09:49] Ned Freed joins the room
[17:09:49] Daniel Margolis leaves the room
[17:10:05] Anjali Goyal joins the room
[17:11:31] Daniel Margolis joins the room
[17:12:05] Isha Pinani joins the room
[17:12:30] NIKHIL SINGH leaves the room
[17:12:54] NIKHIL SINGH joins the room
[17:13:09] Andrew Sullivan joins the room
[17:13:16] Isha Pinani leaves the room
[17:15:45] Isha Pinani joins the room
[17:16:51] Isha Pinani leaves the room
[17:18:41] <Andrew Sullivan> The whole point here is that you're trying to avoid DNSSEC, so you're going to rely on the DNS data without DNSSEC to tell you whether there's a policy?
[17:18:44] <Andrew Sullivan> Seems nuts to me
[17:19:10] <Daniel Margolis> Without DNSSEC there's no good way to get a signed "NXDOMAIN" equivalent, but that's not as nuts as it appears (I think!).
[17:19:15] <Viktor Dukhovni> Yes for compression of DNS to a single bit that indicates support for the STS HTTPS mechanism
[17:19:26] <Aaron Zauner> thinking, could there be possible attacks on http cache control (poisioning)?
[17:19:30] <Daniel Margolis> HSTS of course works the same way.
[17:19:36] Anjali Goyal leaves the room
[17:20:10] Anjali Goyal joins the room
[17:20:15] yone joins the room
[17:20:24] Sean Turner joins the room
[17:20:34] <Binu Ramakrishnan> record in the DNS is just an indicator, and we validate it with webpki
[17:20:47] <Daniel Margolis> Aaron, what are you thinking of?
[17:20:54] <rsalz> at mic now
[17:21:19] DanYork joins the room
[17:21:24] <Andrew Sullivan> Sorry, that wasn't intended to be a mic thing :)
[17:21:30] <Aaron Zauner> @margolis: not sure if possible, would need to investigate - cache poisoning basically
[17:21:36] John Levine joins the room
[17:21:40] resnick joins the room
[17:21:47] <sftcd> @rich: suggest asking folks who want you to go to mic to prefix their comments with mic:
[17:21:51] Anjali Goyal leaves the room
[17:22:00] jeff.hodges@ecotroph.net joins the room
[17:22:09] <rsalz> mea culpa.
[17:22:17] <resnick> Andrew is unlikely to be shy about getting up to the mic. :-)
[17:22:20] <sftcd> being too helpful:-)
[17:22:20] tale joins the room
[17:22:24] <Barry Leiba> Hey, you didn't know the custom.
[17:22:36] <rsalz> Don't know all the players, didn't realize who was in-room vs note.
[17:22:41] <Barry Leiba> We usually do "mic: I have a comment here" when we want to be channeled.
[17:22:42] <Daniel Margolis> (Me, neither.)
[17:22:58] <rsalz> Got it, "mic:" if you want me to relay
[17:23:14] <ned.freed@xmpp.pro> I am more than a little uncomfortable with the dependency on putting a full https client in the SMTP client.
[17:23:21] <tale> ^
[17:23:37] <Daniel Margolis> Ned: Agreed, but note that you can populate the policy cache offline, not necessarily from the MTA.
[17:24:05] Binay Kumar joins the room
[17:24:08] Anjali Goyal joins the room
[17:24:14] <Daniel Margolis> (At cost of some mail sent before you discover a policy for a given destination domain.)
[17:24:14] <Franck Martin> I believe in DANE, but not sure all receivers can do it, while they could do STS
[17:24:14] Steve Olshansky joins the room
[17:24:18] <John Levine> @ned: I'm not crazy about that either
[17:24:33] <ned.freed@xmpp.pro> Really? You're going to populate the cache in response to streams of thousands of messages a second to essentially random destinations?
[17:24:33] <John Levine> it sure would bulk up my mailfront servers
[17:24:44] <Franck Martin> DANE, requires to DNSSEC your zone, and that's a high barrier for some
[17:24:47] <Aaron Zauner> @margolis: how would you populate offline? via CSV provided by a third party?
[17:25:15] <Daniel Margolis> No, what I mean is that if your MTA logs domains that it does not yet have a policy for, you can later grep the logs and "pre"-fetch policies for those domains.
[17:25:32] <Daniel Margolis> Yes, you might want to have a bundle of commonly-known policies (as with e.g. HPKP in some browsers).
[17:25:44] <Aaron Zauner> mhm
[17:25:52] <ned.freed@xmpp.pro> Having just gone through the dnssec exercise for a couple of domains, I'm well aware of the pain associated with it. But I've also been through the pain of getting certificates for web servers, and IMNSHO it's far more painful than dnssec.
[17:26:15] <Joe Hall> @meetecho: video frozen (not super-important but figure you'd want to know)
[17:26:16] <Aaron Zauner> pre-fetching would require intimate knowledge of SMTP-STS and the daemon software, I figure?
[17:26:17] <ned.freed@xmpp.pro> It also costs a lot more $$$
[17:26:30] <Daniel Margolis> Aaron, not sure what you mean.
[17:26:47] <Binu Ramakrishnan> ned, try letsencrypt, it is free and can be automated :)
[17:26:47] <Daniel Margolis> Ned: Let's Encrypt is free, right?
[17:26:50] Rik Ribber joins the room
[17:27:13] <resnick> “Phil Hallam-Baker Komodo -Komodo”. I think I know how to simplify that equation. :-)
[17:27:20] <Franck Martin> @ned.freed: DNSSEC is the DNS admin, which is usually a different team than the mail team…
[17:27:24] <Aaron Zauner> well. as an operator. if you don't do webpki and want to pre fetch you need tooling for that, either supplied by daemons or you'll need to write it on your own (and figure out how SMTP-STS works) - unlikely for small operators
[17:27:42] <Meetecho> FYI for remote chairs: there's someone in the virtual queue
[17:27:47] <Meetecho> you can unmute him pressing the "big red button"
[17:27:47] <Daniel Margolis> Oh, I agree with that. I don't want everyone to have to write their own pre-fetcher. ;)
[17:27:54] Paolo Saviano joins the room
[17:28:03] <DanYork> Oh man... do we need to get up there and give PHB deployment stats...
[17:28:07] <ned.freed@xmpp.pro> And the http folks are the same team? That's even less likely in my experience.
[17:28:07] Robert Martin-Legene joins the room
[17:28:07] <Daniel Margolis> But you could ship MySMTPServer and MySmtpServerPrefetcher.
[17:28:19] Rik Ribber leaves the room
[17:28:20] <resnick> Yes, they noticed Viktor in the queue. He’s in the mic line.
[17:28:21] <DanYork> @Meetecho - the chairs are aware
[17:28:51] <Andrew Sullivan> Did Phill just say that we're going to ditch DNSSEC because it doesn't work, so we're going to encode a whole new set of things in the DNS instead?
[17:28:54] <Franck Martin> @ned: but put a jason/xml file in your https tree is easier than DNSSEC your zone...
[17:29:00] <ned.freed@xmpp.pro> Let's Encrypt isn't practical for email. Try it and see - i have.
[17:29:01] Anjali Goyal leaves the room
[17:29:18] <Daniel Margolis> Hmm. Why not? Maybe we can file bugs against them?
[17:29:26] <JoeHallCDT> yeah, can't get non-web certs from LE at this point in time
[17:29:30] Anjali Goyal joins the room
[17:29:32] <JoeHallCDT> AFAIK
[17:30:32] Robert Martin-Legene leaves the room
[17:30:35] <Aaron Zauner> margolis: sure, I'm not saying I we can't do that, but the average guy running ubuntu and trying to set up their exim or postfix might have issues (until supplied by the distributions themselves)
[17:30:50] <Aaron Zauner> that's in general my biggest concern
[17:30:56] <ned.freed@xmpp.pro> Exactly. Let's Encrypt is barely capable of handling some limited web server situations at this point. Email is clearly not on their radar at all. And I'm not sure it should be.
[17:31:02] <Aaron Zauner> I'm sure large ESPs have proper engineers ;)
[17:31:23] <Andrew Sullivan> Define "very long time".  All the evidence I have suggests that most DNS caches don't actually live any longer than 24 hours, and busy ones a whole lot shorter
[17:31:39] <Daniel Margolis> Aaron, yeah, that's a fair point. I think this is a question for developers of such MTAs, but I can think of a few reasonable (IMO) solutions.
[17:31:40] <Anjali Goyal> hummmmm
[17:31:40] <Anjali Goyal> hummmmm
[17:31:42] <Aaron Zauner> ned: email is on our radar
[17:31:59] <Andrew Sullivan> The DNS TTL doesn't tell you how long to cache.  It tells you how long you _may_ cache
[17:32:05] <Aaron Zauner> ned: we're picking up starttlseverywhere again and will integrate with let's encrypt
[17:32:16] <Daniel Margolis> Right. DNS TTL can be order of minutes/hours.
[17:32:17] <ned.freed@xmpp.pro> Whereas the average guy running ubuntu can get dnssec up and running. It's a PITA not so much because it's hard but rather because there's so much bad information about how to do it out there.
[17:32:22] <Aaron Zauner> ned: possibly supporting drafts discussed in UTA
[17:32:27] Paolo Saviano leaves the room
[17:32:34] <Viktor Dukhovni> SMTPS and HTTPS are NOT the same sort of thing.
[17:32:42] <Franck Martin> EFF method is to distribute a file with policies, STS allows to scale
[17:32:56] <Daniel Margolis> Right.
[17:32:59] <Aaron Zauner> it was
[17:32:59] <DanYork> A colleague of mine, Jan Zorz, wrote up about using Lets Encrypt with email via postfix:  http://www.internetsociety.org/deploy360/blog/2016/01/lets-encrypt-certificates-for-mail-servers-and-dane-part-1-of-2/
[17:33:10] <Viktor Dukhovni> MX indirection fundamentally changes the security model.
[17:33:52] <ned.freed@xmpp.pro> In regards to starttlseverywhere and with all due respect, I'll believe it when I see it.
[17:34:06] <John Levine> @ned: getting DNSSEC running is straightforward, persuading your registrar to install the DS record often is not. Whole separate argument in other WGs.
[17:34:18] <tale> and ICANN
[17:34:32] <Jim Fenton> +1
[17:34:39] <Aaron Zauner> ned: np, it's been idle for 2yrs. picking up now and let's see what makes most sense. we're going with what makes sense for mail not https
[17:34:48] <Franck Martin> a few DNS hosters, cannot do DNSSEC and GSLB
[17:34:53] <JoeHallCDT> @aaron z: very cool
[17:34:55] <Daniel Margolis> Glad to hear that, Aaron.
[17:34:57] NIKHIL SINGH leaves the room
[17:35:08] <Anjali Goyal> Fulll
[17:35:27] <JoeHallCDT> is the current slide still "desire properties" or is my meetecho out of sync?
[17:35:41] <Daniel Margolis> It's out of sync.
[17:35:41] <JoeHallCDT> ty
[17:35:41] <Andrew Sullivan> Lots of DNS hosters can't do DNSSEC and GSLB, because doing that requires signing on the fly and therefore puts the signing keys out at the edge
[17:35:41] <John Levine> it has Chris Newman at the top
[17:35:54] <tale> "Chris Newman on In-Band Distribution" is cur. slide
[17:36:02] <Meetecho> JoeHallCDT: if slides stopped, try rejoining, it may have been a hiccup, sorry
[17:36:57] <ned.freed@xmpp.pro> Due to some early price breaks I have some domains with Network Solutions, I'm well aware of the registry problem. The solution to that is to switch to a competent registrar. Which is still *way* cheaper than certs.
[17:37:00] Joe Hall_resynced joins the room
[17:37:07] Joe Hall leaves the room
[17:37:09] <Daniel Margolis> That's an interesting question. But on the flip side, don't we think the MX host will be more likely to know the right policy (especially for less sophisticated customers)?
[17:37:29] <John Levine> I get certs from startcom for $0 for my MTAs
[17:38:17] <John Levine> also, DNSSEC issue when DNS provider is not the registrant. I host DNS for lots of people and do not want to ask them for their registrar logins
[17:38:49] NIKHIL SINGH joins the room
[17:39:02] <Anjali Goyal> Fulll. Form of dnssec
[17:39:53] Franck Martin leaves the room
[17:40:09] Franck Martin joins the room
[17:40:52] <Aaron Zauner> who's on mike?
[17:40:59] <Binu Ramakrishnan> @aron, the current sts proposal supports both https and dnssec. If your domain support dnssec, then you dont need https endpoint
[17:41:02] <resnick> That was Richard Barnes.
[17:41:23] <Franck Martin> @ned: take all the big mailbox providers, with all these engineers, check why so many don't have their zone signed? Where is the problem? Why it has not happened already?
[17:41:30] <Aaron Zauner> @ramakrishnan: I know, I've read it. DNSSEC solves nothing for me unfortunately.
[17:41:41] <Aaron Zauner> not really a believer in it *duck*
[17:41:56] <Aaron Zauner> though I hear of big deployments to happen this year
[17:42:02] Franck Martin_3574 leaves the room
[17:42:05] Anjali Goyal leaves the room
[17:42:07] <ned.freed@xmpp.pro> I investigated startcom. There was a showstopper there but I don't remember the details
[17:42:37] <John Levine> huh. "works fine for me" at small scale, four MTA certificates
[17:42:45] Franck Martin_3297 joins the room
[17:42:46] Robert Martin-Legene joins the room
[17:42:51] <JoeHallCDT> @meetecho: a hard reload of the meetecho page (shift-cmd/ctrl-R) seems to fix the sync issue (not sure what is causing it but it happens reasonably frequently to where logging back in super-sucks)
[17:43:01] <John Levine> FYI, comodo is $7 through resellers, certs really are cheap now
[17:44:01] NIKHIL SINGH leaves the room
[17:44:12] <ned.freed@xmpp.pro> Oh yeah, no commerical use. Showstopper.
[17:44:19] NIKHIL SINGH joins the room
[17:44:52] <John Levine> ah
[17:45:03] <John Levine> $7 comodo should be OK
[17:45:21] <Franck Martin> hmmm
[17:45:25] <ned.freed@xmpp.pro> comodo was around $200 minimum as I recall.
[17:45:25] <Aaron Zauner> hummmmm
[17:45:28] <JoeHallCDT> hummmm
[17:45:37] Anjali Goyal joins the room
[17:46:06] <Viktor Dukhovni> I'd like to see a simplified -01 first.
[17:46:13] <Aaron Zauner> (pinning in general, reporting: yes. webpki: no, dnssec: don't care at all at the moment, tbh - maybe in the future)
[17:46:13] <Franck Martin> hmm
[17:46:20] <Daniel Margolis> Viktor: Kind of agree, since we have a bunch of changes we want to make. :)
[17:46:37] <John Levine> https://www.ssls.com/ssl-certificates/comodo-positivessl
[17:46:50] Joe Hall joins the room
[17:46:54] <DanYork> dkg at mic
[17:47:13] Joe Hall_resynced leaves the room
[17:47:32] <DanYork> For remote attendees, it would be good if you qualify your hum, i.e. "hum yes on first question"
[17:47:47] <ned.freed@xmpp.pro> I'll see what they offer
[17:47:47] <Aaron Zauner> opened a thread with a problem statement a while ago: "dealing with starttls stripping" - in general I guess 'pinning' and 'reporting' w.r.t. MITM attacks
[17:47:55] <DanYork> There's often a time lag and it's hard to know what remote hums mean with multiple hums
[17:48:07] <Aaron Zauner> hummmmm
[17:48:10] <JoeHallCDT> hummmm
[17:48:26] <resnick> Which thing did you just hum for?
[17:48:27] <Daniel Margolis> Yeah, I have yet to reply to your last email, Aaron.
[17:48:44] <Barry Leiba> Remote hummers should not just hum: please say what your choice is instead.
[17:49:04] <Aaron Zauner> margolis: np, take your time, I didn't get to write until today :/
[17:49:06] <Franck Martin> take as WG
[17:49:28] <rsalz> Chris Newman: DEEP email and tls
[17:49:50] Mark Risher joins the room
[17:50:11] Mark Risher leaves the room
[17:51:00] <rsalz> https://www.ietf.org/proceedings/95/slides/slides-95-uta-0.pdf
[17:51:09] <JoeHallCDT> ty @rsalz
[17:51:22] <JoeHallCDT> @meetecho: not sure what it takes to get slides to sync, but I give up
[17:51:46] <Meetecho> JoeHallCDT: they should always be in sync, not sure what's causing them to fail for you, is the bandwdth enough?
[17:51:56] <Meetecho> all streams are live and not buffered
[17:52:03] <Meetecho> as an alternative you can try the webinar mode
[17:52:12] <JoeHallCDT> @meetecho: yes, plenty of bwidth
[17:52:21] <Meetecho> http://conf.meetecho.com/video?s=atlanticoc&r=uta&c=8895029
[17:52:31] <Meetecho> it will display slides as a flash video
[17:52:32] <Meetecho> which may work better for you
[17:53:03] <Tony Hansen> hum meh
[17:53:34] <Binu Ramakrishnan> @aaron, you do have any writeup that discuss about solutions to fix mta starttls
[17:54:03] Ken Murchison leaves the room
[17:54:22] <JoeHallCDT> @meetecho: seems reloading works, just have to do it often
[17:54:27] Dan Wing joins the room
[17:54:55] jeff.hodges@ecotroph.net leaves the room
[17:54:55] jeff.hodges@ecotroph.net joins the room
[17:54:57] Andrew Sullivan leaves the room
[17:55:21] Paolo Saviano joins the room
[17:55:22] <Aaron Zauner> @ramakrishnan: like a competing draft? no. there's been a lot of previous research and discussion on the topics on IETF lists and other mediums
[17:55:33] Anjali Goyal leaves the room
[17:55:36] <DanYork> @Meetecho - we're not able to hear the remote person in the queue
[17:55:56] <Meetecho> can you hear Viktor now?
[17:56:01] <JoeHallCDT> yes
[17:56:07] <DanYork> yes, we hear viktor
[17:56:09] <Binu Ramakrishnan> ok
[17:56:11] Dan Wing leaves the room
[17:56:18] Robert Martin-Legene leaves the room
[17:56:19] <DanYork> We weren't hearing Anjali who was in the queue and spoke
[17:56:29] <Meetecho> possibly an issue with the previous speaker, then: not sure he did the self-test in advance to make sure things would work
[17:56:38] <Aaron Zauner> @ramakrishnan: are you looking for something specific?
[17:57:01] Dan Wing joins the room
[17:57:12] Anjali Goyal joins the room
[17:58:03] Joe Hall leaves the room
[17:58:25] <Binu Ramakrishnan> @aaron, interested to learn about your solution
[17:58:55] Andrew Sullivan joins the room
[17:58:57] Joe Hall joins the room
[17:59:23] <Aaron Zauner> @ramakrishnan: I wrote to list a couple of times about that already. I like your reporting and some concepts so I don't think a competing draft would be very constructive
[17:59:48] <Binu Ramakrishnan> @aaron: ok
[17:59:54] <Daniel Margolis> Regarding TACK, I just replied to your email, Aaron.
[17:59:55] <Daniel Margolis> Just FYI.
[18:00:01] <Aaron Zauner> thanks
[18:00:09] <Viktor Dukhovni> Alignment not possible if in-band is per-mx but STS is per-domain
[18:00:27] <DanYork> Viktor Dukhovni: is that for the mic?
[18:00:35] <Daniel Margolis> Viktor: I think you could do in-band per-domain, but it probably requires some other SMTP verb, no?
[18:01:50] <rsalz> REQUIRETLS  Jim Fenton https://datatracker.ietf.org/doc/slides-95-uta-1/
[18:02:04] Tony Hansen leaves the room
[18:03:16] Tony Hansen joins the room
[18:04:44] Joe Hall leaves the room
[18:05:16] NIKHIL SINGH leaves the room
[18:05:16] Andrew Sullivan leaves the room
[18:05:32] Joe Hall joins the room
[18:05:50] NIKHIL SINGH joins the room
[18:07:04] Anjali Goyal leaves the room
[18:07:09] <Viktor Dukhovni> The more bells and whistles this supports the less deployment this will get
[18:07:51] Paolo Saviano leaves the room
[18:10:31] <John Levine> I've already fully implemented it
[18:10:36] <John Levine> My MX is signed with DNSSEC
[18:10:49] <John Levine> the MTA advertises the REQUIRETLS option
[18:10:52] <John Levine> it accepts the option
[18:10:58] <John Levine> then ignores it
[18:13:07] dmargolis leaves the room: Replaced by new connection
[18:13:07] dmargolis joins the room
[18:13:39] Daniel Margolis leaves the room
[18:13:42] <abrotman> Would RequireTLS fail if you have a multi-stage platform if some internal nodes (non-internet-accessible) do not support TLS?  I may have missed this, but I didn't see it covered in the draft
[18:13:45] NIKHIL SINGH leaves the room
[18:14:03] Daniel Margolis joins the room
[18:14:23] NIKHIL SINGH joins the room
[18:14:43] <Binu Ramakrishnan> what about mailing list and mail forwarders?
[18:15:24] <Binu Ramakrishnan> would it bounce back if it fails in the final hop?
[18:15:40] <DanYork> I was going to stand up adn ask about deployability ... but others are asking that question.
[18:16:05] dmargolis leaves the room: Replaced by new connection
[18:16:08] dmargolis joins the room
[18:16:54] Daniel Margolis leaves the room
[18:17:34] Daniel Margolis joins the room
[18:18:30] Joe Hall leaves the room
[18:20:41] Joe Hall joins the room
[18:22:19] <John Levine> Now he's arguing against himself
[18:22:21] rlb joins the room
[18:22:25] <rlb> this is negatively useful
[18:22:33] <John Levine> if only the first hop matters, just look for STARTTLS and be done with it
[18:22:34] <rlb> it does nothing to advance the cause of the being more TLS in the ecosystem
[18:22:43] <Daniel Margolis> Is the goal to protect the long hop or to make it so that the MUA can show the user something positive about TLS?
[18:22:48] <rlb> test test
[18:22:53] <Daniel Margolis> rlb: works.
[18:22:57] <rlb> this does nothing to advance the usage of TLS
[18:23:08] <rlb> security by DOS is not helpful
[18:23:19] <Daniel Margolis> I remain a fan of allowing MUAs to show users security promises.
[18:23:25] <Aaron Zauner> people suggested bouncing non-TLS secured MTA messages in the past
[18:23:28] <Viktor Dukhovni> The "long hop" to the outbound MTA is better handled via custom headers than an ESMTP feature
[18:23:28] <Aaron Zauner> bad idea
[18:23:29] <Daniel Margolis> I'm not sure if REQUIRETLS is quite the right way to do it or not.
[18:23:51] <Daniel Margolis> Viktor: I thought he was referring to the hop from sending MTA to receiving MTA (sender.com -> receiver.com).
[18:24:00] <Joe Hall> please state the whole question
[18:24:21] <rlb> "the ability to indicate a preference for security over deliverability"
[18:24:25] <Aaron Zauner> margolis: DEEP has a few good ideas about user indicators
[18:24:31] <Daniel Margolis> Yeah.
[18:24:39] <Daniel Margolis> But it doesn't make promises about server-to-server SMTP.
[18:24:41] <Joe Hall> hummmmm
[18:24:44] <Aaron Zauner> I like that as well
[18:24:57] <Aaron Zauner> no I figure it's entirely for client/server
[18:25:00] Suzanne joins the room
[18:25:04] <JoeHallCDT> my hum was support the question
[18:25:11] <Daniel Margolis> Right. I was saying that the "long hop" is server-to-server.
[18:25:27] <sftcd> seemed from here like the back of the room didn't like it as well as the front of the room:-)
[18:25:31] <Daniel Margolis> I think it would be nice to show users something about that.
[18:25:33] <Aaron Zauner> sure. sorry - that was out of context, w.r.t. user-indicators
[18:25:38] <Daniel Margolis> Right.
[18:25:54] <Aaron Zauner> yes, I agree
[18:26:08] <Daniel Margolis> Anyway, I think I said on the mailing list that I actually want to use STS to show such indicators at least in some cases, but we didn't specify a way for this to work for other MUAs.
[18:26:21] <Daniel Margolis> STS could be done in e.g. the webmail case, which is admittedly my parochial concern.
[18:26:30] <Daniel Margolis> But I couldn't see a great way to do this in an MUA agnostic way.
[18:26:40] <Daniel Margolis> REQUIRETLS attempts this, which I think is a noble goal, but I think it's a very tricky problem.
[18:27:06] <rlb> wait, is "Joe Hall" or "JoeHallCDT" the real one?
[18:27:11] <JoeHallCDT> ha
[18:27:12] <Daniel Margolis> (Sorry. That wasn't a very clear comment. What I mean is that with STS we could probably show a security indicator in the case where it's webmail, but not in other cases.)
[18:27:14] <rlb> will the real JoeHall please stand up?
[18:27:26] <Viktor Dukhovni> The most important bump in TLS use happened in February when Google's inbound TLS jumped from 55% to 70% because users see which email arrived via TLS
[18:27:30] NIKHIL SINGH leaves the room
[18:27:31] <JoeHallCDT> I'll be sure to hum using the meetecho interface, which is what I did above.
[18:27:38] <rsalz> Dacheng: TLS extension for service extension.
[18:27:46] Sean Turner leaves the room
[18:27:46] rlb leaves the room
[18:27:47] <rsalz> https://datatracker.ietf.org/doc/slides-95-uta-2/1/
[18:27:55] <Daniel Margolis> Viktor: And if you wanted to show an outbound indicator, what would you do?
[18:28:02] Andrew Sullivan joins the room
[18:28:27] <rsalz> interesting timing of when people left.
[18:29:15] <abrotman> @daniel: ideally, or in today's world?
[18:29:28] <JoeHallCDT> I'm sure Ted would like more eyeballs on this, which is relevant: https://github.com/IAB-PrivSec-program/draft-iab-privsec-metadata-insertion
[18:29:35] yone leaves the room
[18:29:40] <Daniel Margolis> Alex: Eh, both?
[18:30:05] Joe Hall leaves the room
[18:30:13] <Aaron Zauner> big ESPs have the nobility of fetching STS information for webUI indicators
[18:30:27] <Aaron Zauner> javascript :)
[18:30:42] <abrotman> @daniel, If we all live in a DNSSEC world with DANE records, etc, does that make it easier?
[18:30:55] Joe Hall joins the room
[18:31:03] <abrotman> for outbound indicators I mean
[18:31:05] <Daniel Margolis> Not necessarily. What do you do? Fetch the DANE record at compose time, see if it has a long TTL, set the indicator?
[18:31:11] <Daniel Margolis> What if someone has DANE on some MXes and not others?
[18:31:22] <Daniel Margolis> It's solvable, but I'm not sure what the *right* solution is. Ignore non-DANE MXs?
[18:31:25] rlb joins the room
[18:31:37] <Daniel Margolis> Don't show a "will be secure" indicator if the TLSA TTL is fairly shore?
[18:31:45] Barry Leiba leaves the room
[18:31:47] <Daniel Margolis> *shrug*
[18:31:48] <abrotman> well, we're living in a world with all DANE records, I said that already :)
[18:31:57] <Daniel Margolis> Oh, right. Sorry. ;)
[18:32:06] <Aaron Zauner> I didn't understand this draft either
[18:32:10] <JoeHallCDT> "the layer violation fairy has seemed to visit you and dropped all her violation dust upon you" -Ted
[18:32:22] <sftcd> yeah that's cute
[18:32:25] <Daniel Margolis> Yeah, I mean, if you know they'll have DANE, you just show the lock icon all the time. Not very interesting as an answer, though. ;)
[18:32:40] <abrotman> Your users will thank you!
[18:32:56] <Daniel Margolis> OK, and what's your answer in the current world?
[18:33:02] tale leaves the room
[18:33:04] ben leaves the room
[18:33:05] <Daniel Margolis> (OK, we'll talk some other time. I'm going to get dinner.)
[18:33:05] John Levine leaves the room
[18:33:08] Suzanne leaves the room
[18:33:10] JoeHallCDT leaves the room
[18:33:11] jeff.hodges@ecotroph.net leaves the room
[18:33:11] Franck Martin_3297 leaves the room
[18:33:13] <Daniel Margolis> Thanks, everyone.
[18:33:15] Joe Hall leaves the room
[18:33:24] <Viktor Dukhovni> @daniel, we can discuss outbound issues via email
[18:33:32] <abrotman> Wow, they finished in a hurry
[18:33:33] ned.freed@xmpp.pro leaves the room
[18:33:34] Steve Olshansky leaves the room
[18:33:35] rsalz leaves the room
[18:33:43] <abrotman> Mic drop, and run
[18:33:47] Franck Martin leaves the room
[18:33:56] Viktor Dukhovni leaves the room
[18:33:56] Ned Freed leaves the room
[18:33:56] Tony Hansen leaves the room
[18:33:56] Andrew McConachie leaves the room
[18:33:56] Binu Ramakrishnan leaves the room
[18:33:57] Pulkit Manocha leaves the room
[18:33:58] Aaron Zauner leaves the room
[18:34:00] Binay Kumar leaves the room
[18:34:08] Jim Fenton leaves the room
[18:34:23] Daniel Margolis leaves the room
[18:34:24] DanYork leaves the room
[18:34:31] Tom Zeller leaves the room
[18:35:15] Meetecho leaves the room
[18:37:19] Dan Wing leaves the room
[18:37:35] resnick leaves the room
[18:39:03] Andrew Sullivan leaves the room
[18:39:42] Sean Turner joins the room
[18:43:27] Sean Turner leaves the room
[18:47:51] rlb leaves the room
[18:48:14] Dan Wing joins the room
[18:49:08] sftcd leaves the room
[18:49:41] richsalz joins the room
[18:50:56] tale joins the room
[18:51:14] sftcd joins the room
[18:51:21] Jim Fenton joins the room
[18:51:30] Suzanne joins the room
[18:51:37] sftcd leaves the room
[18:51:57] Jim Fenton leaves the room
[18:52:03] resnick joins the room
[18:52:10] Dan Wing leaves the room
[18:52:23] Suzanne leaves the room
[18:53:21] resnick leaves the room
[18:55:16] Andrew Sullivan joins the room
[18:56:01] Andrew Sullivan leaves the room
[18:57:53] dmargolis leaves the room
[18:58:29] ben joins the room
[18:59:44] rlb joins the room
[19:05:32] tale leaves the room
[19:05:59] rlb leaves the room
[19:07:20] rlb joins the room
[19:09:45] dmargolis joins the room
[19:22:04] richsalz leaves the room
[19:25:36] Mark Risher joins the room
[19:28:44] ben leaves the room
[20:13:30] rlb leaves the room
[20:21:52] dmargolis leaves the room
[20:24:30] Mark Risher leaves the room
[20:32:05] abrotman leaves the room
[21:59:15] Mark Risher joins the room
[22:37:58] Mark Risher leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!