Doesn't DANE produce the server's certificate in the same connection that DNS
produces the servers IP address? If not, that's an optimization that's needed.
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
