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>
>> > 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
> Have other TLS extension specs gone into the details of middlebox
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.
>> 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 ..
TLS mailing list