On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque <shu...@gmail.com> wrote: > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <vik...@dukhovni.org> > wrote: >> >> >> >> > On Feb 21, 2018, at 11:00 AM, Shumon Huque <shu...@gmail.com> wrote: >> > >> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson >> > <martin.thom...@gmail.com> wrote: >> > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty >> > <kathleen.moriarty.i...@gmail.com> wrote: >> > > What's the behavior when the middlebox is a proxy, let's say existing >> > > a managed network? I presume from from section 3.1 that this >> > > negotiation doesn't work in that instance unless sites configured for >> > > this are not subject to the proxy as is often done for financial site >> > > access from corporate networks. It would be good to know if it does >> > > work and that is addressed with the text Mirja calls out for her #1 >> > > question. Having this clarified could be helpful. >> > >> > If there is a MitM, then this extension simply isn't negotiated. >> > That's pretty well understood. I don't see why that requires special >> > mention. >> > >> > Yeah, I agree Martin .. this is the same as with any other extension. >> >> Actually, I don't think it is quite the same. > > > I meant same in the sense that if any extension is blocked then it > can't be used. What the effect of that is depends obviously on what > functionality the extension is providing. The TLS client can at least detect > such blocking/stripping, and alert the application or fallback to something > else. > > Have other TLS extension specs gone into the details of middlebox > impacts?
This one is a little different though as end users are expecting e2e without interference with this extension. Understanding the behavior is important for administrators and users as Viktor stated. Best regards, Kathleen > >> >> This extension may >> be naïvely expected to provide a different peer authentication >> mechanism than the traditional WebPKI. Users who might expect this >> extension to protect them from WebPKI compromise via DANE TLSA >> records, need to understand that such protection only exists when >> DANE is enforced (mandatory) by the client. >> >> The absence of DANE TLSA records, which is downgrade-resistant >> when the client has access to DNSSEC authenticated denial of >> existence (makes its own DNSSEC lookups) is no longer downgrade- >> resistant when delivered via this extension if the client >> is willing to accept just WebPKI in the (apparent) absence of DANE >> TLSA records. > > > Some of this is already discussed or at least implicit in the draft. > If you want to propose specific text to add or modify, please do so .. > > Shumon. > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
