Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

[Ben Schwartz <[e-mail]>]

On Wed, Jun 16, 2021 at 11:47 AM Tommy Jensen <Jensen.Thomas=
[e-mail]> wrote:
...

> Hey Ben,
>
>
>
> I appreciate your efforts in keeping up with the base draft, but I think
> your proposal is best served by a separate document.
>

Perhaps.  I think we need more WG input on which use cases are most
relevant.

The expanded scope it introduces significantly lowers the security posture
> of DDR overall, which you indirectly acknowledge in the text:
>
>
>
> “If the client does not have a Validation Identity, or the Validation
> Identity
>
> was discovered insecurely (e.g. via CNAME), the client SHOULD limit the
>
> validity duration of the discovered information (e.g. the SVCB response
>
> TTL) to no more than 5 minutes. The client MAY make use of this encrypted
>
> connection, but SHOULD NOT assume that the connection is more secure
>
> than an unencrypted connection.”
>
>
>
> I do not think we should be trying to add this to a standard that
> otherwise provides connections of improved security. While DDR can be
> blocked by an on-path attacker, a successful upgrade can be trusted to be
> an entity designated by the original resolver owner.
>

I don't agree with this assessment.  When the unencrypted resolver is
identified by a private IP, both versions are susceptible to capture and
forgery by an on-path attacker.  When it has a public IP or name, neither
version is.


> This PR introduces a mechanism where that is not true.
>

The difference is much subtler.  In draft-01, private IP upgrade is
vulnerable to capture by any on-path attacker.  In PR #11, private IP
upgrade is additionally vulnerable for a short time window after an on-path
attacker ceases to be on-path.  This time can be driven to ~zero by
revalidating the designation before each query, but I think revalidating
every few minutes is likely to be sufficient in practice.

If PR #11 enables significantly broader use of encrypted DNS, as seems
likely, I think it would represent an improvement to overall security.

Since clients will have different opinions on the need to support DDR as it
> is currently defines versus this PR, we should provide them as separate
> documents to avoid clients deploying only partial standard support (as it
> seems likely many will choose to not support this option).
>
>
Since the protocol elements are unchanged, one possibility would be to name
client profiles with different acceptance criteria.

>