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

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 extended to support arbitrary error reporting; an
out-of-band (e.g. HTTP) channel to share delivery failures between domains
strikes me as useful in the general case.

Separately, because we're already assuming providers (both sending and
receiving) make a choice on implementing DANE and/or webPKI, I don't think
actually splitting the two makes it any more or less complex to implement,
or should discourage adoption of one or the other mechanism.

So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd
like to chat a bit more with my co-authors and think about it first. ;)

Viktor, as an aside regarding the hosted mail scenario, we already had the
suggestion to move the HTTPS endpoint to something like "_
smtp_sts.example.com/current". If we do that, the customer (example.com)
can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to
serve the policy with the customer's cert (assuming the customer trusts the
hosting provider with this; for domains that don't operate their own HTTPS
endpoint this seems to me to be likely). For the more complex case, the
cron setup you describe doesn't seem too onerous, I agree.

Thanks again for the feedback.

On Tue, Mar 22, 2016 at 10:21 AM, Neil Cook <neil.cook@noware.co.uk> wrote:

>
> > On 22 Mar 2016, at 08:49, Viktor Dukhovni <ietf-dane@dukhovni.org>
> 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.  Do not duplicate data which one must in any case
> > obtain and cache via HTTPS in DNS.
> >
> > Do not attempt to hedge your bets and support DANE/DNSSEC via STS,
> > I don't think that makes much sense either.
> >
>
> I agree with the “don’t hedge your bets” part. I was quite surprised to
> see all the justification for STS in the first part of the document,
> including “the mechanism described here presents a variant for systems not
> yet supporting DNSSEC”, and yet then goes on to include DNSSEC as one of
> the policy authentication mechanisms.
>
> >    * Allow (DANE or other) domains to publish just the RUA,
> >      the feature is not STS-specific.
> >
> +1
>
> Neil
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>