On Wed, Jul 15, 2015 at 12:01 PM, Ilari Liusvaara < [email protected]> 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 < > > [email protected]> wrote: > > > > > One problem with TLS is that there is no way to perform > > > TLS record padding without resorting to obsolete stuff with > > > known security issues (enough to trigger user-visible > > > warnings in Chrome) and not supported in TLS 1.3 (or yet > > > to be defined extensions). > > > > > > > Can you elaborate on the security issues, and also on what specific > > warnings Chrome puts up? - I probably haven't kept up with this topic, > but > > I was under the impression that the padding oracle attacks don't work > > against TLS 1.2 with AEAD ciphersuites. > > Background: There are three cipher modes in TLS 1.2. > - Stream: Only has bad ciphers. Don't use. > - Block: CBC ciphers. Supports padding, but vulernable to many attacks. > - AEAD: GCM and Poly1305 modes. Does not support padding. Regarded > as modern ciphers. > > 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)? > > The Chrome warning "uses obsolete cryptography" is given for using > RSA key exchange (not to be confused with DHE or ECDHE signed with > RSA key) or any cipher that isn't of AEAD type. I think the warning > is in panel popped up by clicking on the lock icon. > Ok, so the TLS BCP addresses this too. > 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. Shumon Huque
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
