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 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
