Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C5C1201F2; Thu, 8 Feb 2018 06:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_b7DJmoEDEi; Thu, 8 Feb 2018 06:33:01 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FB312DA06; Thu, 8 Feb 2018 06:32:56 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id b66so6742330itd.5; Thu, 08 Feb 2018 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I8B9iRc9hcoMiJ404fhj+9KlADYgWbX+M3i1dpMRTLI=; b=EuKzPK2bWgIMVivzsnDP4pOBOgL6s/qTZpcfNlAc1oXN9Dfv5IIkZaC7MZY6/gUaGX JKNwqNJpddYq0OFwymunpbijCz0M5rC0xDwcwKYwiOmioJA/oWf7D+NIVpyXMYnqLpS8 qSspAHjvspKOtbbHkIUAzDrMW4ORsSG4g2RAinui1KCDXYxbE57pHcM8leRxmFwYVJmm IrkM6PnoC+ZCtDLHGMf/JsnIspdk+f1ceXIUfkRmB32ekJqpsS3Ho5bY9Hw90xh2ixcP DS1L/UEGK/KbuSa922xLGxpR28gvEUqLlNExqVGJo6PrThgK/zpae43OJ4/d8pl0SGJG RMBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I8B9iRc9hcoMiJ404fhj+9KlADYgWbX+M3i1dpMRTLI=; b=gXE2IO+vvgTCHs7vddzGi0/NGRnADT3upGaR6CzfKUpPYoyALJnWNims7JI7dJ1z7v WawiybrUTGKZXMt9sAydoBuzWm3jKdPExFtBoGPz7JrPU4/IzNNxg720I1lWPHYppOpv 8oR8FYDTiUWB9ouDowrbsNoTR1QJ+7mpPykieMSckoeEWXbJCGM/ApJhROFwrVKLw3bx IuCoOm/GCrO2JmLetLORJZB0U+ZMhiAPO+WzQPIzXk5v6pwjTkh944oweENcWrq/KMiv aHWqnByiniE0SJ2TgTd8RKVq5t24bPvgYu0EjoxzD9oSbmlCJNgCHsl+0GXtX691FVQF Ygfg== X-Gm-Message-State: APf1xPABIqCa+kaJKUdJcV9wa04QtybVY+YTxt+aJf9QCGR1ouPO4w/6 CQeXS4+K2yyInDBBB+n4Q3CFdwnEF5JLPJnM4PM= X-Google-Smtp-Source: AH8x227nHAG/+0edHYTR/cVZDEyKVzO8mgc/M58UarNlOVXiEbpWkXMebyXOIPTSroowgqsZ8H1LW4SST3Ku0tdNI+U= X-Received: by 10.36.167.67 with SMTP id s3mr1746616iti.66.1518100375782; Thu, 08 Feb 2018 06:32:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 8 Feb 2018 06:32:55 -0800 (PST) In-Reply-To: <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Shumon Huque Date: Thu, 8 Feb 2018 09:32:55 -0500 Message-ID: To: Willem Toorop Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="f403045fb1c8a1ca2e0564b4496d" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:33:05 -0000 --f403045fb1c8a1ca2e0564b4496d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=BChlewind > > wrote: > > > > Mirja K=C3=BChlewind 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 unabl= e > 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 do= ne > > measurements to show this is an actual problem -- for a relatively smal= l > but > > still non-trivial fraction of clients. We'll try to see if we can dig u= p > > 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=C3=B3n, 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. --f403045fb1c8a1ca2e0564b4496d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 8, 2018 at 4:51 AM, Willem Toorop <willem@nlnetlabs.nl> wrote:
Op 08-02-18 om 03:27 schreef= Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind = <ietf@kuehlewind.net
> <mailto:ietf@kuehlewind.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Mirja K=C3=BChlewind has entered the following ball= ot position for
>=C2=A0 =C2=A0 =C2=A0draft-ietf-tls-dnssec-chain-extension-06: No O= bjection
>
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ------------------------
>=C2=A0 =C2=A0 =C2=A0COMMENT:
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ------------------------
>
>=C2=A0 =C2=A0 =C2=A0Two minor, mostly editorial comments:
>
>=C2=A0 =C2=A0 =C2=A01) Intro (sec 2): " It also provides the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0ability to avoid potential problems wi= th TLS clients being unable to
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0look up DANE records because of an int= erfering or broken middlebox on
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the path between the client and a DNS = server."
>=C2=A0 =C2=A0 =C2=A0Is that actually a well-known problem (can you prov= ide a reference?)
>
>
> Some folks (at Google and NLnet Labs if I recall; maybe others) have d= one
> measurements to show this is an actual problem -- for a relatively sma= ll 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 :)=C2=A0 DNSSEC i= s severely
hampered for end-entities by broken infrastructure in many different
ways.=C2=A0 Sometimes an upstream resolver can be used for positive DNSSEC<= br> 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.=C2= =A0


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Gorj=C3=B3n, Xavier Torrent, and Willem Toorop.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Discovery method for a DNSSEC validating = stub resolver."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2015)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://n= lnetlabs.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!

<= div>I think my "relatively small" comment was recalling an earlie= r study (I think by
Google) that saw a breakage of around ~ 5%, b= ut I think that was just measuring
the ability to lookup and obta= in less common RR types and did not measure ability=C2=A0
to perf= orm full DNSSEC validation.

Shumon.

=
--f403045fb1c8a1ca2e0564b4496d--