Please see inline From: Eric Rescorla <e...@rtfm.com> Sent: Tuesday, March 12, 2019 9:28 PM To: Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com> Cc: d...@ietf.org; dnsop@ietf.org; dns-priv...@ietf.org; Vittorio Bertola <vittorio.bertola=40open-xchange....@dmarc.ietf.org>; Stephen Farrell <stephen.farr...@cs.tcd.ie> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. ________________________________ On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>> wrote: Hi Eric, In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and white-list, black-list and grey-list TLS session based on the server identity. In other words, middleboxes are conditionally acting as TLS proxies to specific servers (categorized in the grey-list). With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS proxy for all the flows. It would be most useful not to conflate TLS 1.3 and ESNI. In ordinary TLS 1.3, the SNI is in the clear but the server cert is not. However, importantly, even in TLS 1.2, the server certificate is not verifiable, and therefore is not significantly more trustworthy than SNI. [TR] Middle boxes have a trust store (e.g. downloaded from Mozilla CA store) to validate the server certificate. Malwares lie about SNI (typically use a FQDN whose reputation score is good), validating the server certificate (e.g. certain types of malwares use self-signed certificates) and SNI mismatch helps detect the client is lying. With ESNI, the SNI is encrypted (hence the name). However, the xpectation is that enterprises which want to do conditional inspection will disable ESNI on the client. This should not be problematic as they already need access to the client to install their own trust anchor. [TR] I see Firefox has given an option to disable ESNI, hopefully others will provide a configurable option. Cheers, -Tiru -Ekr -Tiru From: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Sent: Tuesday, March 12, 2019 3:14 AM To: Paul Vixie <p...@redbarn.org<mailto:p...@redbarn.org>> Cc: nalini elkins <nalini.elk...@e-dco.com<mailto:nalini.elk...@e-dco.com>>; Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>>; d...@ietf.org<mailto:d...@ietf.org>; dnsop@ietf.org<mailto:dnsop@ietf.org>; Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>; Christian Huitema <huit...@huitema.net<mailto:huit...@huitema.net>>; dns-priv...@ietf.org<mailto:dns-priv...@ietf.org>; Vittorio Bertola <vittorio.bertola=40open-xchange....@dmarc.ietf.org<mailto:40open-xchange....@dmarc.ietf.org>>; Stephen Farrell <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. ________________________________ On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie <p...@redbarn.org<mailto:p...@redbarn.org>> wrote: nalini elkins wrote on 2019-03-11 10:26: > Tiru, > > Thanks for your comments. > > > Enterprise networks are already able to block DoH services, i wonder if everyone here knows that TLS 1.3 and encrypted headers is going to push a SOCKS agenda onto enterprises that had not previously needed one, I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3 doesn't generally encrypt headers any more than TLS 1.2 did, except for the content type byte, which isn't that useful for inspection anyway. Are you perchance referring to encrypted SNI? Something else? -Ekr and that simply blocking every external endpoint known or tested to support DoH will be the cheaper alternative, even if that makes millions of other endpoints at google, cloudflare, cisco, and ibm unreachable as a side effect? CF has so far only supported DoH on 1.1.1.0/24<http://1.1.1.0/24> and 1.0.1.0/24<http://1.0.1.0/24>, which i blocked already (before DoH) so that's not a problem. but if google decides to support DoH on the same IP addresses and port numbers that are used for some API or web service i depend on, that web service is going to be either blocked, or forced to go through SOCKS. this will add considerable cost to my network policy. (by design.) -- P Vixie _______________________________________________ Doh mailing list d...@ietf.org<mailto:d...@ietf.org> https://www.ietf.org/mailman/listinfo/doh
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
