[Uta] Recording from irtfopen on email security using TLS

2016-04-06 Thread Orit Levin (CELA)
For those who didn't attend the irtfopen session on Tue, I recommend viewing the recording at https://www.youtube.com/watch?v=36WDbfKEIRI. The talk relevant to UTA starts at min 22. It provides a great intro to the challenges around using email with TLS. Orit.

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

2016-04-06 Thread Viktor Dukhovni
On Wed, Apr 06, 2016 at 10:52:14AM +0200, Daniel Margolis wrote: > > While I see benefits to hosters, what I've seen from community projects > > like bettercrypto(.org) is there's a lot of misunderstanding on how to > > properly configure services, a lot of bad information sources around for > >

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

2016-04-06 Thread John Levine
The question is whether there's something we can assemble from parts known to work that is less bloated than a full HTTPS client. R's from my fone, John On Apr 6, 2016 12:34, Daniel Margolis wrote:That's a pretty depressing conclusion, but yes, I think this is a compromise

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

2016-04-06 Thread 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

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

2016-04-06 Thread Jeremy Harris
On 06/04/16 10:49, Daniel Margolis wrote: > I do agree that an SMTP dependency on HTTPS doesn't feel great, but what > are the concrete issues? Is libcurl that much worse than libresolv? Nothing concrete. However, you are not swapping libresolv for libcurl, you're adding libcurl to the

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

2016-04-06 Thread Jeremy Harris
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