Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque <[e-mail]> wrote:
> On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <[e-mail]>
> wrote:
>>
>>
>>
>> > On Feb 21, 2018, at 11:00 AM, Shumon Huque <[e-mail]> wrote:
>> >
>> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
>> > <[e-mail]> wrote:
>> > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>> > <[e-mail]> 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