On Wed, Dec 16, 2015 at 10:50 PM, Paul Vixie <vi...@tisf.net> wrote:
> On Wednesday, December 16, 2015 09:08:03 PM Robert Edmonds wrote:
>
> > Shane Kerr wrote:
>
> > > I have updated the DNS over HTTP review document that I sent some days
>
> > > ago. Thanks to Jinmei for reading it.
>
> > >
>
> > > As I mentioned before, if there is interest then my co-authors and I
>
> > > are happy to try to get the working group to adopt the document. If
>
> > > there is not interest, then we are happy to go forward with an
>
> > > individual submission.
>
> > >
>
> > > If I don't hear any positive support over the next week or two then
>
> > > that is a pretty clear sign that the working group has little
>
> > > interest. :)
>
> >
>
> > Hi, Shane:
>
> >
>
> > Given BCP 188 ("Pervasive Monitoring Is a Widespread Attack on Privacy"
>
> > and "The IETF Will Work to Mitigate Pervasive Monitoring"), I'm a bit
>
> > disappointed that "HTTPS" is spelled "HTTP(S)" in your document :-) If
>
> > you're going to go to the trouble of defining a new transport for DNS,
>
> > what's the rationale for allowing the transport to permit plaintext?
>
>
>
> as the author of the first prototype, let me say that the client side
> proxy's only knowledge of its server side proxy is its IP address, whereas
> SSL needs a host name. i'd be happy to have all that specified by people
> who understand it, alone with client-side certs and server-side SSL ACL's.
> but i'll still likely use raw HTTP in some situations, so that should also
> be specified, even if explicitly discommended by the final published
> document.
>
>
>
Paul,
SSL (Actually "TLS", since no-one should use SSL any more) doesn't *need* a
hostname. TLS supports many identity forms that aren't hostnames. It's
perfectly possible to establish a TLS session with the client knowing only
the IP address of the server, and with some preconfigured knowledge of the
server, the client can even establish an' authenticated' TLS session.
However, there may be reasons to use hostnames (e.g. to allow more
recognizable associations of the DNS server's identity for users). Many
such details are being written up by some folks involved in the DNS over
(D)TLS efforts in a companion document. You could consider reusing that
work.
Shumon.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
