Re: [TLS] Two Multi-CDN proposals

Eric Rescorla <ekr@rtfm.com> Thu, 28 February 2019 14:19 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 B707E130EC3 for <tls@ietfa.amsl.com>; Thu, 28 Feb 2019 06:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 76iBGVYCcS7U for <tls@ietfa.amsl.com>; Thu, 28 Feb 2019 06:19:04 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 4F5D2130F1E for <tls@ietf.org>; Thu, 28 Feb 2019 06:19:03 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id l5so17297650lje.1 for <tls@ietf.org>; Thu, 28 Feb 2019 06:19:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u1Tlgfzn1R14SZbrfuLeHXk62cAwxFI/q9ZwN7Hg/P0=; b=kbpuV+icqJYVvqDoFo+CudWn2zfOicOLqCaCu18H+feU2+6v/7/JOosJFK4dOa4hLL Oh4TVBu7klDIN5T/qd+zLZTBL7F9Spzjq0TIxR6pRqMdv5P88rXhr8vxtHToPBJFdw16 YFckMPEflo/Kv0ZUdV6RWEFUcjyRLCCd1KA3OWxHwCOfe3l6ANQzQStm+55BdxDHl9yg JIwN9MMvBQDvky35Cjd7VnyJdZa94UOaiCRhpdoZpzn8MMjk9KkYfJOOKbx3GwzVByKu zefk36ElmujvknDx2XJHq4HeUN63YsB0j+NsAtT4bOI6Se9qeLSFe/zK3805lPJ8xZqz MXsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u1Tlgfzn1R14SZbrfuLeHXk62cAwxFI/q9ZwN7Hg/P0=; b=BkftdsG5vmWXRXhRE+I35wurVLAg5XGjSXjGJKSrwpVeS6FfiDeX1S+TRh4kgXpTxF z09geP2JLDwZexCQqtGOiOLdIEA719AYggvYIfUGsDtfucZQelaWTdIa2V82wGgsmiF8 2lfdXBSXweAxsWq4SrSfw/Om8+Jn9VSnbtqDW5Lk+gxr5gbNpuE6+lv7aZ5JVwDNTFxF 0KTLwzI73dIS5bWJz7Hi6FFpAAupKz4JPFjSgnARRx286tYz8adqVa8SRihsxmA6q7bT A4lfU+sh8GQEMc7M4U6zwh/ZwvtG2A9ruqhNq6EMpgZ0aQEBvnQ1ffgCZC9halBOmrA+ oCQQ==
X-Gm-Message-State: AHQUAuadA0hdLDkyaGq89ofpm8cZthhX9JCAk3/GgnHli9oJvCcw9TJG KsCDYIM800yJHXoPP8IlztlnmbBYvBChbeF4ajkAC9KA
X-Google-Smtp-Source: APXvYqzM9FQvO7fwooVgPDZLp88FQGICcl6pCosqS9koSlTamF5sxtpytZ2KJLWpc/SecjZpAPgrKbqYhAeR3BEbv4w=
X-Received: by 2002:a2e:965a:: with SMTP id z26mr4408120ljh.59.1551363541419; Thu, 28 Feb 2019 06:19:01 -0800 (PST)
MIME-Version: 1.0
References: <CAO8oSX=sPoLo78oX4qEEyeuck7CxM_uAqYPHEsY7BuYqBUaorg@mail.gmail.com> <0b19d021-8101-23ee-2899-450d103a8906@cs.tcd.ie> <CABcZeBN0mf7VFCKKdg9gH0=tCS7eLZz6M5_WJdaNG7XrJeyESw@mail.gmail.com> <0b854704-8f93-f9ad-c067-67f7f73cbbbf@cs.tcd.ie> <CABcZeBM61u=DtjQh+NkQF47MLyZS4EyuGBjDnsfjxz-z5kfjoQ@mail.gmail.com> <1eaaebf3-6e8a-ae84-0ab3-f977295c0721@cs.tcd.ie> <CABcZeBMeiCa8CGqab9cUH0ydOqBJKcALuA41ToAjJ1qFirrtDQ@mail.gmail.com> <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie>
In-Reply-To: <99af33f1-81d0-d918-9746-568d6ad0c1f0@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Feb 2019 06:18:23 -0800
Message-ID: <CABcZeBNVVQ4GEsr7LM+0osbtugLRrF8UW+6eX-WH4UDu32UKNA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Christopher Wood <christopherwood07@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cde2220582f4f855"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MtHu-_v5WG2CUdl0wXfyvXq7bYk>
Subject: Re: [TLS] Two Multi-CDN proposals
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Feb 2019 14:19:18 -0000

On Thu, Feb 28, 2019 at 5:51 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 28/02/2019 13:12, Eric Rescorla wrote:
> >> That's what leads me to think that we'd be better off
> >> to have multi-valued answers when a browser looks up
> >> the RRset at _esni.www.example.com with each separate
> >> value matching one ESNI public share (or one CDN,
> >> though I'd argue for one share per zone file stanza).
> >>
> > I don't really understand your point, because this *is* the expected
> > design.
> >
>
> Seems one of us is confused then, likely me:-)
>
> Lemme try clarify it out this way:
>
> $ dig +short txt _esni.cloudflare.com
> "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT
> C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX
> HPm0AAAAABce8/QAAA="
>
> That's one encoded ESNIKeys value accessed just now.
>
> The ietf.org domain has two TXT RR values, (actual content
> elided below for brevity) so I get:
>
> $ dig +short txt ietf.org
> "somegooglestuff"
> "lotsofspfstuff"
>
> What I'd like to see for my earlier example.com case would
> be like:
>
> $ dig +short txt _esni.www.example.com
> "/wEXMtleACQAHQAgsKfk/Hy67PiJCb68AVrT
> C5jXkYnJK5UKCHcF4BAojAwAAhMBAQQAAAAAX
> HPm0AAAAABce8/QAAA="
> "/wHHBBOoACQAHQAg4YSfjSyJPNr1z3F8KqzB
> NBnMejim0mJZaPmria3XsicAAhMBAQQAAAAAW
> 9pQEAAAAABb4jkQAAA="
>
> Where the first is supplied to me by cdn1.example and the
> second is from cdn2.example.
>

> And have browsers and other ESNI clients be able to handle
> that, picking whatever they consider the best of the usable
> options presented.
>

My understanding is that this is problematic for DNS reasons, namely that
you are supposed to concatenate the records, and that we definitely need a
way to go above 255 bytes. But I'm no DNS expert and if there's a way to
have both of these, then I have no problem with it.


(And assuming we are: I'd subsequently suggest we can
> simplify ESNIKeys so that it just has one KeyShareEntry per
> RR value and not a list of those, since multiples for one
> CDN or many CDNs can be handled already as above.


Yes, I believe you've made this suggestion before, and I opposed it for the
same reason I oppose it now. While technically possible, it requires you to
duplicate everything else in the entry, which is bad, and worse the more
other stuff you put in the record (for instance, the public name).

-Ekr


I think
> making that change, and perhaps other simplifying changes,
> at the same time as moving from TXT to a new RRTYPE would
> be a fine thing, but there's no pressing need to make all
> those changes for the -03 draft or in #137 though, I'd be
> happy if we're heading there a little later.)
>
> Cheers,
> S.
>