Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-01.txt

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 15, 2015 at 12:53:46PM -0400, Shumon Huque wrote:
> On Wed, Jul 15, 2015 at 12:01 PM, Ilari Liusvaara <
> [e-mail]> wrote:
> 
> > On Wed, Jul 15, 2015 at 11:36:04AM -0400, Shumon Huque wrote:
> > > On Tue, Jul 14, 2015 at 5:43 AM, Ilari Liusvaara <
> > > [e-mail]> wrote:
> >
> > The various security issues include POODLE TLS against some endpoints,
> > LUCKY13 (various endpoints try to mitigate, but maybe not fully),
> > length-recovery attacks via truncated_hmac and probably some other
> > subtle attacks.
> >
> 
> Thanks for the elaboration. So if we follow the recommendations in the TLS
> BCP (to summarize, TLS 1.2 only with AEAD ciphersuites), we are safe from a
> bunch of these: POODLE, LUCKY13 (both padding oracle attacks), right? Is
> there a pointer to the length recovery attack (and do we really care about
> that for DNS privacy)?

Yeah. As for pointer for length recovery, it is in one of the references
of TLS BCP. The impact is seemingly to allow attacker to tell the amount
of padding inserted at TLS level.

> > TLS 1.3 will remove stream and block type ciphers (as well as
> > RSA key exchange).
> >
> 
> That's great. There is one other feature in TLS 1.3 that will be beneficial
> for DNS over TLS implementations for performance/latency reasons: the
> planned 0-RTT mode for resumed sessions with previously seen resolvers
> (most clients will take to the same resolvers), which will frequently cut
> out 1RTT.

Actually 0RTT is allowed even if performing full handshake (if the server
has valid key on file, this also allows for skipping certificate auth).


-Ilari