IETF Logo Mail Archive

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

Nick Harper <nharper@google.com> Thu, 12 December 2019 20:55 UTC

Return-Path: <nharper@google.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 E57571200F3 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2019 12:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.489
X-Spam-Level:
X-Spam-Status: No, score=-17.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 n78Z-Bor_Jvj for <tls@ietfa.amsl.com>; Thu, 12 Dec 2019 12:55:56 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 E83C9120024 for <tls@ietf.org>; Thu, 12 Dec 2019 12:55:55 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id r27so3428426otc.8 for <tls@ietf.org>; Thu, 12 Dec 2019 12:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Y6lUfJG3J5KFmFy3cXHJOOvcD6DK8ibzbf3hOnWDvk=; b=LlOD228gqSMyVoPSE3AAkgQrAcIPkJXXHuljUYRVj1hm4fmmHJpbnePvPPvTTHc6yf G7+XiHbCSp9tteinSYTWNIkRSFdviciXCHJNmix0dZpsoB94E9y5y586GGjfQGdwHeOE 5xZomVOQlSbGwbMUcIBJ7DUnURS65ceN2epHxxFa36MMmPzrpraKMYMfuYJ19z+nGuxe XSYxURv4sI52Cmz5bXgHAkgc+tUOmdjpW31B6IhCOYnZJlSAqh1O09HnxnYC4RpLPDdY 8c+cSk2h2gm78xcjvCWNuKqzh7pzuaTOv6eULwQG4PYUgFkmxP6waM6MvCj8yqLnc/VI Zj3w==
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=0Y6lUfJG3J5KFmFy3cXHJOOvcD6DK8ibzbf3hOnWDvk=; b=jw7icjYkOmTlGizdl4lBLWKtSzFAbtSzdxo6P+9nUtvtaYO8WggiB/sePUxh7q4Mfc l63QQu5UpR3AxDfUzy8YFlPeBnuwcxGP6a7TtNnxi2Ik2ZRonG7yZ+evHVB58YF2kaNU Zk+7q5F1tB4RyTo9Z9cqxVFmEkMVbZbdFmjcg/RUgXeA5yyApfwH4wHuaZGvbqsz/j1z l50b3N8k5XwdxfrdXEKRt1HDLlcqbI9i138K0rWX/6EQ94Fzt8rH9kQADvj0PuQufbU3 HaBQaCQm/mGle1dz01v9lH+SpxRTGMtt6DiFacD1VTUlvPtdwpcRqyOG9v6g8pL6lqmX F2Ng==
X-Gm-Message-State: APjAAAVj+eAKu1ioHmzMJeST9WCmM9m8dICRCpg3lQUlsxlCAm8BstpE OzY5ya8dBanvd0l6FejWwWTARtxUoFz1RvkdvQPXPA==
X-Google-Smtp-Source: APXvYqwUDaH1HkQZ/hj+CQRALUilerrKnTBR9OcODc5WLO4a1IZTJznxcB0MG8tZ/kIacDorNjPL/ZzQNNm0/xipxFk=
X-Received: by 2002:a9d:6a50:: with SMTP id h16mr10573627otn.267.1576184154776; Thu, 12 Dec 2019 12:55:54 -0800 (PST)
MIME-Version: 1.0
References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <c4bab542-f1fd-4c80-89b8-1b7a3ef883a7@www.fastmail.com> <CAMfhd9W_+1i=Q48GKAxT=TtHm+fKxUKUepqCtfJ7xQ6LgM4h_w@mail.gmail.com> <CAEMoRCshwo1vsb+bYbJLpOCMWGcJ15sz8COXeXbxmX-KDbY8Mw@mail.gmail.com> <20191207102017.GA1754124@LK-Perkele-VII> <8f54acb3-61df-4617-b2c6-53b8c9021575@redhat.com> <20191211142155.GA1879660@LK-Perkele-VII> <CAF8qwaAHXGWwAswv8XfhjhN3fi7XtVSngLJY8sekYgX+u=wXVA@mail.gmail.com> <054bd0ed-6afe-4500-9339-16f414aa8840@redhat.com> <CAF8qwaChxmQw8K6YbEUkkxTQ6UnXfuowzoZZUOoje9Cw5p1dEQ@mail.gmail.com> <aa89b581-cdb1-4251-b849-6eda45f525be@redhat.com>
In-Reply-To: <aa89b581-cdb1-4251-b849-6eda45f525be@redhat.com>
From: Nick Harper <nharper@google.com>
Date: Thu, 12 Dec 2019 12:55:42 -0800
Message-ID: <CACdeXiJ618GOaZD3M29gNGDX147jnnx-MRnct9KnuYpVL8e=+g@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a5d620059987f854"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zC99JPTh-YA5Vvq9OwgRP_dmMOk>
Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1
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, 12 Dec 2019 20:55:58 -0000

On Thu, Dec 12, 2019 at 8:27 AM Hubert Kario <hkario@redhat.com> wrote:

> On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote:
> > On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario <hkario@redhat.com> wrote:
> >
> >> On Wednesday, 11 December 2019 18:06:19 CET, David Benjamin wrote: ...
> >
> > ... some TLS stacks don't
> > support renegotiation as a server at all (BoringSSL and Go).
> >
> > ... Chrome does not accept it ...
>
> so because Google decided one thing, everybody has to bow down to it?
>
> and, sorry, but I consider the privacy angle a red herring, nobody is doing
> proper AppData padding, so the connections leak privacy information in TLS
> 1.3
> like a sieve too
>

Privacy isn't a red herring. There's a big difference between leaking
ciphertext lengths vs leaking the user's name, email address, and other PII
present in a client cert when the client cert is sent in the clear.

>
> >> An endpoint MAY use renegotiation to provide confidentiality protection
> >> for client credentials offered in the handshake
> >
> > An HTTP/2 client speaks as soon as the handshake completes and does not
> know
> > whether the server is going to do this.
>
> if privacy was so important why nobody worked on it with HTTP/2? It's not
> like
> much has changed in the last 4 years on that front.
>

HTTP/2 couldn't fix the issue with TLS 1.2 client certs being sent in the
clear, but that problem was solved in TLS 1.3. Many of the problems not
solved by H2 are being worked on in QUIC. It takes time to develop and
deploy these protocols. Don't let perfect be the enemy of good.

>
> sorry, I'm not buying that argument
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email