Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Yeah, this doesn't seem like an actually secure set of practices, which is
why we don't do it for HTTPS even when there are CNAMEs.

-Ekr


On Fri, Oct 27, 2017 at 12:20 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Oct 27, 2017, at 2:34 PM, Eric Rescorla <[e-mail]> wrote:
> >
> > So to be clear, what you are saying is that when I enter "
> mail.example.com" but it's hosted on "mailhosting.com", and that
> indirection is done via SRV, that the certificate contains "
> mail.example.com" but the SNI contains "mailhosting.com"?
>
> I would expect a mail user agent that actually uses RFC 6186 to
> obtain the target name from SRV records (do any MUAs support this
> yet?) to set the reference identifier also to the SRV target,
> either because it was validated via DNSSEC, or via a confirmation
> dialogue.
>
> Thus both the SNI name and the reference identifier will the same,
> in your example "mailhosting.com".
>
> One might also secure the MUAs use of SRV records with DANE,
> see also https://tools.ietf.org/html/rfc7672#section-7
> https://tools.ietf.org/html/rfc7673 in which case the SNI
> would again be the target domain.  The server cannot know
> whether the client is statically configured to use the target
> name, used SRV with DANE, or SRV with just DNSSEC and WebPKI.
>
> The bottom line is that no matter how the client gets there,
> the SNI and reference identifier are the SRV target, but
> without DNSSEC, and with SRV-ID unlikely to be practiced,
> RFC 6816 requires user confirmation, with all its flaws...
>
> --
>         Viktor.
>
>
>
> --
>         Viktor.
>
>