Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Eric Rescorla <ekr@rtfm.com> Thu, 05 July 2018 02:46 UTC

Return-Path: <ekr@rtfm.com>
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 1CCCE130E79 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 u18yLq2swcZ7 for <tls@ietfa.amsl.com>; Wed, 4 Jul 2018 19:46:55 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (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 EAAD0130D7A for <tls@ietf.org>; Wed, 4 Jul 2018 19:46:54 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id e84-v6so2684668ybb.0 for <tls@ietf.org>; Wed, 04 Jul 2018 19:46:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IMRjQk12YesSxA0vxXtvwU9qteInYgztvxACUxhggGU=; b=owIhrAC54Di0pbZeoiAqohnh+u38slLiS34N0kWaz1VBYOuqbRlPXYZnV6AfUiIFNq esKmcRs4GwPmx6du3rAUGWFV8YInsw8CxqhF5QRVxlo+qwexNyWgoSaOsJzKKxqqRDnP liO9Hl+/4K3EpUDoudHy0CvFMme9JL19roHNc/RxvtGeQsEJgKAesGcxRx5x6bMgyhJ/ Q5SMsBZR+1SQs3w7ebqFGlhUpNN9tZoYfcEj9VQ+5LWO8zL6GItHqUJWenJIAN8L2WLJ cu+T9CVENVUzTgTx0VYXuQOvWsH6b2pIhfOykEQtm0xjZQa7ec7v7zqmoP/hfHBLNKZ5 51ag==
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; bh=IMRjQk12YesSxA0vxXtvwU9qteInYgztvxACUxhggGU=; b=aHt/TFM+hqIQnOBBAbDt0Zaxbpz/LEQsg3b6kxrGY/qbXxkR27SkKLUMqsXWYK5g20 FLfX4kykFeLs350BfHuy/ZkF+QEyRtC4frfEP6eU+1u2W3jHKKw4QJrGIidSbrK3OZVv mqAYYUPnIOAuDo492jg1uFVjAAEbi34WwQji+5EPp6u45h90Y44wD4p0XUdn7k/6AlQQ XjhwIpaHUMkAEAABVphlLOCl4PZ5cZrAk/WgNyBga1M8Rg90uvSO2GryyYC3+pBGxt9U gqvO7rTU3y2YyIPrlkl6rz4EcH5dgaebSVHn4ERDsEGEUBzLQoGCXhenfSBzKxo4kxYB H6XQ==
X-Gm-Message-State: APt69E2r+iUwqOKO1ZWY1dYM+DLKuCGnZXlq4oNqli5o9CLqpjwyUoIa N48JB0gGUkIxOaqJHw4cNwWRe5cuFKCcI2SyD4X2gcSx
X-Google-Smtp-Source: AAOMgpeF4wXFNk+LBYwvilDPQ2fvhojKtmz5O/7XDFumBYw/gkTlYfSulOVK6N2wImsoaifV9JxSac8/vRYo8/3g3ak=
X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr2319734ybe.73.1530758813671; Wed, 04 Jul 2018 19:46:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 19:46:13 -0700 (PDT)
In-Reply-To: <20180705023310.GL85096@straasha.imrryr.org>
References: <20180604203947.GW13834@akamai.com> <alpine.LRH.2.21.1806050858340.8057@bofh.nohats.ca> <CAOgPGoBPfL46ogCGa4tSA2q9dikuTwrY766R5y3U-DD1k+XudQ@mail.gmail.com> <CABcZeBOQ0AueZup+sLbK1g2nJ_GUP5Oq+pzRaKmQ0y=Foa4-MA@mail.gmail.com> <20180705023310.GL85096@straasha.imrryr.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 4 Jul 2018 19:46:13 -0700
Message-ID: <CABcZeBMDKeYM_jnB+2hNREHOLNwOpMAfm1E69hbGdmZMFBCMRw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005379520570378f5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wPxMHYUW3o5daeMP3pFDFlBJVpg>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 02:46:57 -0000

On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>;
wrote:

> On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:
>
> > > 1.  Do you support the working group taking on future work on a pinning
> > > mechanism (based on the modifications or another approach)?
> >
> > Unsure. I'd like to see some real evidence that it will be widely
> consumed.
> > Do we have a count of major implementors who say they will do so?
>
> Well, what is a "major implementation"?


Well, we could start with "what implementations are going to do this"?


> No. I'm undecided on whether we should have an extension point here, but
> > I'm strongly against having it just be opaque reserved bytes. Everywhere
> > else we have decided to put extension points, we've had them as
> Extensions,
> > not just "here are some bytes".  Aside from this being general TLS
> > practice, it is good futureproofing because one can grease Extensions,
> > whereas you cannot grease opaque bytes.
>
> It is far from clear why "grease" is applicable here, or what "grease
> barriers" either proposed form of the reserved field presents.
>
>     * With the 16-bit field, servers set it to zero until non-zero
>       values are specified.
>

>     * With the <0..255> byte value, servers send an empty value
>       until non-empty values are specified.
>

    * In either case clients ignore either non-zero or non-empty
>       values, until they implement the specification, and must not
>       employ pinning until such time.
>

Yes, and this is where grease comes in. Specifically, if implementations
are required to send empty values (or zero) until something is specified,
then implementations which *require* those values and choke otherwise go
undetected. By contrast, if we have a structured Extension code point with
requirements to ignore unknown extensions, then implementations can send
grease extension values and verify that the peer properly ignores them. In
any case, as Martin Thomson says, we have a perfectly good extension
mechanism which can be used to add pinning later without creating any
placeholder here.

I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished.


Well, I'm not an author, so I'm the wrong person to be addressing this to.


If we're no
> longer in a hurry to get this out the door before all the issues
> are sorted out, we can specify the downgrade protection now, in
> which case there's no need for reserved fields, we can define the
> pinning approach now.
>

That would first require there being consensus to do pinning.

-Ekr