Warren,
Since my proposal is now hooked to the widespread deloyment of DANE, and if
DANE is being hindered by an ancient DNS protocol that requires multiple
connections to secure a server's certificate and IP address, I'll have to
include an item for DNS 2.0 that allows for multiple commands and multiple
reponses in a simple cpio like data stream.
Thanks for your help!!
Karl Malbrain
________________________________
From: Warren Kumari <[email protected]>
To: Karl Malbrain <[email protected]>
Cc: Randy Bush <[email protected]>; Leif Johansson <[email protected]>;
"[email protected]" <[email protected]>; Warren Kumari <[email protected]>
Sent: Friday, September 13, 2013 4:03 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication
protocol
On Sep 13, 2013, at 6:19 PM, Karl Malbrain <[email protected]> wrote:
> Doesn't DANE produce the server's certificate in the same connection that DNS
> produces the servers IP address?
Nope.
> If not, that's an optimization that's needed.
Would be nice, but, unfortunately DNS doesn't really allow you to return
answers to questions that the client didn't ask…
There are all sorts of sexy (and dangerous :-)) things that you could do if it
did...
E.g. - if a client asks for the A record for www.example.com they are
presumably trying to reach my webserver and render a page -- which contains
images from images.example.com and some ads from www.punchthemonkey.com, so I
would like to be able to return:
www.example.com 600 IN A 192.0.2.2
images.example.com 600 IN A 192.0.2.3
www.punchthemonkey.com 600 A 192.0.2.100.
Or, even just returning MX responses in addition to A and AAA…
W
>
>
> Karl
> From: Warren Kumari <[email protected]>
> To: Karl Malbrain <[email protected]>
> Cc: Randy Bush <[email protected]>; Leif Johansson <[email protected]>;
> "[email protected]" <[email protected]>; Warren Kumari <[email protected]>
> Sent: Friday, September 13, 2013 3:03 PM
> Subject: Re: [perpass] proposed enhancement to TLS strong authentication
> protocol
>
>
> On Sep 13, 2013, at 4:40 PM, Karl Malbrain <[email protected]> wrote:
>
> > I'm not familiar with DANE. Is it operational?
>
> Yes, it is just not widely (enough) deployed. There are some browser
> extensions and a browser (Bloodhound) that has support built in. There are
> good tools to generate the DANE (TLSA) records, and e.g registro.br has a
> simple one click "generate and publish a TLSA record" record for hosted DNS
> customers.
>
> It is gaining traction in mail / SMTP, with support in Postfix.
>
> At the moment one of the main deployment hurdles is browser support (and more
> DNSSEC deployment!).
> Browsers (understandably) don't want to be waiting on TLSA records -- latency
> is really important for browsers, and waiting for more DNS lookups takes time.
>
> A few solutions have been discussed / suggested, such as only doing DANE for
> self-signed certs, doing the TLSA lookup in parallel with the regular lookup
> and making the normal connection, then aborting it (and replacing the page
> with a notice) if DANE shows evidence of shennanigans and / or caching TLSA
> records.
>
> W
>
> > Does it include changes to TLS to accept/compare the server's certificate
> > obtained from DANE? If so, then that part of the proposal can be mooted in
> > favor of DANE.
> >
> > Yes, it would be simpler to offload the certificate sourcing management to
> > DNS. However, I'm proposing changes to be implemented entirely within TLS,
> > that are transparent on the client side. Only the server side would
> > require an additional interface to accept/reject client connections.
> >
> > Karl
> >
> > From: Randy Bush <[email protected]>
> > To: Karl Malbrain <[email protected]>
> > Cc: Leif Johansson <[email protected]>
> > Sent: Friday, September 13, 2013 1:24 PM
> > Subject: Re: [perpass] proposed enhancement to TLS strong authentication
> > protocol
> >
> > [ off lst ]
> >
> > > I've dropped the idea of including both client and server public
> > > certificates in the directory in favor of a server certificate only
> > > repository with an additional TLS interface to authorize access by
> > > clients.
> >
> > so why is this a win over dane?
> >
> > randy
> >
> >
> > _______________________________________________
> > perpass mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/perpass
>
> --
> Hope is not a strategy.
> -- Ben Treynor, Google
>
>
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
>
>
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
--
With Feudalism, it's your Count that votes.
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
