Re: TLS connection reuse implementation timeline (#4089)

[Eric Luehrsen via Unbound-users]

On 07/05/2018 06:25 PM, nusenu via Unbound-users wrote:

Eric Luehrsen via Unbound-users:

If Unbound cache and prefetch parameters are configured properly,
they can mitigate the TLS handshake overhead.


Unless you have a cache hit rate of 100%, cacheing and prefetching
will not be able to compensate missing TLS connection reuse.


(but that was not what my question was about)


Okay, the question was time line. I hope Unbound designers answer with 
an outline for time and design considerations. Whether a month or a 
year, some short term workaround may be useful. All workarounds (adjust 
cache and prefetch) are imperfect but may get by short term. At some 
reasonable cache rate, TLS connections will likely expire anyway before 
fresh data is needed. Neither server nor client will want excessive 
dangling connections. The gap in behavior may not be as big as it seems.

Re: TLS connection reuse implementation timeline (#4089)

[nusenu via Unbound-users]

Eric Luehrsen via Unbound-users:
> If Unbound cache and prefetch parameters are configured properly,
> they can mitigate the TLS handshake overhead.

Unless you have a cache hit rate of 100%, cacheing and prefetching
will not be able to compensate missing TLS connection reuse.


(but that was not what my question was about)


-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature

Re: TLS connection reuse implementation timeline (#4089)

[Eric Luehrsen via Unbound-users]

On 07/05/2018 04:53 AM, nusenu via Unbound-users wrote:

Hi,

Since unbound's missing TLS connection reuse feature
is now used as a justification [1] why DoH [2] has better software
than DoT I was wondering if you had any timeline
for TLS connection reuse in unbound, which is already in your bugzilla:

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089

I'm looking for a rough estimate, something like:
will be released within
- 3 month,
- before the end of the year
- in 2019

thanks!
nusenu


[1] https://twitter.com/FiloSottile/status/1014603362204028935
[2] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1200



Unbound current behavior may be a bit inefficient, but at least it is a 
robust and repeatable behavior. If Unbound cache and prefetch parameters 
are configured properly, they can mitigate the TLS handshake overhead. 
For the limited users of DOT (or DOH) this is not so awful.


I could see outstanding design decisions to make: what is a minimum time 
to wait for new queries before closing an idle connection? what is a 
maximum time to wait to drop and redo a connection? will minimum timer 
reset on any new query, or does it extend with some weight function? how 
will this affect the client and server relationship? how long should a 
public DNS accept a dangling connection (thinking about 1.1.1.1)?


As far as DOH vs DOT, the rhetoric is becoming a little silly. As with 
all things, there is and will be the right tool for the right job. It 
seems a minor stumble in deploying a specification should not be used as 
justification for another. That is, if we use a disciplined scientific 
method.


Eric