Heh, thanks for the feedback.
I will try to make sure we used consistent language. In specifics, my
intended meanings:
* authentication: determining that the policy is published by the domain
owner (either because it was delivered over DNSSEC or because it was
delivered over HTTPS with a trusted
explicitly state it, I presume reports can be
> sent even when “to” is set to “true”? If so the draft should be explicit
> about this. If not, why not?
>
> Neil
>
> On 22 Mar 2016, at 11:24, Daniel Margolis wrote:
>
> Heh, thanks for the feedback.
>
> I will try
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?
If we instead said that senders who validate STS must honor STS and senders
who
On Mon, May 2, 2016 at 12:55 AM, Viktor Dukhovni
wrote:
>
> > On May 1, 2016, at 5:00 PM, John Levine wrote:
> >
> >> 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 wor
On Thu, May 5, 2016 at 6:40 PM, John R Levine wrote:
> Random CNAMEs and SNI play poorly together. Might as well just use the
> TXT record to point people at the real name of the server.
>
Heh. But in this case we don't really need HTTPS (or any validation), since
the SMTP reports can be sent w
On Sat, May 14, 2016 at 11:02 AM, Vladimir Dubrovin
wrote:
> 1. Alice makes certificate request for mx1.example.org to any public CA
> choosing hostmas...@mx1.example.org as a validation address
> Because Bob does not expect any mail to be received for
> @mx1.example.org, he has no separate STS p
Trimmed to a few parts I have immediate comment/questions on:
On Tue, Aug 9, 2016 at 9:08 PM, Viktor Dukhovni
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 th
On Fri, Aug 12, 2016 at 5:24 PM, Viktor Dukhovni
wrote:
> Delivery disruption that's due to stale policy is IMHO far less
> likely to be the cause of problems, and so doing synchronous HTTPS
> refresh and retry is I think too much complexity and latency for
> too little gain. I'd like to see tha
On Wed, Sep 7, 2016 at 4:57 PM, Viktor Dukhovni
wrote:
> If 404 is a soft fail, and maxage=0 is revocation, what should a sending
> MTA
> do when it encounters a 404 (or indeed an HTTPS connection timeout,
> handshake
> failure, ...)? Retry the HTTPS policy lookup on every delivery? Employ
> so
Fair point on the pseudocode. My point wasn't so much that it's not useful
as that it's hard and I have to carve out some time to sit down and try to
do a better job of it. ;)
Regarding 3.2, I think you're misinterpreting (due to, as I think Stephen
pointed out, a misuse of the "MAY" terminology a
On Sat, Dec 17, 2016 at 12:04 AM, Alberto Bertogli wrote:
> But using HTTPS only has the same polling frequency. The MTA doesn't
> need to trigger the probe any more often than with the current proposal.
>
I think you're basically right about polling frequency, but I believe there
are two other
Thanks for the comments! Comments inline.
On Mon, Feb 20, 2017 at 9:16 PM, David Illsley
wrote:
> In general, the fact the a complete failure causes a policy update makes
> this simple and safe. There are a couple of reasons why I think it's not
> quite that easy:
> 1. It's not desirable for a '
Ugh, you're right. Seems like I screwed up the merge or something. I can't
remember what I was doing.
Anyway, since we have to submit another draft for the whole CNAME issue I
guess no harm done. :-/
If only we had some sort of code review process to review code. What an
idea.
Thanks for the clo
I'm also not convinced that it is harder to block the HTTPS request, since
the hostname there is not the nexthop domain but is itself a special
hostname ("mta-sts"). Given that, an attacker who can block the TXT can
just block the CNAME/A/ record for "mta-sts".
You'd have to get rid of that an
2017 at 9:32 PM, wrote:
> > On Tue, Apr 04, 2017 at 04:20:59PM +0200, Daniel Margolis wrote:
>
> > > Can you explain a little more what you mean? The mitigation is to
> publish a
> > > new policy with the correct values, so certainly anyone who does so
> > >
Thanks. Comments inline, mostly ticking off changes. :)
I have pushed all my changes in response to this to the git repo and they
should appear in our next draft.
On Wed, Apr 19, 2017 at 1:05 PM, Alexey Melnikov
wrote:
> Hi,
> Below is my early "AD review" of the document. I think it is in pre
Hi, Viktor,
Thanks for the thorough writeup. A question about the "requirements" stated:
1. We need to provide a means for a domain to transition
> from having an STS policy to not having an STS policy.
> 2. The transition process should not look like failure to
> obtain the policy, gen
On Tue, Aug 8, 2017 at 10:20 PM, Viktor Dukhovni
wrote:
>
> > On Aug 8, 2017, at 6:24 PM, Daniel Margolis
> wrote:
> >
> > mode=none still requires period refresh via HTTPS. So it fails the
> > requirement to be able to erase all trace of STS.
> >
> >
On Wed, Aug 9, 2017 at 10:48 AM, Viktor Dukhovni
wrote:
> On Wed, Aug 09, 2017 at 08:52:48AM -0700, Daniel Margolis wrote:
>
> > The time period during which a domain who opts out of STS must publish
> the
> > "opt out" signal--regardless of how it is expressed--
l let him chime in and maybe correct me. ;)
On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni
wrote:
>
> > On Aug 20, 2017, at 1:08 PM, Daniel Margolis
> wrote:
> >
> > Policies fetched via HTTPS are only valid if the HTTP response code is
> 200 (OK).
> > HTTP 3xx
ply delegate the
> mta-sts zone as the policy indicator TXT record doesn’t sit in it.
>
> On Mon, 21 Aug 2017 at 20:47, Daniel Margolis
> wrote:
>
>> My point was that if you host on Microsoft, you could have
>>
>> https://policy.example.com <-- cert
> On Tue, Sep 05, 2017 at 08:04:24PM +0200, Daniel Margolis wrote:
>
> > I had it in my head that a CNAME could only point to an A or , but I
> > can't find anything like that in the RFC at a quick glance, so perhaps I
> > made that up.
>
> You've made t
Jim and Viktor basically get it right, I think.
I don't believe this has any security value in warding off a DOS; anyone
who can inject a TXT record to a non-implementing domain can also inject
the A or CNAME for mta-sts.example.com.
What this does do which has real security value is allow you to
The MX-selection-vs-validation discussion (and change; note that in draft
03 and prior it worked the way you suggest) was in this thread:
https://www.ietf.org/mail-archive/web/uta/current/msg01914.html.
I agree that the modifying-MX-selection-loop is mostly a red herring, since
you can do as you s
I believe Google's MTAs are sending SNI. But the only time this would
matter would be for cases like
https://support.google.com/a/answer/2520500?hl=en, since ordinarily nobody
is validating identities on server-to-server SMTP.
Regarding arguments in favor of supporting SNI, Jim made the best attem
I've draft language stolen from HTTP/2 that just requires TLS 1.2 or
higher. If people want more specific language on this (e.g. blacklisted
cipher suites, MTI ciphers), please suggest it.
On Sun, Oct 29, 2017 at 1:05 AM Viktor Dukhovni
wrote:
>
>
> > On Oct 28, 2017, at 4:32 PM, Hanno Böck wr
Thanks. I think this is consistent with what was added here:
https://github.com/mrisher/smtp-sts/blob/master/mta-sts.txt#L633. If not,
let me know.
Thanks again.
On Fri, Mar 23, 2018 at 12:38 AM Viktor Dukhovni
wrote:
>
>
> > On Mar 22, 2018, at 4:17 PM, Daniel Kahn Gillmor
> wrote:
> >
> >>
>
Apologies for the slow reply here. (I was on vacation.)
Ned: thanks for the clear summary. I'll start working on those issues.
Dave: thanks also for the direct feedback. To be honest, though, after all
this discussion, I'm somewhat struggling to sort out what's actionable from
what isn't, as I su
Hey. Thanks for the feedback.
On Mon, Apr 16, 2018 at 6:10 AM Ben Campbell wrote:
>
> --
> DISCUSS:
> --
>
> I plan to ballot "Yes" for this, but there is an is
Whoah. Long thread.
For the record, I believe it's trivial to implement the hostname filtering
without applying it to the MX selection loop (and I think I've made this
observation before): if an invalid certificate is (as it must be) detected
after connecting to the chosen MX candidate (and thus c
on issue, but I am
generally hesitant to change things now if we don't have to.
On Sun, May 6, 2018 at 8:41 PM Viktor Dukhovni
wrote:
>
>
> > On May 6, 2018, at 12:55 PM, Daniel Margolis
> wrote:
> >
> > 2. Why is the "mx" pattern matched against the SA
Yes, that was exactly my point. That's why I was saying this is really an
implementation detail (albeit one you'd want to call out); the only
fundamental protocol question at issue is whether we should consider valid
a policy that matches only the cert but not the hostname itself.
On Mon, May 7, 2
On Thu, May 10, 2018 at 12:38 AM Benjamin Kaduk wrote:
> On Wed, May 09, 2018 at 11:43:50AM -0700, Ned Freed wrote:
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-uta-mta-sts-17: No Objection
> >
> > > When responding, please keep the subject line intact and r
Right.
An attacker who can inject false DNS resolutions can, of course, redirect
either the fixed mta-sts host or insert a spoofed TXT response--but by
allowing the attacker to specify what hostname to use, it is more likely
that attacks which indirectly allow an attacker to obtain a valid cert fo
Thanks. We (as you may know) renamed "report" mode to "testing" mode late
in the review process. I have fixed the errors in TLSRPT to be consistent
with MTA-STS in our working draft.
On Wed, May 9, 2018 at 8:49 AM Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> dra
wrote:
>
>
> > On May 10, 2018, at 2:13 PM, Daniel Margolis
> wrote:
> >
> > No, it's just a rushed edit on my part. My intent was t say that you
> should check the cached version against the version in HTTPS.
> >
> > One could argue (as you specu
Just to make sure I understand, your point was that there's no additional
risk introduced by having arbitrary hostnames for the Policy Host, and
having the hostname specified via the TXT record?
I tend to agree about the security reasoning (i.e., that having the TXT
provide indirection to the Poli
Cool, me too. :)
A few back and forth comments with Viktor on wording and we should be able
to cut a new draft shortly.
On Thu, May 17, 2018 at 3:22 PM Alberto Bertogli
wrote:
> On Sun, May 13, 2018 at 05:35:26PM +0200, Daniel Margolis wrote:
> >A first cut of language here:
&g
+1 for a JSON array.
On Mon, Jul 16, 2018 at 11:43 PM Brotman, Alexander <
alexander_brot...@comcast.com> wrote:
> Hello,
>
> While someone was beginning to write their code for TLSRPT, they noticed
> that mx-host-pattern is under specified.
>
>o "mx-host-pattern": The pattern of MX hostname
is a "feature" of REQUIRETLS.
>
> -Jim
>
> On 10/24/18 5:59 AM, Daniel Margolis wrote:
>
> I don't disagree with the points made here. If you know you need TLS from
> REQUIRETLS, and you know the desired MX identity from DNSSEC on the MX
> records, you don't
I don't think we discussed exactly that issue. We did entertain early on
the idea of having the policy in a TXT record instead of via HTTPS, but
moved to HTTPS for the obvious reasons.
I do think the observation that you don't really even need the policy
(except for the "mode" switch) in the event
Well, like I said, STS requires clients to provide SNI, so they should not
consider it an STS violation if they don't send SNI and consequently get
the wrong cert.
I am not claiming your setup is broken--just that among possible fixes (a
cert with many SANs, using SNI to serve one cert of many, re
e:
> >>>>> "DM" == Daniel Margolis writes:
>
> DM> Google should only be sending TLSRPT reports for time periods in which
> DM> there was mail sent.
>
> They send me daily reports for each of my tlsrpt zones to which they've
> sent any ma
43 matches
Mail list logo
