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