Re: [TLS] draft-ietf-tls-esni feedback

Patrick McManus <mcmanus@ducksong.com> Mon, 21 October 2019 23:59 UTC

Return-Path: <mcmanus@ducksong.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 B5774120A7A for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 16:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=p1lNislE; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=o128HcHS
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 kkTX0wwFRzTX for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 16:58:57 -0700 (PDT)
Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44AD120A79 for <tls@ietf.org>; Mon, 21 Oct 2019 16:58:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1571702337; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=qlawPSB75ZySZkWhcG55KylXFhYCzPV4v2weuFhsY6B/UNYfcirWWWfZ0We7VzBqVm7XnjHDpZPE2 R0WJXEG1TaUt1HJWYrPAZSFAZxI1ot5dP6+0DT/1MstsGSKUrOjXXo2lpouAbcN/2CXpt0C6R2RrWV o/KgAp8JFTeU0YZIpiW0jR8jdxucG+Jp2H7O+GDk9UT3kAHIDdorvYaEQjMmfSoBtKmegr05JNl30W n08695Bz8TrnJZRMM1VsEz8iH3ZKuv3QOek7yervRV4OLM0lx+urYQJE3Wxohl6NsTAEOMRQQxHKTq LZMdvaxn2nmq7gecGl+52Vy7775UfOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=gnDyATmcrXhja58vxor0tvUqWDc6S8CJQ5DzXFOTRdze+R+Ig7FfkTZcypONf+s3uEEdhxfthlQcL V/+QvPlsnQSD0UfzOydal3sbxvw+nRNOT2W8QLZuZ3llQG1Et+8h/J8a66GkHAkErxJEpFVp38sexx N6Ss7JGL6klWIef9EbgGsAJTdsttv5Lf2xhdMtBxvZwwHu0JjKR8o0y5R+v+DLyZWS469Fd3BVFYvJ UycE1jM+0kX+OJRzY+pLgwFOL5yK3HOVnKtRKzg87NUEgRQUTevpzAM53ll6cA6vXxREXlBFchYuM+ BoXH0JoADyOR6+XvvuMGBeCypc6ctAg==
ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.50; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=p1lNislEyuUrvoOdvP8NoUPI4Q6S5F9sfRfaOGoe4oNi77ggIN+kFWPrQZk1QZNP+M5520r2UwgPl Xgb5QiQcdtPUP9FBi1JJo3/k/4O4OK4RouubDMFvVdlPhoVaRt+LDl0bAVX4YA99MWCuzXewBp1vSA nB8SaPTFSy9Ki6i0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=o128HcHSfyrFtnCWDhUtARiCLokccge/ki9wTBWTLkA9zF3967HWTjsOB+uUhxH/Ry9S2QGPTMqCA r30WltSmnKyKWK6VFTpqW7DY+smK83W3OcjEWcK7OBPdoccuXJNpgfTwoYHkm3KeTHeHA0c3oovzUt eIJU7u3WfHEA47kHWXPaeNaF4wRvkruJcKsteUk+Uzs4GEPLB7DPyyGKeDEuApKeeKE+cfA8/kR1Jk Q9AEUiHgDzCntqgnS36kYVp7ANN3Ex+2oAT4l92Fr8Kzn2bHCWloqYbAKnJOE6QuTDNsMZ4HF9N6Fe 33LHDyTQcJiQhxP9x4CY4RJjqusYJ4w==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: bd103ce7-f45e-11e9-9560-dfabc1efb494
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.210.50
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-ot1-f50.google.com (unknown [209.85.210.50]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id bd103ce7-f45e-11e9-9560-dfabc1efb494; Mon, 21 Oct 2019 23:58:55 +0000 (UTC)
Received: by mail-ot1-f50.google.com with SMTP id c7so1843689otm.3 for <tls@ietf.org>; Mon, 21 Oct 2019 16:58:55 -0700 (PDT)
X-Gm-Message-State: APjAAAVd4hkAiZ7iJI+P2paoeXodk6Pet3Vg49Me6Xc85It1F9KRWqUQ SMQwFdME6km8pto5+wBXbjOc98KP1CSsnFIu+FQ=
X-Google-Smtp-Source: APXvYqxGxI5tya9RYSzcigElBIjchx7tiRJRUF9OWy9Ok4cQYzcQscBtHZGx2RUO2KajkG81sZVcqJX/SBYnZ8WtFPI=
X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr386087otr.289.1571702334519; Mon, 21 Oct 2019 16:58:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sw3f7du3JYxfcWSZje1zjDzsRBQyDjob-AvzjWeZzKW7g@mail.gmail.com> <CABcZeBPbw_KOo_ieSqkksYPeLtb9DufBz628oFPYc_Ue4S9iww@mail.gmail.com> <CAChr6SwB+7Jt2TLJSQh3q=Roizdt2=9jCBa9nq8KRxRo=86uZQ@mail.gmail.com> <CABcZeBNBtDK7q175tseEUiCVds=khj4xXYJZRf7GU9VGNDJ_Tg@mail.gmail.com> <CAChr6Sz6xHtFWjOKrLp3sp9MpC-SoU9Sx=vk22ditjShA7B=Kg@mail.gmail.com> <CABcZeBOnE+gyNu7GarAfO0bptoPfzQQ=VKeWLdpJBDM=E4yhzg@mail.gmail.com> <CAChr6SxWE66jPRbnBRtwNSn3L+uNFkoFBbYNOBAkKDN05qotoA@mail.gmail.com> <CABcZeBOy8ogJrmFajxX1pqjqgnE61gE=c3CWz+pp34NWHmGKbw@mail.gmail.com> <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <CABcZeBMquubsGvt8UssiyFU_ZuQK67rHN_KBXY+iKSNayJFZew@mail.gmail.com> <d9402fe2-2ab3-f60f-c478-dc1df5bd4402@cs.tcd.ie> <CABcZeBNC9YBGMs0b84DFDB-FU7fKXpzX+HP1H5KRcjYJ7kXr3w@mail.gmail.com> <c7ada021-1ccf-1dc5-d7e3-a5f893f116ee@cs.tcd.ie> <CABcZeBO09MKms7tG40NDy-wRz26eXzKvyJqSYK1K5fEJBzcE3Q@mail.gmail.com>
In-Reply-To: <CABcZeBO09MKms7tG40NDy-wRz26eXzKvyJqSYK1K5fEJBzcE3Q@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 21 Oct 2019 19:58:41 -0400
X-Gmail-Original-Message-ID: <CAOdDvNrhTUxMojbNj08bwHN4y=yM3qifgnTjG07jyE4mMex7rg@mail.gmail.com>
Message-ID: <CAOdDvNrhTUxMojbNj08bwHN4y=yM3qifgnTjG07jyE4mMex7rg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000057826f05957477bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YZCYMsvnBztXGMjPDddjfDw_eZY>
Subject: Re: [TLS] draft-ietf-tls-esni feedback
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: Mon, 21 Oct 2019 23:59:01 -0000

wildcards are real in both dns and http services.. (also the dns entries
might be invisible to the http provider thanks to cname indirections..
though obviously service names are not.)

On Mon, Oct 21, 2019 at 4:56 PM Eric Rescorla <ekr@rtfm.com>; wrote:

>
>
> On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
> wrote:
>
>>
>> Hiya,
>>
>> On 21/10/2019 21:02, Eric Rescorla wrote:
>> >> Sure, but the point holds though. If ESNIKeys are changed every
>> >> N seconds, and any new certificate is loaded during that time,
>> >> then the server operator can't tell the lengths that the CAs
>> >> might produce in future. So with the current design 260-always is
>> >> the only thing a server-operator (or really an ESNIKeys generator
>> >> who may be a slightly different entity) can rely on in general.
>> >>
>> > I don't believe that this claim is correct in general. Remember that
>> these
>> > records are stored in the DNS under the name that becomes the SNI, so,
>> > absent wildcards, ths eet of names is in fact known, regardless of what
>> > happens to be in the certificate.
>>
>> Depends which "in general" is more general I guess.
>>
>> Wildcards do exist in the DNS, though TBH I'm not really
>> familiar with how they're implemented in authoritatives.
>>
>> But even ignoring those, deployment models where the
>> ESNIKeys are generated by the TLS server operator, but
>> DNS records are published by a different entity (say the
>> owner of the name or registrar) ought not be precluded
>> I think. Supporting such a model I think more or less
>> requires setting padding_length to 260 or else risking
>> a failure nobody will notice (if browsers fall back to
>> cleartext SNI) or know how to diagnose if they do.
>>
>> And even in the case of a monolithic service that does it
>> all for every name, I think it'd still likely pick 260
>> in order to avoid having to exercise/write the code to
>> detect and react to a need to increase the padding_length.
>>
>
> Fortunately, we have a number of such operators on this list. Alessandro?
> McManus? Nygren, What say you?
>
> -Ekr
>
>
>
> ("Holy crap - you mean I need to re-publish everyone's
>> ESNIKeys just because this bozo has a really long name?
>> Who made that up?")
>>
>> I really can't see what'd motivate anyone to publish
>> ESNIKeys with a padding_length < 260 tbh (well, other
>> than not having thought it through;-). Anything <260
>> just seems to be asking for later problems.
>>
>> S.
>>
>>
>> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>