Re: [dns-privacy] Eric Rescorla's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, May 8, 2017 at 1:21 AM, Sara Dickinson <[e-mail]> wrote:

>
> On 6 May 2017, at 21:31, Eric Rescorla <[e-mail]> wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dprive-dtls-and-tls-profiles-09: Discuss
>
>
> Many thanks for the review.
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> S 9 mandates RFC 7250:
>   o  Raw public keys [RFC7250] which reduce the size of the
>      ServerHello, and can be used by servers that cannot obtain
>      certificates (e.g., DNS servers on private networks).
>
> This needs to be updated to indicate that the client MUST NOT
> offer 7250 unless it has a preconfigured SPKI, otherwise
> you're going to have interop problems.
>
>
> Agreed.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> TECHNICAL
> S 5.
>      subsequently connect.  The rationale for this is that requiring
>      Strict Privacy for such meta queries would introduce significant
>      deployment obstacles.  This profile provides strong privacy
>      guarantees to the client.  This Profile is discussed in detail in
>      Section 6.6.
>
> This point seems unclear. If you do these queries unprotected, then
> you don't have strong privacy guarantees. I think you mean that
> you get them via some trusted mechanism such as DHCP.
>
>
> No, we mean they could be done either via Opportunistic lookups or DHCP
> (see table 2.)
> The meta queries contain no information about what DNS lookups the client
> is doing other than what DNS Privacy server they are going to use to do
> their queries. But you are correct that the ‘strong privacy guarentees’
> apply only to the subsequent queries to the Privacy server and the text
> should be updated to clarify that.
>

Well, per my previous comment, I think you need to focus on the entire
strategy.

I.e., if you determine whether to adopt a Strict policy based on
Opportunistic queries, then you are back to the active attack setting. I
don't have a problem with your design here, which seems to be about as good
as one can do; I'm just trying to make sure the description is accurate...


Table 1 seems to have N and D paired, so maybe you can coalesce them?
>
>
> That specific question was asked on the WG mailing list and the answer was
> ‘no, please keep both’:
> https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01541.html
>

OK. Perhaps add some text that theya re paired



S 6.4.
>   A DNS client that is configured with both an authentication domain
>   name and a SPKI pinset for a DNS server SHOULD match on both a valid
>   credential for the authentication domain name and a valid SPKI
> pinset
>   (if both are available) when connecting to that DNS server.  The
>   overall authentication result should only be considered successful
> if
>   both authentication mechanisms are successful.
>
> You should cover the topic of user-defined trust anchors. Here's the
> relevant text from 7469:
>
>   For example, a UA may disable Pin Validation for Pinned Hosts whose
>   validated certificate chain terminates at a user-defined trust
>   anchor, rather than a trust anchor built-in to the UA (or underlying
>   platform).
>
>
> We purposely avoided adding any details on the SPKI mechanisms in this
> document because this document simply refers to RFC7585 which then directly
> references RFC7469. But if you think this is needed here also then I’ll add
> it.
>

The concern I have is that this guidance seems to implicitly contradict the
guidance from 7469. So I think you should either just say that if you have
both you treat it like a 7469 pin, or say something like "successful, with
the possible exception of certificates which chain to local trust anchors,
as described in..." Or, alternately really prohibit this. Also, should ->
SHOULD.


>
>
> EDITORIAL
> Do you want to cite TLS 1.3 at this point?
>
>
> Early on we chose not to include a normative reference to the TLS 1.3
> draft to avoid the dependancy on that becoming an RFC but are you
> suggesting we do that now or just include an informative reference?
>

I would think at least an informative reference would be useful.


Do you think Section 9 the right place to talk about TLS 1.3 in general or
> do you feel there are specific points to made elsewhere in the text?
>

1.3 has pretty much the same properties here, so I think you might just
cite 1.3 and make it informative. I'm not sure what the right actual
mechanics are here, but surely such a thing is possible.



> S 3.
>   o  Any server identifier other than domain names, including IP
>      address, organizational name, country of origin, etc.
>
> addresses, names, for parallel structure with domain names
>
>
> Ack.
>
>
>
> S 9.
>   There are known attacks on (D)TLS, such as machine-in-the-middle and
>   protocol downgrade.  These are general attacks on (D)TLS and not
>   specific to DNS-over-TLS; please refer to the (D)TLS RFCs for
>   discussion of these security issues.
>
> This text seems pretty unhelpful. Given that you are specifying 1.2,
> if you also require the relevant strong algorithms, then there should
> not be downgrade or MITM attacks.
>
>
> How about moving the justification later in the section:
>
> “ Clients and servers MUST adhere to the (D)TLS implementation
>    recommendations and security considerations of [RFC7525] except with
>    respect to (D)TLS version.
>
>   Since encryption of DNS using (D)TLS is a green-field deployment DNS
>    clients and servers MUST implement only (D)TLS 1.2 or later.
>
>   These requirements ensure mitigation against known attacks on
>   (D)TLS, such as machine-in-the-middle and
>   protocol downgrade.  These are general attacks on (D)TLS and not
>   specific to DNS-over-TLS.”
>

My complaint is that this seems kinda FUDdy. If there are things that you
think people
ought to do other than those in 7525, you ought to say them.

-Ekr