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

[Shumon Huque]

On Thu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni 
wrote:
>
>
> My comments are less about middleboxes (TLS-terminating corporate
> proxies trusted by the user's browser) and more about unwanted
> active MiTM attacks.  If the MiTM attacker has obtained WebPKI
> (PKIX) certificates for the destination, then this new extension
> will not protect the user even when the destination has TLSA
> records, because the server can deny their existence (not offer
> the extension) without proof.
>
> What makes this case different is that the naïve mental model
> of what it offers is support for DANE-based peer authentication
> equivalent to doing the DNSSEC lookups on the client end, but
> with DNSSEC tunneled via the server.
>
> Therefore, some text is probably warranted to disabuse the reader
> of such a naïve view.  What one gets with this extension, in the
> more typical cases in which DANE is not "mandatory", is not
> equivalent to enforcing DANE when it is published by the peer.
> Rather, what one gets is the ability to use DANE to authenticate
> sites that one might not otherwise be able to authenticate (no
> shared WebPKI trust-anchor).
>

Yes, I agree that some elaboration on this limitation of the protocol
is useful. In case you missed it, I do actually document the limitation
quite explicitly in Section 8, which I'll excerpt here:

   "This protocol currently provides no way for a server to prove that it
   doesn't have a TLSA record.  Hence absent whitelists, a client
   misdirected to a server that has fraudulently acquired a public CA
   issued certificate for the real server's name, could be induced to
   establish a PKIX verified connection to the rogue server that
   precluded DANE authentication.  This could be solved by enhancing
   this protocol to require that servers without TLSA records need to
   provide a DNSSEC authentication chain that proves this (i.e. the
   chain includes NSEC or NSEC3 records that demonstrate either the
   absence of the TLSA record, or the absence of a secure delegation to
   the associated zone).  Such an enhancement would be impossible to
   deploy incrementally though since it requires all TLS servers to
   support this protocol."

But perhaps it needs to feature more prominently in the document
rather than being buried in the context of a discussion about mandating
the use of this extension. The limitation exists independent of whether
a TLS application is trying to mandate things.

My suggestion is to move this discussion to the beginning of the
Security Considerations section, and then adding some of your
elaborating points, including a direct comparison with clients querying
DANE records themselves. It might also be worth a brief mention in the
Intro section that the protocol lacks authenticated denial and pointing
the reader/implementer to the Security Considerations section for more
details.

Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

> On Feb 22, 2018, at 10:59 AM, Shumon Huque  wrote:
> 
 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?

My comments are less about middleboxes (TLS-terminating corporate
proxies trusted by the user's browser) and more about unwanted
active MiTM attacks.  If the MiTM attacker has obtained WebPKI
(PKIX) certificates for the destination, then this new extension
will not protect the user even when the destination has TLSA
records, because the server can deny their existence (not offer
the extension) without proof.

What makes this case different is that the naïve mental model
of what it offers is support for DANE-based peer authentication
equivalent to doing the DNSSEC lookups on the client end, but
with DNSSEC tunneled via the server.

Therefore, some text is probably warranted to disabuse the reader
of such a naïve view.  What one gets with this extension, in the
more typical cases in which DANE is not "mandatory", is not
equivalent to enforcing DANE when it is published by the peer.
Rather, what one gets is the ability to use DANE to authenticate
sites that one might not otherwise be able to authenticate (no
shared WebPKI trust-anchor).

The main exception to this limitation is that once DANE TLSA
records are obtained and cached (assuming there's a cache),
then they may protect against downgrade to PKIX-along for the
TTL of the previously obtained records, and if the cache is
"refreshed" periodically (prior to expiration) by a client
that continues to communicate with the server frequently
over newly negotiated connections, then it becomes difficult
for an MiTM to downgrade the communication to strip the DANE
TLSA extension, unless the MiTM certificates are stolen directly
from the server (rather than obtained fraudulently for a new key
controlled by the attacker).

The above exception will not be typical, so this extension is
useful to support DANE-TA(2)/DANE-EE(1) certificate usages, but
does not (when not mandatory) support PKIX-TA(0)/PKIX-EE(1), because
authenticated denial of existence is lost.

If some day (a decade or more from now if and when it is nearly
universally implemented by servers) the extension is made mandatory,
and requires authenticated denial of existence (or proof that the
server's domain is not signed), THEN it would reach parity with
direct DNSSEC lookups by the client, and its purpose would be
latency reduction, rather than overcoming DNSSEC opaque captive
portals...

-- 
-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Thu, Feb 22, 2018 at 11:17 AM, Shumon Huque  wrote:
> On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty
>  wrote:
>>
>> On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque  wrote:
>> > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni 
>>
>> >
>> > 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
>
>
> Okay Kathleen.
>
> We'll add some discussion on this. Viktor - I assume you'll help with text.

Thank you!

>
> Shumon.
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Shumon Huque]

On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque  wrote:
> > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni 
>
> >
> > 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
>

Okay Kathleen.

We'll add some discussion on this. Viktor - I assume you'll help with text.

Shumon.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

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

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

[Shumon Huque]

On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni 
wrote:

>
>
> > On Feb 21, 2018, at 11:00 AM, Shumon Huque  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
> >  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

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

[Viktor Dukhovni]

> On Feb 21, 2018, at 11:00 AM, Shumon Huque  wrote:
> 
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson  
> wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>  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

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

[Kathleen Moriarty]

On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque  wrote:
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson 
> wrote:
>>
>> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>>  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.

OK, I think it is clear in the discussion with 1.2, but wasn't sure if
it was clear enough elsewhere and figured it was best to ask.
>
> Shumon.
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Shumon Huque]

On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson 
wrote:

> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>  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.

Shumon.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kathleen Moriarty]

On Thu, Feb 8, 2018 at 9:32 AM, Shumon Huque  wrote:
> On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop  wrote:
>>
>> Op 08-02-18 om 03:27 schreef Shumon Huque:
>> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > > > wrote:
>> >
>> > Mirja Kühlewind has entered the following ballot position for
>> > draft-ietf-tls-dnssec-chain-extension-06: No Objection
>> >
>> >
>> > --
>> > COMMENT:
>> >
>> > --
>> >
>> > Two minor, mostly editorial comments:
>> >
>> > 1) Intro (sec 2): " It also provides the
>> >ability to avoid potential problems with TLS clients being unable
>> > to
>> >look up DANE records because of an interfering or broken
>> > middlebox on
>> >the path between the client and a DNS server."
>> > Is that actually a well-known problem (can you provide a reference?)
>> >
>> >
>> > Some folks (at Google and NLnet Labs if I recall; maybe others) have
>> > done
>> > measurements to show this is an actual problem -- for a relatively small
>> > but
>> > still non-trivial fraction of clients. We'll try to see if we can dig up
>> > specific
>> > references to documents that could be cited.
>>
>> I wouldn't call it a relatively small fraction :)  DNSSEC is severely
>> hampered for end-entities by broken infrastructure in many different
>> ways.  Sometimes an upstream resolver can be used for positive DNSSEC
>> answers (i.e. existing records), but not for non-existent or wildcard
>> answers, because it simply doesn't forward the NSEC(3) proof for it.
>>
>>
>>
>> The last measurements we at NLnet Labs did was in July 2015:
>>
>> Gorjón, Xavier Torrent, and Willem Toorop.
>> "Discovery method for a DNSSEC validating stub resolver."
>> (2015)
>>
>> https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf
>>
>> Measurements were done with RIPE Atlas, with at the time +-8200 probes.
>> At the time only 56% of probes received enough DNSSEC data from their
>> upstreams to be able to perform DNSSEC validation for both positive and
>> non-existent answers (required for DANE).
>
>
> Ah, thanks. I'd forgotten that it was so high!
>
> I think my "relatively small" comment was recalling an earlier study (I
> think by
> Google) that saw a breakage of around ~ 5%, but I think that was just
> measuring
> the ability to lookup and obtain less common RR types and did not measure
> ability
> to perform full DNSSEC validation.

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.

Thanks.

>
> Shumon.
>



-- 

Best regards,
Kathleen

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Shumon Huque]

On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop  wrote:

> Op 08-02-18 om 03:27 schreef Shumon Huque:
> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  > > wrote:
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-tls-dnssec-chain-extension-06: No Objection
> >
> > 
> --
> > COMMENT:
> > 
> --
> >
> > Two minor, mostly editorial comments:
> >
> > 1) Intro (sec 2): " It also provides the
> >ability to avoid potential problems with TLS clients being unable
> to
> >look up DANE records because of an interfering or broken
> middlebox on
> >the path between the client and a DNS server."
> > Is that actually a well-known problem (can you provide a reference?)
> >
> >
> > Some folks (at Google and NLnet Labs if I recall; maybe others) have done
> > measurements to show this is an actual problem -- for a relatively small
> but
> > still non-trivial fraction of clients. We'll try to see if we can dig up
> > specific
> > references to documents that could be cited.
>
> I wouldn't call it a relatively small fraction :)  DNSSEC is severely
> hampered for end-entities by broken infrastructure in many different
> ways.  Sometimes an upstream resolver can be used for positive DNSSEC
> answers (i.e. existing records), but not for non-existent or wildcard
> answers, because it simply doesn't forward the NSEC(3) proof for it.


>
> The last measurements we at NLnet Labs did was in July 2015:
>
> Gorjón, Xavier Torrent, and Willem Toorop.
> "Discovery method for a DNSSEC validating stub resolver."
> (2015)
>
> https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf
>
> Measurements were done with RIPE Atlas, with at the time +-8200 probes.
> At the time only 56% of probes received enough DNSSEC data from their
> upstreams to be able to perform DNSSEC validation for both positive and
> non-existent answers (required for DANE).
>

Ah, thanks. I'd forgotten that it was so high!

I think my "relatively small" comment was recalling an earlier study (I
think by
Google) that saw a breakage of around ~ 5%, but I think that was just
measuring
the ability to lookup and obtain less common RR types and did not measure
ability
to perform full DNSSEC validation.

Shumon.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Willem Toorop]

Op 08-02-18 om 03:27 schreef Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  > wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: No Objection
> 
> --
> COMMENT:
> --
> 
> Two minor, mostly editorial comments:
> 
> 1) Intro (sec 2): " It also provides the
>    ability to avoid potential problems with TLS clients being unable to
>    look up DANE records because of an interfering or broken middlebox on
>    the path between the client and a DNS server."
> Is that actually a well-known problem (can you provide a reference?)
> 
> 
> Some folks (at Google and NLnet Labs if I recall; maybe others) have done
> measurements to show this is an actual problem -- for a relatively small but
> still non-trivial fraction of clients. We'll try to see if we can dig up
> specific
> references to documents that could be cited.

I wouldn't call it a relatively small fraction :)  DNSSEC is severely
hampered for end-entities by broken infrastructure in many different
ways.  Sometimes an upstream resolver can be used for positive DNSSEC
answers (i.e. existing records), but not for non-existent or wildcard
answers, because it simply doesn't forward the NSEC(3) proof for it.


The last measurements we at NLnet Labs did was in July 2015:

Gorjón, Xavier Torrent, and Willem Toorop.
"Discovery method for a DNSSEC validating stub resolver."
(2015)

https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf

Measurements were done with RIPE Atlas, with at the time +-8200 probes.
At the time only 56% of probes received enough DNSSEC data from their
upstreams to be able to perform DNSSEC validation for both positive and
non-existent answers (required for DANE).


There is a RFC that outlines detection and mitigation techniques on how
to deal with this from DNSSEC validation stub resolvers:

RFC8027  -  DNSSEC Roadblock Avoidance

Ultimately such a stub resolver has to be able to fallback to full
recursive resolving (i.e. iterating from the root).  Although even that
might fail...


Furthermore, hampered DNS (but not specifically DNSSEC), is the primary
motivation for the new DNS over HTTPS draft (and workgroup):

https://tools.ietf.org/html/draft-ietf-doh-dns-over-https

(DoH might be the ultimate final fallback in DNSSEC Roadblock Avoidance)

> 
> or would
> it be enough to say something like this: " It also provides the
>    ability to avoid potential problems with TLS clients being unable to
>    look up DANE records when DNS server is not reachable."
> 
> 
> Your rewording of this sentence would unfortunately not be accurate.
> It's usually not the DNS server that is unreachable, but that some middlebox
> has done something wrong, such as: not allow DANE queries or responses 
> through; not allow DNSSEC signatures through; not allow EDNS options
> that enable DNSSEC through, or engage in other misbehavior.
> 
> 
> 2) IANA Considerations should probably be updated.
> 
> 
> I guess you are suggesting that the last sentence is probably obsolete:
> 
>     "If the draft is adopted by the WG, the authors expect to make an
>      early allocation request as specified in [RFC7120]."
> 
> Agreed. It's a little late for that! :-)
> 
> We will remove it.
> 
> Shumon Huque
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Shumon Huque]

On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: No Objection
>
> --
> COMMENT:
> --
>
> Two minor, mostly editorial comments:
>
> 1) Intro (sec 2): " It also provides the
>ability to avoid potential problems with TLS clients being unable to
>look up DANE records because of an interfering or broken middlebox on
>the path between the client and a DNS server."
> Is that actually a well-known problem (can you provide a reference?)


Some folks (at Google and NLnet Labs if I recall; maybe others) have done
measurements to show this is an actual problem -- for a relatively small but
still non-trivial fraction of clients. We'll try to see if we can dig up
specific
references to documents that could be cited.

or would
> it be enough to say something like this: " It also provides the
>ability to avoid potential problems with TLS clients being unable to
>look up DANE records when DNS server is not reachable."
>

Your rewording of this sentence would unfortunately not be accurate.
It's usually not the DNS server that is unreachable, but that some middlebox
has done something wrong, such as: not allow DANE queries or responses
through; not allow DNSSEC signatures through; not allow EDNS options
that enable DNSSEC through, or engage in other misbehavior.


> 2) IANA Considerations should probably be updated.
>

I guess you are suggesting that the last sentence is probably obsolete:

"If the draft is adopted by the WG, the authors expect to make an
 early allocation request as specified in [RFC7120]."

Agreed. It's a little late for that! :-)

We will remove it.

Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls