On Thu, Dec 03, 2015 at 02:08:29AM -0000, John Levine wrote:
> >In any case, absent DNSSEC validated SRV records, there is no good
> >way to deploy transport security for *hosted* submission and imap
> >services without users manually selecting the underlying provider
> >hostnames as the service endpoint.
>
> Yup. We're exactly where we are now, he said tautologically.
>
> >With DNSSEC validated SRV records, one may as well use DANE. That
> >said, DNSSEC is as yet not a ubiquitous viable option for mobile
> >clients, we need many years of upgrades of public WiFi networks
> >before one might be able to expect DNSSEC signed SRV records to
> >reach one's mobile device.
>
> I wouldn't disagree, but I also don't see anything on the horizon
> better than SRV+DNSSEC. It's an architectural fact that mail servers
> host lots of domains, and that server configuration has historically
> been pretty casual.
OK, but we should probably at this point return to discussing the
draft, it being Last Call and all that. What does all this mean
in terms of the draft?
* The draft attempts to introduce SRV-ID as a security mechanism
for mail services. SRV-ID does not require DNSSEC, but does
require that CAs be able to figure out which service providers
are legitimately hosting a given domain.
Is the objection that this is not realistic? I can see that it
won't always be an option. There is a class of service providers
for whom this is possible, namely those that are also WebPKI CAs.
So GoDaddy and the like would be able to issue SRV-ID certificates
for domains they host. Is that enough to justify including the
SRV-ID use-case in the draft?
Or is it the case that you'd prefer text that says that the problem
has no broadly workable solution in the absence of DNSSEC? In
which case the SRV-ID proposal might be a non-starter? Then the
options we're left with are explicit target server configuration
by users with WebPKI + DNS-ID (of user-specified server names) or
DNSSEC + SRV + DNS-ID (with either WebPKI or DANE for whatever
hostname appears as the target of the SRV).
My take is that the draft explains what it *would* take to try to
secure 6186 in the absence of DNSSEC, and if gets adoption fine,
and if it doesn't at least the obstacles are more clearly explained.
Yes, I am somewhat skeptical of the practicality of the model, but
since it is basically the only plausible alternative to either
manual configuration (including MUA wired-in per-provider settings)
or SRV + DNSSEC, I see no harm in it, whether it works out or not.
The draft is very concise, perhaps there should be more discussion
of the difficulties that lead to its recommendations, including
the some text to the effect that while DNSSEC (with perhaps DANE)
might address the issues more neatly in the future, this document
aims to specify practices one could employ today (or at least soon).
Which brings us back to the question of whether WebPKI SRV-ID
certificates can be employed now or in the near future widely enough
to warrant the ink.
--
Viktor.