{"action":"created","issue":{"url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/52","repository_url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https","labels_url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/52/labels{/name}","comments_url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/52/comments","events_url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/52/events","html_url":"https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/52","id":281855278,"number":52,"title":"bootstrapping / circular dependency in hostname resolution?","user":{"login":"collinanderson","id":129234,"avatar_url":"https://avatars3.githubusercontent.com/u/129234?v=4","gravatar_id":"","url":"https://api.github.com/users/collinanderson","html_url":"https://github.com/collinanderson","followers_url":"https://api.github.com/users/collinanderson/followers","following_url":"https://api.github.com/users/collinanderson/following{/other_user}","gists_url":"https://api.github.com/users/collinanderson/gists{/gist_id}","starred_url":"https://api.github.com/users/collinanderson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/collinanderson/subscriptions","organizations_url":"https://api.github.com/users/collinanderson/orgs","repos_url":"https://api.github.com/users/collinanderson/repos","events_url":"https://api.github.com/users/collinanderson/events{/privacy}","received_events_url":"https://api.github.com/users/collinanderson/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-12-13T18:45:06Z","updated_at":"2017-12-13T20:58:01Z","closed_at":null,"author_association":"NONE","body":"If DOH uses https under the hood, how does this https host name get resolved? I would have expected this to be mentioned in the RFC, though I didn't see any mention of it, besides OCSP Stapling.\r\n\r\nIs it assumed that DOH would need to be bootstrapped by traditional DNS?\r\n\r\nOr is it assumed that a DOH endpoint would have a TLS/SSL certificate for its ip address? (Apparently a certificate for an IP address is possible in some cases, though hard to get.)\r\n\r\nI assume DOH is not intended to be used by home NAT routers? (How would the router get a signed TLS certificate? Maybe a DHCP response could say: use this DOH url and trust this self-signed cert for its ip address (though a certificate might be too big for a DHCP response). Or, in cases where no local DNS services are needed, the DHCP response could maybe say: use this public DOH url, here's the ip address for that hostname)"},"comment":{"url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/comments/351519874","html_url":"https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/52#issuecomment-351519874","issue_url":"https://api.github.com/repos/dohwg/draft-ietf-doh-dns-over-https/issues/52","id":351519874,"user":{"login":"mcmanus","id":260531,"avatar_url":"https://avatars1.githubusercontent.com/u/260531?v=4","gravatar_id":"","url":"https://api.github.com/users/mcmanus","html_url":"https://github.com/mcmanus","followers_url":"https://api.github.com/users/mcmanus/followers","following_url":"https://api.github.com/users/mcmanus/following{/other_user}","gists_url":"https://api.github.com/users/mcmanus/gists{/gist_id}","starred_url":"https://api.github.com/users/mcmanus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mcmanus/subscriptions","organizations_url":"https://api.github.com/users/mcmanus/orgs","repos_url":"https://api.github.com/users/mcmanus/repos","events_url":"https://api.github.com/users/mcmanus/events{/privacy}","received_events_url":"https://api.github.com/users/mcmanus/received_events","type":"User","site_admin":false},"created_at":"2017-12-13T20:58:01Z","updated_at":"2017-12-13T20:58:01Z","author_association":"MEMBER","body":"The document doesn't describe how a HTTPS client authenticates HTTPS... that's on purpose in order to simply leverage HTTPS without surprises.\r\n\r\nas a practical matter a number of things can be done. One is TOFU as you suggest. Another is an IP based certificate which you also suggest.\r\n\r\nAnother would be to lookup the name via another, perhaps less trusted resolver, knowing that HTTPS means the IP address isn't part of the security scheme anyhow - its just a route.. subject to blocking, but not to impersonation.\r\n\r\nAnother would be to bootstrap the client with a name _and_ an address instead of one or the other.\r\n\r\nbut as a general matter I think this is one step beyond the scope of the document as its basically writing down the rules for HTTPS."}}
{"actor":{"display_login":"mcmanus"}}