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 <ietf-d...@dukhovni.org> wrote: > > > > On Oct 27, 2017, at 2:34 PM, Eric Rescorla <e...@rtfm.com> 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. > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
