On Tue, Jul 14, 2015 at 5:43 AM, Ilari Liusvaara <
[email protected]> wrote:
> On Tue, Jul 14, 2015 at 04:58:03AM +0000, Wessels, Duane wrote:
> >
> > We believe that this update addresses the working group's concerns
> > and hope that the document can progress to last call soon.
>
> I didn't see any discussion about requirements on TLS if any.
>
> Given that this is a new service, running on a "fresh" port
> (so no problems like HTTP/2 faced), one can set the bar
> relatively high.
>
Yes, I agree. I think this draft should probably reference the TLS BCP doc
(RFC7525) and recommend the use of no less than TLS 1.2 with AEAD
ciphersuites. There are no backwards compatibility considerations here to
consider anything weaker.
Or the document could write out the specific TLS requirements itself, or
have them listed in another document ("A TLS profile for DNS"?).
I've mentioned all these things to Allison Mankin previously, and I believe
she was favoring the approach of pointing to RFC7525.
> 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.
> So if query/response padding is to be done (and I think it
> does), it needs to be somehow done on DNS level.
>
> Also, regarding pre-deployed profile, what names are the
> certificate validated against (assuming it is not RPK
> [RFC7250])? The name is stored in the same config as
> the resolver IP and the pinned key?
>
This is good question. For pre-configured stub to resolver profiles, raw
public keys might actually make sense to avoid getting into chicken and egg
issues involving the server's DNS name.
Shumon Huque
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
