Re: [Uta] UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

[Viktor Dukhovni <[e-mail]>]

On Tue, Dec 01, 2015 at 06:38:02PM -0000, John Levine wrote:

> >The key word in that text is "another".  This does not require the
> >server to have a certificate that matches this identifier, provided
> >there is some other some suitable identifier.  It provides additional
> >flexibility, not a constraint.
> >
> >NOTE HOWEVER, that use of the server name from the SRV record as
> >a DNS-ID reference identifier offers no security at all absent
> >DNSSEC.  So "another" might become "only" in that case.
> 
> Then we have a problem, since the SRV-ID is just an assertion from the
> server.
>
> What's to keep an evil MITM from putting dukhovni.org as a
> SRV-ID in its submit and imaps certificate?

The trusted CA presumably, if it is not negligent.

> >I am not aware of any adoption of RFC 6186.  Are there are any MUAs
> >actually doing RFC 6186 SRV lookups?  If there are none, is it worth
> >debating?
> 
> In the lack of plausible alternatives, I think so.

Well, the plausible alternatives are explicit static configuration
of the server names by the user, per instruction from the provider.
This "out of band 6186" if you like.  That's largely what happens
today, except that for some popular providers, many user agents
come preloaded with default settings.

The other plausible alternatives are DNSSEC, or "ask the user".

-- 
	Viktor.