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

Hi Binu, First off: sorry for the very late reply, I've been moving to another continent temporarily. > On 06 Apr 2016, at 08:42, Binu Ramakrishnan wrote: > > Aaron, I think the important point here is when you say TOFU (Trust On First > Use) - that means no trust anchor is

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

On Mon, Apr 11, 2016 at 10:07:14AM +0200, Daniel Margolis wrote: > I see your point. But I think one thing still needs to be specified. In the > smarthost case, what domain is used to validate the server certificate > during the HTTPS policy fetch? The nexthop domain. It may, or may not, be

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

On Sun, Apr 10, 2016 at 12:00:07AM +0200, David Schweikert wrote: > > Just because email is ultimately going to say Gmail, if my nexthop > > relay is some corporate outbound smarthost, the relevant STS policy > > is for that relay, not the destination domain. > > OK, got it. But this is going to

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

On Fri, Apr 08, 2016 at 19:06:16 +, Viktor Dukhovni wrote: > > I don't understand this: why would the STS client do a policy lookup not > > on the recipient address? I understand that you can have a different > > nexthop specified in your transport map, but why look that up instead of > > the

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

Hi Viktor, On Wed, Apr 06, 2016 at 22:40:40 +, Viktor Dukhovni wrote: > * Is it enough for delivery via just the first MX tried to succeed? >Or does the initial delivery need to confirm more than one MX host? > > * Is delivery to a second MX host after failing the first a "success"? >

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

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

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

> 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

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

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

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

ogle.com>; "uta@ietf.org" <uta@ietf.org>; Orit Levin (CELA) <or...@microsoft.com>; Daniel Margolis <dmargo...@google.com> Sent: Tuesday, 5 April 2016 3:26 PM Subject: Re: [Uta] New proposal: SMTP Strict Transport Security Hi, > On 05 Apr 2016, at 03:13,

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

Hi, > On 05 Apr 2016, at 11:16, Daniel Margolis wrote: > Could you go a bit into what you consider "mx indirection" and where you see > problems there? e.g. a specific problem statement. I'm not sure I follow. > > To slightly paraphrase Binu's reply, I think one of the

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

Hi, > On 05 Apr 2016, at 03:13, Binu Ramakrishnan wrote: > 1. TACK TOFU model promotes trusting self-signed certificates. It is similar > to SSH and it is less trusted than PKIX. You can use TACK with self-signed or with CA signed certificates. I'm not sure I agree that

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

Hi, > On 05 Apr 2016, at 01:44, Binu Ramakrishnan wrote: > > Aaron, > > Whether we use Git to distribute policies or use CT append logs, we still > need to pull policies using HTTPS (or something similar). From that > perspective, STS's webpki model is not different. If you

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

On Mon, Apr 04, 2016 at 05:24:59PM +0200, Aaron Zauner wrote: > As for authentication/TOFU: I see no better proposal than TACK around. I was briefly interested in TACK for SMTP before I started work on DANE 2 years ago, but gave up after realizing that TACK cannot protect the MX records.

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

Hi Daniel, > On 04 Apr 2016, at 19:56, Daniel Margolis wrote: > > It's been a long time since I looked at TACK, but if I remember right, > doesn't this only help with the CA/trust issue? > > To me the big question with STS as is is how to exchange policy/routing >

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

On April 4, 2016 at 11:03:33 , Mark Risher (ris...@google.com) wrote: >> Do you really think an end-user can understand what it means if the MTA will >> transport encrypt the next hop of mail relay but can say nothing about relay >> hops after that or how the mail is handled by either service

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

On 4/4/16 5:45 AM, Jeremy Harris wrote: > On 04/04/16 13:01, Jim Fenton wrote: >> On 4/4/16 3:14 AM, Jeremy Harris wrote: >>> On 01/04/16 23:18, Viktor Dukhovni wrote: On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: > I feel very strongly that policy for SMTP relay should be

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

On 04/04/16 13:01, Jim Fenton wrote: > On 4/4/16 3:14 AM, Jeremy Harris wrote: >> On 01/04/16 23:18, Viktor Dukhovni wrote: >>> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: I feel very strongly that policy for SMTP relay should be advertised by SMTP and protected by SMTP

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

On 4/4/16 3:14 AM, Jeremy Harris wrote: > On 01/04/16 23:18, Viktor Dukhovni wrote: >> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: >>> I feel very strongly that policy for SMTP relay should be advertised by >>> SMTP and protected by SMTP TLS. >> Unfortunately, in MTA-to-MTA SMTP,

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

On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote: > I feel very strongly that policy for SMTP relay should be advertised by > SMTP and protected by SMTP TLS. Doing anything else creates a much larger > attack surface on the policy information and is both more complex and less >

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

I’m unconvinced by these two design reasoning documents. They start with the assumption that signed routing information, security policy and reporting should be conflated. I consider those separate functions. The only relationship between signed routing and security policy is that security

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

On March 25, 2016 at 15:15:22 , Mark Risher (ris...@google.com) wrote: The discussion around whether to include a timeout in DEEP was basically to ask the question: Should a domain that makes a commitment to be secure be allowed to revoke that commitment? The rough consensus in the face-to-face

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

On March 24, 2016 at 2:16:27 , Mark Risher (ris...@google.com) wrote: Hi, Chris: Thanks for the comments.   1. I personally dislike using DNS records for any of this proposal. I believe SMTP security policy is best communicated within SMTP as this minimizes attack surface, eliminates the need

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

On March 23, 2016 at 18:45:45 , Daniel Margolis (dmargo...@google.com) wrote: Hey,  Of course we reviewed DEEP during the drafting process, but as you say, the targets are slightly different. I've responded to some individual points inline; in summary, though, I think you raise some actionable

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

Hi, Chris: Thanks for the comments. > 1. I personally dislike using DNS records for any of this proposal. I > believe SMTP security policy is best communicated within SMTP as this > minimizes attack surface, eliminates the need for TOFU in some scenarios, > and puts the policy configuration

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

This document is providing STS functionality for SMTP relay, while DEEP is providing STS functionality for SMTP submission (plus IMAP & POP). I believe it’s important to align these two proposals and am open to changing DEEP to do so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).

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

Hi Viktor, On 22/03/2016 16:09, Viktor Dukhovni wrote: On Tue, Mar 22, 2016 at 11:10:57AM +0100, Daniel Margolis wrote: Thanks for the feedback to both of you. I don't disagree; I think Viktor makes a very solid point in favor of simplicity. In addition, a report-only protocol could be

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

> On 22 Mar 2016, at 08:49, Viktor Dukhovni wrote: > > On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote: > > My (strong) suggestion: use DNS for just cache invalidation, and > perhaps also publication (via a separate record) of the "rua" > reporting URI.

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

On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote: > > A significant obstacle to a successful roll-out of WebPKI with > > SMTP is not [so] much that obtaining and deploying CA certs is > > onerous (enabling DNSSEC is likely more difficult at present), > > but rather

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

On Sat, Mar 19, 2016 at 11:20:23AM +0100, Mark Risher wrote: > The initial draft is at > https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/ and we hope to > discuss this at the Buenos Aires meeting next month. While we have deployed > a prototype/reference implementation among the authors,