Re: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-03.txt

2014-09-22 Thread Viktor Dukhovni
On Sun, Sep 21, 2014 at 11:15:20PM +0300, Yaron Sheffer wrote: o Host name validation is sometimes irrelevant. While it is true that insecurely obtained hostnames are not suitable reference identifiers for peer authentication, it is perhaps not enough to suggest that the hostname should

Re: [Uta] comments: draft-ietf-uta-tls-bcp-04

2014-10-03 Thread Viktor Dukhovni
On Thu, Oct 02, 2014 at 05:20:56PM -0400, Sean Turner wrote: The deployment recommendations address the operators of application layer services that are most commonly used on the Internet, including but not limited to: o Operators of email servers who wish to protect the

Re: [Uta] Opportunistic TLS and draft-ietf-uta-tls-bcp-04

2014-10-09 Thread Viktor Dukhovni
On Thu, Oct 09, 2014 at 09:58:59AM +0100, t.p. wrote: Well, that is what you have in your I-D, that is what you are proposing. The question I raise is whether or not that definition of opportunistic TLS is the one that UTA wants to use I thought we weren't going to debate those definitions

Re: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-05.txt

2014-10-14 Thread Viktor Dukhovni
On Tue, Oct 14, 2014 at 01:56:52PM +0200, Aaron Zauner wrote: 3. SSL Protocol version recommendations. Once again with unauthenticated opportunistic TLS even SSL 3.0 or TLS 1.0 is (much) better than cleartext. So the MUST NOT SSL 3.0 and SHOULD NOT TLS 1.0 are too strong. So once

Re: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-05.txt

2014-10-14 Thread Viktor Dukhovni
On Tue, Oct 14, 2014 at 08:04:01PM +0200, Aaron Zauner wrote: I'm willing to accept MUST NOT for mandatory (non-opportunistic) TLS. However, claiming that SSL 3.0 is worse than cleartext is simply absurd. Perhaps the BCP should not apply to opportunistic uses of TLS, and those should be

Re: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-05.txt

2014-10-14 Thread Viktor Dukhovni
On Tue, Oct 14, 2014 at 05:59:13PM +0300, Yaron Sheffer wrote: Thanks for your comments! I agree we SHOULD tone down a few of the requirements, to make sure we do accommodate the opportunistic use case. Thanks. OTOH I agree with Aaron on (for example) still forbidding export-level

[Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp-05.txt

2014-10-14 Thread Viktor Dukhovni
* Section 2.1 first bullet below first paragraph: With unauthenticated opportunistic TLS this is not attainable. Confidentiality: all (payload) communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver. Confidentially

Re: [Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp-05.txt

2014-10-15 Thread Viktor Dukhovni
On Wed, Oct 15, 2014 at 08:21:07PM +, Orit Levin (LCA) wrote: Victor, some of your text is not directly related to the opportunistic recommendations. So, if you feel that it will be useful to include these parts or modifications into the BCP, please, submit them in a format suggesting how

Re: [Uta] POODLE

2014-10-16 Thread Viktor Dukhovni
On Thu, Oct 16, 2014 at 03:13:10AM +, Peter Gutmann wrote: I'm currently travelling and have only had time for a quick look at the Poodle doc, but it seems to require a combination of things, a client that automatically falls back to SSLv3, that runs Javascript and performs actions on

Re: [Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp-05.txt

2014-10-17 Thread Viktor Dukhovni
On Thu, Oct 16, 2014 at 07:53:37PM -0600, Peter Saint-Andre - yet wrote: It seems to me that, by definition, the future cannot be helpfully discussed in a Best *Current* Practice document. The most we can do is point to some possible directions of future trends that might have an impact on the

Re: [Uta] Richard Barnes' No Objection on draft-ietf-uta-tls-attacks-04: (with COMMENT)

2014-10-19 Thread Viktor Dukhovni
On Sun, Oct 19, 2014 at 06:48:40PM +0300, Yaron Sheffer wrote: in newer versions of the protocol, but if the client and server can't negotiate that version, it's all for naught.

Re: [Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp-05.txt

2014-10-21 Thread Viktor Dukhovni
On Tue, Oct 21, 2014 at 07:56:35PM -0600, Peter Saint-Andre - yet wrote: The initial UTA BCP was supposed to be a quick win for authenticated encryption with TLS. All this discussion of OE/UE is distracting us from that goal. It was only mentioned because the document asserted SMTP and XMPP

Re: [Uta] Feedback on draft-ietf-uta-tls-bcp-07 (Forwarding on behalf of Joe. St. Sauver...)

2014-11-18 Thread Viktor Dukhovni
On Mon, Nov 17, 2014 at 09:12:20PM +, Stephen Farrell wrote: 4.2.1 states that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SHOULD be the first cipher proposed, and servers SHOULD prefer that cipher whenever is proposed. I'd prefer to see the AES_256 version recommended instead, given

Re: [Uta] AES-128 vs. AES-256

2014-11-20 Thread Viktor Dukhovni
On Wed, Nov 19, 2014 at 11:37:39PM +0100, Aaron Zauner wrote: Yup, I meant the post-quantum stuff w.r.t. asking CFRG. I'm subscribed there, and some people working on exactly that topic are as well. But to be honest I don't see a pressing reason to do so right now. You'll likely get a simple

Re: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

2015-02-19 Thread Viktor Dukhovni
On Thu, Feb 19, 2015 at 09:35:50AM -0500, Richard Barnes wrote: Part of the source of my confusion here is that from the pure perspective of TLS, the server is *always* authenticated (and the client, Factually incorrect. Anon-DH has been present in TLS since the beginning. If your

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

2015-03-22 Thread Viktor Dukhovni
On Sun, Mar 22, 2015 at 08:34:56PM +, Alexey Melnikov wrote: Should use of _submission SRVNAMES be inferred from the target port? No. OK. Or enabled via per-destination configuration? I think direct host configuration must disable SRV lookups and checking for

Re: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

2015-03-22 Thread Viktor Dukhovni
On Mon, Mar 23, 2015 at 02:22:28AM +, Alexey Melnikov wrote: Another alternative is to allow for uniformResourceIdentifier for the purpose you describe (they are currently prohibited by the draft, but only because they are not used). I think I would avoid URI, too much unnecessary

Re: [Uta] draft-ietf-uta-email-deep-00 comments

2015-02-25 Thread Viktor Dukhovni
On Wed, Feb 25, 2015 at 07:25:56PM +, Jeremy Harris wrote: 7.3 At what stage of an SMTP conversation is CLIENT valid? Are multiple uses per SMTP connection (EHLO to QUIT) valid? Good point. Presumably (when used on either port 587 or port 25 with STARTTLS) the sequence is: S:

Re: [Uta] WGLC draft-ietf-uta-email-tls-certs

2015-04-16 Thread Viktor Dukhovni
On Wed, Apr 15, 2015 at 10:23:32AM -0700, Rick Andrews wrote: The the CA's job, the certificate would be obtained by the customer and provisioned by the customer via a customer admin portal. I think what's being asked is how would the CA do the verification before issuing the cert? All

Re: [Uta] WGLC draft-ietf-uta-email-tls-certs

2015-04-12 Thread Viktor Dukhovni
On Sat, Apr 11, 2015 at 01:08:59PM -1000, Brian Smith wrote: Viktor Dukhovni ietf-d...@dukhovni.org wrote: Brian Smith wrote: That said, maybe I'm not understanding the importance of SRV-ID. Clarification of why supporting SRV-ID is important would be useful. My understanding

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

2015-07-31 Thread Viktor Dukhovni
On Fri, Jul 31, 2015 at 06:49:59PM -0400, Keith Moore wrote: They'd also need new SMTP software to support AQRY. That software would need to be well maintained too. I trust the DNSSEC validation code in unbound and BIND more than I would trust the same to some application library. The

Re: [Uta] E-Mail Protocol Security Measurements

2015-07-29 Thread Viktor Dukhovni
On Tue, Jul 28, 2015 at 01:39:40AM +0200, Aaron Zauner wrote: * RC2-CBC-MD5 is supported by 40% of SMTP servers we've studied, This looks implausible, I've not seen it once in SMTP connection logs. Slide 8 even mentions this preferred by ~25% of servers. Preferred to what? This

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

2015-08-01 Thread Viktor Dukhovni
On Sat, Aug 01, 2015 at 01:31:02AM -0400, Keith Moore wrote: It's pointless to continue arguing about this. Yes, we're done. Contact me off-list to arrange a time to chat when you're ready. The below are just clarifications, not a counter-argument. I did not mention anything about resource

Re: [Uta] it's not end-to-end *versus* hop-by-hop for email (was: Re: E-Mail Protocol Security Measurements)

2015-08-02 Thread Viktor Dukhovni
On Sun, Aug 02, 2015 at 07:48:24PM +0100, Stephen Farrell wrote: We should make arguments for use of TLS in mail. Deploying that provides real security and privacy benefits. And there are real improvements happening today in terms of deploying TLS in mail. I say encourage that as much as

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

2015-07-31 Thread Viktor Dukhovni
On Thu, Jul 30, 2015 at 04:02:58PM -0400, Keith Moore wrote: And finally, the idea that a DNS client could simply trust its local resolver to do DNSSEC validation for it never made any sense at all. Perhaps you're using the phrase local resolver in some novel way that I don't understand. Why

Re: [Uta] E-Mail Protocol Security Measurements

2015-07-30 Thread Viktor Dukhovni
On Thu, Jul 30, 2015 at 04:10:56PM -0400, Michael Richardson wrote: Michael Richardson wrote: RC4 is supported by 83% of end points that support crypto, or of 83% of end points that answer TCP? This percentage is based on hosts that did complete a SSL/TLS

Re: [Uta] E-Mail Protocol Security Measurements

2015-07-30 Thread Viktor Dukhovni
On Thu, Jul 30, 2015 at 09:09:17PM +0200, Aaron Zauner wrote: We'll take a look into that in the future! I have a reasonable dataset of IPs (from January), but not the bandwidth (or software on hand) to repeat the scan. There's two options which we can work out rather quickly to

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

2015-07-31 Thread Viktor Dukhovni
On Fri, Jul 31, 2015 at 02:23:25PM -0400, Keith Moore wrote: Perhaps you're using the phrase local resolver in some novel way that I don't understand. Why shouldn't an application trust responses from 127.0.0.1:53? The vast majority of hosts don't operate a resolver, and even if they do,

Re: [Uta] E-Mail Protocol Security Measurements

2015-07-30 Thread Viktor Dukhovni
On Thu, Jul 30, 2015 at 06:16:53PM +0200, Aaron Zauner wrote: Still I think it's an interesting study, I don't know of anybody doing a similar one previously (as in: enumerating TLS for the whole IPv4 space. Back in January 2015 I got some data conducted by a contact in Germany who had access

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

2015-07-30 Thread Viktor Dukhovni
On Thu, Jul 30, 2015 at 11:34:43AM -0400, Keith Moore wrote: The secret swept under the rug is that there is no security at all in the provisioning process for DV certificates. Ok, I agree with you there. A DNSSEC signature is not less reliable than a DV certificate. Thanks. I see

Re: [Uta] E-Mail Protocol Security Measurements

2015-07-27 Thread Viktor Dukhovni
On Mon, Jul 27, 2015 at 03:17:52PM +0200, Aaron Zauner wrote: https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf * RC4 support is at about 83-85% * unsurprisingly TLS 1.0 is most widely supported * ~60% of certificates are self-signed * a huge number of servers offer AUTH

Re: [Uta] E-Mail Protocol Security Measurements

2015-10-30 Thread Viktor Dukhovni
On Fri, Oct 30, 2015 at 12:00:30PM +0100, Aaron Zauner wrote: > Starting up this thread again; our paper has been published today > open-access and our data-sets are currently in the process of being > published on scans.io. > > The paper is available at http://arxiv.org/abs/1510.08646 > > In

Re: [Uta] E-Mail Protocol Security Measurements

2015-10-31 Thread Viktor Dukhovni
On Sat, Oct 31, 2015 at 07:15:51AM -0400, Watson Ladd wrote: > > STARTTLS is designed to thwart exactly one attack: *passive* wiretap. > > It works as designed for just that attack. It is not surprising > > that active attacks can and do defeat STARTTLS, > > Before STARTTLS adoption the

Re: [Uta] E-Mail Protocol Security Measurements

2015-10-31 Thread Viktor Dukhovni
On Sat, Oct 31, 2015 at 06:28:16AM +0100, Aaron Zauner wrote: > That article is referencing another paper, presented at IMC15 by > UMichigan, UCI and Google researchers, publicly available over here: > http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf > > ..there're also problems with some

Re: [Uta] Dealing with STARTTLS Stripping

2015-12-05 Thread Viktor Dukhovni
> On Dec 5, 2015, at 5:14 PM, Aaron Zauner wrote: > >>> And I also think I've broken your proposal in this GitHub issue: >>> https://github.com/mrisher/smtp-sts/issues/1 >> >> No. Neither DEEP nor TACK can protect MTA-to-MTA SMTP. The reason >> is MX indirection. DEEP and

Re: [Uta] Dealing with STARTTLS Stripping

2015-12-05 Thread Viktor Dukhovni
On Fri, Dec 04, 2015 at 11:56:21PM +0100, Aaron Zauner wrote: > > Aaron, > > > > There's a group of folks from M3AAWG that are working toward a sort of > > mechanism for SMTP, roughly using some ideas relating to HSTS and/or > > certificate transparency. The idea being that you would specify a

Re: [Uta] Dealing with STARTTLS Stripping

2015-12-05 Thread Viktor Dukhovni
On Sun, Dec 06, 2015 at 04:24:53AM +0100, Aaron Zauner wrote: > > MTA-to-MTA SMTP (relay) establishes connections to wherever the MX records > > point. The MX records are in DNS. Therefore, if active attacks are in > > scope, and DNS is not protected from active attack, you cannot protect > >

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

2015-12-01 Thread Viktor Dukhovni
On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote: > If I understand this draft correctly, I object. > > It says: > > >2. When using email service discovery procedure specified in >[RFC6186] the client MUST also use the right hand side of the >email address

Re: [Uta] Last Call: (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

2015-11-23 Thread Viktor Dukhovni
On Sat, Nov 21, 2015 at 02:41:29PM +, Alexey Melnikov wrote: > > (1) In Introduction says: > > > >Note that this document doesn't apply to use of TLS in MTA-to-MTA > >SMTP. > > > > Can this be enhanced to include a pointer to where this can be found? > > Currently this is

Re: [Uta] Last Call: (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

2015-11-23 Thread Viktor Dukhovni
On Fri, Nov 20, 2015 at 04:36:41PM -0500, Russ Housley wrote: > I support this document going forward. Below I suggest four improvements to > the document. I also have some suggested improvements: Section 2: reference identifier: (as defined in [RFC6125]) One of the domain names

Re: [Uta] CAA DNS RRs (RFC6844), DNSSEC and MTA-STS

2016-06-17 Thread Viktor Dukhovni
On Sat, Jun 18, 2016 at 01:53:20PM +0800, Aaron Zauner wrote: > RFC6844 defines a method by which domain owners can limit the CA allowed > to issue certificates for their domain. Critically, this signalling channel is *exclusively* between the domain and any CA that might consider issuing a

Re: [Uta] CAA DNS RRs (RFC6844), DNSSEC and MTA-STS

2016-06-18 Thread Viktor Dukhovni
> On Jun 18, 2016, at 4:40 PM, Aaron Zauner wrote: > > That being said; an option to pin to the public key of a certain intermediate > CA is far more useful, with the caveat of roll-over and broken/bouncing mail > transfer. You're starting to invent DANE. There are now 1181

Re: [Uta] CAA DNS RRs (RFC6844), DNSSEC and MTA-STS

2016-06-18 Thread Viktor Dukhovni
On Sat, Jun 18, 2016 at 06:15:33PM +0800, Aaron Zauner wrote: > > You're starting to invent DANE. There are now 1181 DANE SMTP domains > > with LE certificates in my survey... > > I meant with MTA-STS. They do have public key pinning as a future work item > already? Key pinning is most

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

2016-03-28 Thread Viktor Dukhovni
On Sun, Mar 27, 2016 at 08:17:28PM -0700, Jim Fenton wrote: > >> I have received suggestions that there also be options to require > >> specific TLS version, cipher suites, PFS, etc. as well, and my gut feel > >> is that's getting too specific. > > > Don't let this be over-engineered. That's a

Re: [Uta] Recording from irtfopen on email security using TLS

2016-04-07 Thread Viktor Dukhovni
On Wed, Apr 06, 2016 at 11:13:17PM +, Orit Levin (CELA) wrote: > 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

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] "webby" STS and DANE/DNSSEC co-existence

2016-04-12 Thread Viktor Dukhovni
On Tue, Apr 12, 2016 at 06:52:31PM +0200, Daniel Margolis wrote: > I'm not sure if I'm being stupid here, but what does it mean for STS to be > "trumped" by DANE (or the reverse)? Do you mean that if the recipient > domain/MX has both STS and DANE you will *only* validate the DANE policy?

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

2016-04-10 Thread Viktor Dukhovni
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

2016-04-11 Thread Viktor Dukhovni
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] "webby" STS and DANE/DNSSEC co-existence

2016-04-11 Thread Viktor Dukhovni
On Mon, Apr 11, 2016 at 09:45:06PM +0100, Stephen Farrell wrote: > With no hats, I'd like to argue that the WG should pursue > the "webby" STS proposal, but should also ensure that we > do not damage progress made by those who are deploying the > DANE/DNSSEC approach to securing MTA-MTA

Re: [Uta] I-D Action: draft-ietf-uta-email-deep-04.txt

2016-03-19 Thread Viktor Dukhovni
On Thu, Mar 17, 2016 at 04:01:22PM -0700, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Using TLS in Applications of the IETF. > > Title : Deployable Enhanced Email Privacy

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

2016-03-22 Thread Viktor Dukhovni
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,

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

2016-03-22 Thread Viktor Dukhovni
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] Uta Digest, Vol 28, Issue 16

2016-03-24 Thread Viktor Dukhovni
> On Mar 24, 2016, at 12:16 PM, uta-requ...@ietf.org wrote: > > In addition to the possible difficulty in migrating a domain off > a server (particularly in a multi-tenant config), we also felt > that introducing a new SMTP verb might be dramatically more complicated > than deploying in

Re: [Uta] Uta Digest, Vol 28, Issue 16

2016-03-24 Thread Viktor Dukhovni
On Thu, Mar 24, 2016 at 06:06:25PM +0100, Daniel Margolis wrote: > I think your thought exercise has brought you to the same place I arrived > at. ;) > > Note in particular, regarding domains "too big to do DANE", that this seems > likely to be especially true for big hosting providers. [ As an

Re: [Uta] REQUIRETLS: another SMTP TLS mechanism

2016-03-25 Thread Viktor Dukhovni
On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote: > > If the entire goal is to ensure the integrity of the RFC 6125 > > "reference identifier" used to authenticate the nexthop SMTP > > server, then it is perhaps a good idea to say so explicitly. > > The primary purpose was

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

2016-04-01 Thread Viktor Dukhovni
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

2016-04-04 Thread Viktor Dukhovni
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] "webby" STS and DANE/DNSSEC co-existence

2016-04-14 Thread Viktor Dukhovni
On Wed, Apr 13, 2016 at 10:43:31AM -0700, Chris Newman wrote: > DANE is merely one method of validating a certificate, there can also be > SMTP policy orthogonal to DANE. Sure, but I don't see DEEP-style policy latches playing much of a role, if any, in MTA-to-MTA opportunistic transport

Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

2016-04-14 Thread Viktor Dukhovni
On Wed, Apr 13, 2016 at 08:58:58PM +, Binu Ramakrishnan wrote: > > STS is WebPKI. If you want STS, you need a certificate from one > > of the usual CAs.  With a self-signed certificate (some day just > > a bare public key and no certificate at all) you can only use DANE.>-- > > Yes, the STS

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

2016-04-30 Thread Viktor Dukhovni
On Sat, Apr 30, 2016 at 07:37:13PM -, John Levine wrote: > 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. > I have two

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

2016-04-30 Thread Viktor Dukhovni
On Sat, Apr 30, 2016 at 10:29:30PM -, John Levine wrote: > >> 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. >

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

2016-05-09 Thread Viktor Dukhovni
On Mon, May 09, 2016 at 05:59:09PM -, John Levine wrote: > >Definitely not mutually exclusive. The case I'm trying to make is > >that the initial operational priority is timely notification of > >misconfiguration (expired, untrusted or wrong name certs). > > I'd really like to hear from

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

2016-05-09 Thread Viktor Dukhovni
On Mon, May 09, 2016 at 10:44:11PM -, John Levine wrote: > 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

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

2016-05-10 Thread Viktor Dukhovni
On Tue, May 10, 2016 at 12:56:54PM -0700, Daniel Margolis wrote: > Agreed; makes sense to me. I'm not sure if it makes sense to extend the > DEEP-specific reporting to cover this case; it may be easier to just draft > a short separate spec on this. What do you think? Yes, I think the alignment

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

2016-05-10 Thread Viktor Dukhovni
On Wed, May 11, 2016 at 04:55:43AM +0700, Aaron Zauner wrote: > DNSSEC non-existent. I do have some counter-examples to that claim, that have not only DNSSEC, but also DANE TLSA records for inbound SMTP: gmx.at registro.br gmx.ch gmx.com mail.com bund.de gmx.de

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

2016-05-10 Thread Viktor Dukhovni
> On May 10, 2016, at 11:14 PM, Aaron Zauner wrote: > > Do you have percentages which of these aren't either: > > a) a open-source project where there's large community demand (for some > reason) The open-source projects are a very tiny subset of the overall list, they are a

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

2016-05-10 Thread Viktor Dukhovni
> On May 10, 2016, at 11:22 PM, Aaron Zauner wrote: > >> Yes, it is true that both DNSSEC and IPv6 still have some catching >> up to do with vanilla DNS and IPv4, respectively. A sample of >> DNSSEC adoption for a few TLDs: >> >> TLDDNSSEC >> --

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

2016-05-12 Thread Viktor Dukhovni
On Thu, May 12, 2016 at 11:26:49AM -0700, Jim Fenton wrote: > 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

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

2016-05-12 Thread Viktor Dukhovni
On Thu, May 12, 2016 at 04:41:43PM -0400, John R Levine wrote: > >True, but admins usually at least know where their stuff is (hosted), don't > >they? > > You would hope so, but in sufficiently large organizations, sometimes not. > It's off in the cloud, somewhere. And in many small

[Uta] Unexpected notification channel

2016-05-16 Thread Viktor Dukhovni
On Sun, May 15, 2016 at 05:50:23PM -0400, Viktor Dukhovni wrote: > Similarly, the nameservers of patriotguard.org are misguidedly configured to > drop TLSA queries as a security^Wignorance feature in a firewall to > protect^Wbreak the nameservers. This too resembles an MiTM attack:

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

2016-05-13 Thread Viktor Dukhovni
On Sat, May 14, 2016 at 03:44:53AM +0300, Vladimir Dubrovin wrote: > > > There are situations where this is practically impossible, e.g. wildcard > > > domains. For example, I want MX to accept mail for *.example.com and > > > support STS. Having policy.mta-sts.*.example.com can be problematic

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

2016-05-13 Thread Viktor Dukhovni
On Sat, May 14, 2016 at 02:37:56AM +0300, Vladimir Dubrovin wrote: > 1. Current draft does not allow to control STS policy for subdomains. It > means every subdomain which can be used as a recipient's domain must > have it's own policy.mta-sts A-record and _mta_sts TXT record. And this is

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

2016-05-10 Thread Viktor Dukhovni
> On May 11, 2016, at 1:02 AM, Aaron Zauner wrote: > >> With only one MTA open-source supporting DANE at present, and only with >> relatively recent releases, and OpenSSL 1.1.0 still (for a couple more >> weeks) in beta, it is not surprising that deployment is still light. >> We

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

2016-05-02 Thread Viktor Dukhovni
> On May 2, 2016, at 9:06 PM, John Levine wrote: > > 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 chain against

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

2016-05-03 Thread Viktor Dukhovni
On Tue, May 03, 2016 at 11:57:40PM +0200, Daniel Margolis wrote: > > By "TXT" resolution do you mean publishing the target URI in the > > DNS TXT record? If so, I thought that idea was abandoned. > > > It was, but only because we had been thinking we would just use a > hard-coded hostname

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

2016-05-03 Thread Viktor Dukhovni
On Wed, May 04, 2016 at 01:38:22AM +0200, Daniel Margolis wrote: > Yeah, I agree on the two points. But is it safe for us to assume that > "smtp-sts-policy" is not an untrusted host? This was our concern, given > examples like dyndns.org or tumblr.com. Of course, an attacker also has to > do DNS

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

2016-05-06 Thread Viktor Dukhovni
On Fri, May 06, 2016 at 11:01:00PM -, John Levine wrote: > >That's not a fair objection, they would have to deploy upgraded > >MTAs that support the new extension, just as would deploy MTAs that > >support DANE or STS to enjoy the benefits of those (yes at present > >upgrades are only needed

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

2016-05-02 Thread Viktor Dukhovni
On Mon, May 02, 2016 at 07:06:42AM +0200, Daniel Margolis wrote: > > > My impression from the converstation in B.A. was that it'd be > > > a big problem. > > Probably the most likely answer is that it would be easier than deploying > DNSSEC and harder than deploying at a custom host. For us it's

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

2016-05-01 Thread Viktor Dukhovni
On Sun, May 01, 2016 at 09:40:30PM +0200, Daniel Margolis wrote: > > If the two names in the cert aren't in the same tree, how will you > > get a CA to sign it? For example, I have a customer philiphazan.com > > whose mail is at Tucows' hostedemail.com. Who's going to get the > > cert, me or

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

2016-05-06 Thread Viktor Dukhovni
On Fri, May 06, 2016 at 12:57:15PM +0700, Aaron Zauner wrote: > > You need to keep in mind that in the vast majority of cases > > authentication errors will be operational errors (self-DoS) on > > receiving systems, and the task at hand is to minimize the frequency > > and duration of outages, so

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

2016-05-05 Thread Viktor Dukhovni
On Fri, May 06, 2016 at 10:39:57AM +0700, Aaron Zauner wrote: > > The MITM attacker already knows he was attempting to intercept the > > traffic. > > The MITM does, the receiving party may not. You need to keep in mind that in the vast majority of cases authentication errors will be operational

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

2016-05-05 Thread Viktor Dukhovni
On Fri, May 06, 2016 at 10:55:02AM +0700, Aaron Zauner wrote: > > On 06 May 2016, at 10:49, Aaron Zauner <a...@azet.org> wrote: > > > >> On 06 May 2016, at 02:40, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > >> > >> The most

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

2016-05-06 Thread Viktor Dukhovni
On Fri, May 06, 2016 at 02:14:37PM +0700, Aaron Zauner wrote: > > The current form is not the final form. To the expect that the > > draft emphasizes statistical reporting over problem alerting it > > needs to be corrected. > > I'm aware of that, but if the draft turns out to be a delivery

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

2016-05-09 Thread Viktor Dukhovni
On Tue, May 10, 2016 at 01:15:34AM -, John Levine wrote: > >Legacy MTAs also won't have STS support. We won't get new security > >capabilitie ex nihilo. > > If you want to do the client stuff, you need new code in the MTA, but > for the server side part, publishing a statement saying here's

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

2016-05-10 Thread Viktor Dukhovni
On Tue, May 10, 2016 at 10:07:06AM -0700, Chris Newman wrote: > > I'm not suggesting that out-of-band reporting should not also be > > specified. Let's also specify in-band reporting. > > The MUA STS (aka DEEP) specification already has in-band reporting for > SMTP Submission. We could

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

2016-05-06 Thread Viktor Dukhovni
On Sat, May 07, 2016 at 01:08:44AM -, John Levine wrote: > > It is the long tail of much smaller domains where SMTP transport security > > needs > > an effective alerting channel. > > So they can point the reports at some place like dmarcian.com, which > does the analysis for small mail

Re: [Uta] Implementing STS

2016-04-14 Thread Viktor Dukhovni
On Thu, Apr 14, 2016 at 09:20:01AM -0500, Arvel Hathcock wrote: > ... one way to handle it (as I think was mentioned before) is by deferring > back to queue any delivery attempt which finds a previously unknown STS > policy record until such time (not long) as a separate thread safely > dedicated

Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

2016-04-17 Thread Viktor Dukhovni
On Sun, Apr 17, 2016 at 08:45:06PM -0700, Jim Fenton wrote: > I'm a little confused by the language in section 9.1 "All [client and > server] implementations MUST be configurable to support implicit TLS > using the TLS 1.2 protocol or later." So why not insist in TLS 1.2 all > the time? There

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

2016-08-11 Thread Viktor Dukhovni
On Thu, Aug 11, 2016 at 05:59:08PM +0200, Daniel Margolis wrote: > > Should this still apply when the names are DNSSEC validated? Or > > should clients that obtain DNSSEC "secure" MX RRsets (or denial > > of existence) skip the MX constraints in the STS policy, whose > > primary purpose is to

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

2016-08-11 Thread Viktor Dukhovni
On Thu, Aug 11, 2016 at 09:37:47PM +0200, Daniel Margolis wrote: > Another option (also, IMO, simpler than multiple versions) is to simply not > indicate the ID string in the JSON at all, but only in the TXT. It's not > clear to me why it has to be in the JSON anyway (but I haven't thought this >

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

2016-08-11 Thread Viktor Dukhovni
> On Aug 11, 2016, at 8:54 PM, Mark Risher wrote: > > This sounds interesting. So in this model, would we eschew the "max-age" in > the policy itself and rely solely on updates to the DNS? This seems like the > best leverage of the existing DNS caching capabilities, the

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

2016-08-11 Thread Viktor Dukhovni
On Thu, Aug 11, 2016 at 08:19:06PM +, Binu Ramakrishnan wrote: > We appreciate your time and effort reviewing our draft.Lately we had some > discussions related to policy cache and refresh in GitHub. One proposal > was not to depend on DNS beyond initial discovery. We have some flow >

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

2016-08-11 Thread Viktor Dukhovni
On Fri, Aug 12, 2016 at 12:02:18AM +, Binu Ramakrishnan wrote: > > Keep in mind that polling for fresh policy (synchronous or not) > > will only happen as part of a mail delivery to the destination > > domain.  A quick DNS lookup as part of each delivery works just > > fine.  It is far from

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

2016-08-09 Thread Viktor Dukhovni
My review below. Executive summary, at least a -02 (and likely then an -03) is needed to correct many issues before this is ready for WGLC. > 1. Introduction > > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to > establish secure SMTP sessions over TLS. In its

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

2016-08-09 Thread Viktor Dukhovni
> On Aug 9, 2016, at 3:08 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > >> >> The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to >> establish secure SMTP sessions over TLS. In its current form, however, it >> fails to

Re: [Uta] Updated drafts for MTA-STS & TLSRPT

2017-02-23 Thread Viktor Dukhovni
> On Feb 23, 2017, at 3:35 PM, Daniel Margolis wrote: > >> 2. It prevents new MX records (eg new servers for increased capacity or >> backups) not covered by the cached policy from being used until the max_age, >> or until a failure to send with all the covered servers.

Re: [Uta] Updated drafts for MTA-STS & TLSRPT

2017-02-23 Thread Viktor Dukhovni
> On Feb 23, 2017, at 3:35 PM, Daniel Margolis wrote: > >> Having pondered it a bit, my suggestion is: >> 1. A SHOULD that max_age is set to at least 6 months, other than during >> roll-out >> 2. A SHOULD that well-behaved clients with a cached policy should re-check >>

Re: [Uta] Updated drafts for MTA-STS & TLSRPT

2017-02-23 Thread Viktor Dukhovni
> On Feb 23, 2017, at 4:04 PM, Daniel Margolis wrote: > >> This applies whether or not the change is to the list of acceptable "mx" >> hosts, or to some other property. > > Yes, but my point was that we don't (to my recollection) actually require > senders to check for

Re: [Uta] Updated drafts for MTA-STS & TLSRPT

2017-02-24 Thread Viktor Dukhovni
> On Feb 24, 2017, at 3:33 PM, David Illsley wrote: > > I think I agree with where you've got to, but I do want to clarify > that I think it's important that a shorter refresh period doesn't > shorten the policy expiry - we want a 6 month policy to be cached > and relied

  1   2   3   4   >