nusenu wrote:
>
> https works also without names it is just less common.
It's difficult to get a certificate for an IP address.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty, Forth, Tyne: Northwest 5 or 6, backing west 4 or 5,
occasionally 7 at first in Forties. Rough, occasi
On Sat, Mar 23, 2019 at 10:44 PM Kenji Baheux wrote:
>
>
> On Sat, Mar 23, 2019, 13:04 Wes Hardaker wrote:
>
>> Kenji Baheux writes:
>>
>> > * We are considering a first milestone where Chrome would do an
>> automatic
>> > upgrade to DoH when a user’s existing resolver is capable of it.
>
Paul Vixie:> if all you have is an ip address (say, from dhcp or resolv.conf),
how
> would you decide whether the https endpoint you found at that
> address, was using an x.509 key you had any reason to trust? https
> wants names.
https works also without names it is just less common.
Example:
If I'm not mistaken, currently the solution used by at least Cloudflare
bootstraps using traditional DNS as the certificate they are using for DoH
is just a standard X.509 certificate issued by DigiCert. I believe you
could just hardcode both the host and IP address on the client side if you
want t
Wes Hardaker wrote on 2019-03-22 21:03:
Kenji Baheux writes:
* We are considering a first milestone where Chrome would do an automatic
upgrade to DoH when a user’s existing resolver is capable of it.
Sorry for the delayed question, but with respect to this bullet:
1) ...
2) ...
Kenji Baheux writes:
> * We are considering a first milestone where Chrome would do an automatic
> upgrade to DoH when a user’s existing resolver is capable of it.
Sorry for the delayed question, but with respect to this bullet:
1) Do you have evidence that DOH is faster than DOT, since s
On Wed, 13 Mar 2019 at 16:10, Paul Vixie wrote:
> On Wednesday, 13 March 2019 19:23:55 UTC Erik Kline wrote:
> > > If there is a malicious user or app on a network that someone is
> trying to
> > > protect, isn't the very existence of these players the actual issue
> that
> > > needs to be addres
On Wednesday, 13 March 2019 19:23:55 UTC Erik Kline wrote:
> > If there is a malicious user or app on a network that someone is trying to
> > protect, isn't the very existence of these players the actual issue that
> > needs to be addressed?
>
> I tend to think this is the real issue. Any app can
On Wednesday, 13 March 2019 10:20:58 UTC Kenji Baheux wrote:
> On Wed, Mar 13, 2019 at 4:41 PM Paul Vixie wrote:
> > ... can i request that you offer DoT as a
> > solution, not just DoH? they offer the same capabilities of secrecy and
> > authenticity, but DoT can be cheaply disabled by the networ
Kenji Baheux:
>We are considering a first milestone where Chrome would do an automatic
>upgrade to DoH when a user’s existing resolver is capable of it.
Thanks for sharing these insides.
Are you also considering to implement support for this I-D currently in the DoH
WG
(once it is a RFC
>
>
> If there is a malicious user or app on a network that someone is trying to
> protect, isn't the very existence of these players the actual issue that
> needs to be addressed?
>
I tend to think this is the real issue. Any app can craft its own
non-cleartext-DNS name resolution service; DoH m
On Wednesday, 13 March 2019 02:33:14 UTC Kenji Baheux wrote:
> *(Sincere apologies about the multi-posting but the discussion seems to be
> happening in different places...)*
>
>
> Hi,
>
> I'm involved with Chrome's DoH efforts.
>
> ...
>
> PS: I won't be able to join IETF 104 to discuss this
*(Sincere apologies about the multi-posting but the discussion seems to be
happening in different places...)*
Hi,
I'm involved with Chrome's DoH efforts.
I've noticed a few drafts listing concerns about certain types of
deployment for DoH. It appears that the key concerns are based on
assumptio
13 matches
Mail list logo
