Re: [Add] Terminology in draft-ietf-add-requirements - "secure" etc

[Eric Rescorla <[e-mail]>]

On Wed, Jul 7, 2021 at 11:08 PM Patrik Fältström <paf=
[e-mail]> wrote:

> In the requirements document, wordings are used like (example from section
> 4):
>
> > Redirect secure DNS traffic to themselves when
> > they would not otherwise handle DNS traffic.
>
> I find it a bit confusing what the wording "secure DNS traffic" implies.
>
> In various scenarios we might have (at least) situations when the traffic
> between stub and recursive resolver is encrypted or not. And it might be
> validated on the recursive resolver or not, and it might be possible for
> the stub resolver to query with DO flag or not.
>
> Or to put it differently, the DNSSEC validation might:
>
> 1. Not take place at all
> 2. Take place in the recursive resolver side
> 3. Take place in the local client
>
> In case (1) there is not much to do.
>
> In case (2) the client must trust the recursive resolver.
>
> In case (3) the recursive resolver do not have to trust the resolver.
>
> In all cases the transport between client and recursive resolver can of
> course be encrypted or not.
>
> May I ask for some carefully selected language here so that we do not call
> all three cases "secure"? Specifically if the only thing we are looking for
> is encrypted communication between stub and recursive resolver?
>
> And IF we have some flags and negotiation taking place, would it not be a
> good idea for the client to actually know where validation takes place?
>

Well, the client surely knows whether validation is taking place on the
client (spoiler alert: infrequently). How does an encrypted transport
change its epistemic situation wrt the recursive's validation practices
from where we are now?

-Ekr