Re: [Add] A proposed charter for ABCD

[Ted Lemon <[e-mail]>]

Actually, the meaning of the term “trust” in computer security is not at all ambiguous, and your descriptions make things less clear, not more. 

Most of what you say here is just missing the point I made earlier. Trust is a decision: in order to do what I want, I must trust some thing. How do I enforce this?  With cryptographic authentication. 

DNSSEC is a cryptographic authentication mechanism. It does not establish trust. It allows me to authenticate your identity, which I may or may not trust. TLS provides a similar capability. 

Privacy is a thing that I might or might not trust you to provide for me. One of many things.

Your identity is how I mark you as trusted. Cryptographic authentication is how I validate that you actually are who you claim to be: that your identity is the identity I have marked as trusted.

The way you have attempted to explain this is much more complicated, and does not make things clearer.  See if you can talk about this in terms of trusted services, trusted identity and authentication of identity. It will be a lot easier to understand. 

> On Jan 2, 2020, at 16:17, Brian Dickson <[e-mail]> wrote:
> 
> 
> 
> 
>> On Thu, Jan 2, 2020 at 6:11 AM Ted Lemon <[e-mail]> wrote:
>> On Jan 2, 2020, at 5:00 AM, Ralf Weber <[e-mail]> wrote:
>> > Can you define trust relationship / authenticating configuration data. Depending on how you define that the solution is either obvious or impossible. As an ops guy and non native english speaker I often struggle with abstractions, so let me give you an concrete example you can hopefully give an answer on:
>> 
>> Good questions, thanks.
>> 
>> > - A router sends a client an PvD RA as defined in (draft-bruneau-intarea-provisioning-domains - https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/ ) with FQDN content of pvd.myisp.net.
>> > - My system retrieves https://pvd.myisp.net/.well-known/pvd and can DNSSEC validate the domain and the HTTP certificate
>> > - In the JSON blob retrieved contains the following keys (see draft-pauly-dprive-adaptive-dns-privacy - https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/?include_text=1 ):
>> >    dohuri: https://doh.myisp.net/dns-query
>> >    requireDNSFiltering: True
>> >    dnsFilteredZones: “.”
>> > I can again DNSSEC validate the domain and the HTTP certificate using they key stores available with my system.
>> > 
>> > Is that authenticated? Is there a trust relationship?
>> 
>> No.   You have no more reason to trust that than you do any other random HTTPS-authenticated web site that you might try to access.   When you go to https://www.badguy.com, you know that it’s really www.badguy.com because the TLS cert validates, and maybe the DNSSEC validated, but you /don’t/ have any reason to trust answers you get from that site.
>> 
>> That’s why I say there’s no reason to go through any extra bother.   In order to have a trust relationship, I need to have configured a list of sites I trust as DNS resolvers.  This is independent of the RA I receive, or the DHCP message I receive.
>> 
>> Then when I get an RA or a DHCP message asserting the availability of a DNS resolver, if I have a trust relationship with that resolver, and I can validate the cert upon connecting, then it’s a “trusted resolver.”   Otherwise, it’s an “untrusted resolver.”   It’s the pre-established trust relationship that makes it trusted, not some assertion I get from the network about it being trustworthy.
>> 
>> E.g., suppose I trust the SLA from my ISP.   I believe that my ISP will not snoop on my DNS data, and I want to use their resolver.   If their resolver is using DoH or DoT, then I can list the domain name(s) of their resolver in my list of trusted resolvers.   When I am offered one of these resolvers, I can validate that I’m actually communicating with it, by validating the TLS cert, and then I can trust it, because of that pre-established trust relationship, not because of any assertion the network made about its trustworthiness.
>> 
>> Absent some kind of out-of-band trust establishment process like this, there can’t be a trust relationship with a resolver.
> 
> "If there were any sense to the English language, trust would be a four-letter word." - Risky Business quote.
> 
> One of the problems we are having in this thread, is the terminology, which I'd like to suggest a couple of substitutes for clarity.
> "Trust" can have several meanings, which is unfortunate in that the inherent ambiguity causes unclear meaning.
> 
> Perhaps two distinct terms or phrases would be appropriate - one for what DNSSEC provides (data integrity protection), and one for privacy. 
> Maybe we could just use DNSSEC and privacy?
> 
> I'd like to start with Ted's last statement, and break it into two related components, which are actually both relevant using both meanings of "trust".
> - Absent some kind of out-of-band DNSSEC establishment process, there can't be a DNSSEC relationship with a resolver 
>    (I'd actually prefer to use "server" here, since a client is UNABLE to distinguish a resolver from a forwarder.)
> - Absent some kind of out-of-band privacy establishment process, there can't be be a privacy relationship with a resolver. (Same concerns on server rather than resolver.)
> 
> The assumption that may be being made is that the only way to have a DNSSEC relationship with a resolver, is when two conditions are true:
> - The resolver has a globally unique, resolvable name with a chain of (DNSSEC) trust from the DNS Root Trust Anchor
> - The name of the resolver is known (or discoverable), and the URI for the service in question is also well-known
> These generally require some OOB method of discovery/publication/usage.
> The relevance of the following statement is unclear, but it should be noted: there is basically no way to validate the claim of a given network, of the network's association with the resolver (e.g. whether they are part of the same ISP, etc.)
> 
> There is another way by which a DNSSEC relationship to a resolver can be established, which is very much non-obvious: the OOB publication of a specific DNSSEC Trust Anchor, for a zone which publishes some server-related information.
> For example, a DNSKEY associates a name with a public key for a named zone. The contents of that zone can be signed with DNSSEC, and those signatures validated with the DNSKEY. 
> The degree of trust in the DNSSEC status is dependent on the manner of the OOB publication. However, revocation of such trust is trivial (unpublish the zone or roll the key) and provides POP (proof of possession of the private key).
> 
> The information in a signed zone can be used for bootstrapping any number of related DNS mechanisms (e.g. TLSA records), or even unrelated mechanisms for bootstrapping other associations (lots of possibilities, such as URIs for network support, URIs for web pages that have QR codes for whatever other stuff you want to publish).
> 
> The FQDN of such a Trust Anchor, DOES NOT need to be global at all, and the real value is being able to use names which have only local significance (e.g. under the local-use ISO namespaces such as "zz").
> 
> The bootstrap method for upgrading from DHCP-provided resolver IP could be as simple as connecting on port 53 and asking for a global well-known name, which returns the FQDN of the server (even if that FQDN is locally scoped under "zz"). If a match is found in the set of Trust Anchors, look things up in that zone and validate with the corresponding TA (or the Root TA if the FQDN is global.) Bootstrap to having a DNSSEC trust relationship is then complete.
> 
> What data is published in a signed zone of this sort is entirely open to standardization, for any number of use cases.
> 
> Examples could include:
> - Methods of providing ways of authenticating Access Points (since the SSID is not trustworthy in general, and the normal authentication of public SSIDs is "none" or "client to SSID" rather than the other way around).
> - URIs for HTTPS connections for arbitrary uses, e.g. including obtaining short-term guest credentials to use on WiFi
> - URIs for SSL VPNs (much better than just encrypting DNS)
> - any well-known prefix-based services (_SOMETHING._TCP)
> - CNAMEs, DNAMEs to FQDN-based services
> - Anything anyone wants to standardize for bootstrapping from locally scoped network connections
> 
> Brian
>