Re: [TLS] proposal to encrypt ContentType for TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Mon, 14 July 2014 16:21 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC6E1A0AEE for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 09:21:55 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 zzlawBXa3adK for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 09:21:53 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4351A0AEB for <tls@ietf.org>; Mon, 14 Jul 2014 09:21:52 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id f73so1700122yha.24 for <tls@ietf.org>; Mon, 14 Jul 2014 09:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sG/iiu+yo2+AKS91Fj5UjjmW9x0s8eQNhvKGJeJPi/w=; b=GzON6bR0Z4uRKwTJ4votbReWxXcsjvvpZ2jYk4IiDQW0KCP6YdQwAw3ErZgEQ+mBnR nj6vwf2ngVefyZF81Y+st43GxHfOCsM584IiOpEFOAKWXYUDD5wvKwVOoZYXq3H9KJYc WpsWrTppoLzr/zf3S5QQhoENTVpulsUqWl4SifHGSE3DOxMqG9FHP0DAY1bsdNTv4kcM fVqncxGh4Yz/aW/v07TjbBYPU8nTz6ljIJLTpy1T77uPWhUc/ZeAbb8rZ+urMn0tpDGk fPSxaeldNqnGV0KO79El4qE7aLeQE8VjVW9nH6KxnUW1XBJaI3z9iXdOEpEfDP04XnI4 jPXQ==
MIME-Version: 1.0
X-Received: by 10.236.25.234 with SMTP id z70mr31069462yhz.107.1405354912150; Mon, 14 Jul 2014 09:21:52 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Mon, 14 Jul 2014 09:21:52 -0700 (PDT)
Received: by 10.170.202.8 with HTTP; Mon, 14 Jul 2014 09:21:52 -0700 (PDT)
In-Reply-To: <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp>
References: <53C3E973.4070504@fifthhorseman.net> <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp>
Date: Mon, 14 Jul 2014 09:21:52 -0700
Message-ID: <CACsn0cnbszHANmS+1L6+BpMNQX2s-bnR1_DPB9nnKVp2BX9M8Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=089e0149be7a527a4304fe29b05d
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w_eqWA3xOQ8lYk2YwzHtlVdJNx4
Cc: tls@ietf.org
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 14 Jul 2014 16:21:55 -0000

On Jul 14, 2014 9:10 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Daniel Kahn Gillmor wrote:
>
> > On 07/14/2014 10:12 AM, Martin Rex wrote:
> >> Daniel Kahn Gillmor wrote:
> >>> The fact that network-facing code won't know with certainty when a
> >>> handshake completes and when application data starts flowing seems
like
> >>> a feature, not a bug, if we want to protect the communication.
> >>
> >> I definitely see it as a feature.
> >
> > I'm glad to hear it :)
>
> Ooops, my hands wrote the opposite of what my mind was thinking of.
>
> I meant to say that it is a feature of TLS to be able to distinguish
> handshake phase from application data phase on the outside.
>
>
> >
> >> The bug here would be an unnecessary difference to existing TLS
protocol versions.
> >  [...]
> > > Drop-in replacement of only the TLS stack will be impossible.
> >
> > Yes, I'm suggesting that for people in the unusual situation of having
> > moved their network i/o state machine entirely outside of their TLS
> > stack, they'll want to update their network i/o state machines first (to
> > understand the new traffic patterns), before upgrading their TLS stacks
> > to support TLS 1.3.
>
>
> That is not ususual at all.  It is actually the most reasonable approach
> if you want to do network I/O with arbitrary mixtures of non-blocking
> and application-specified timeouts.   Microsoft's SChannel SSP AFAIK has
> always been transport-free.  In addition to non-blocking, I also
> implemented server-side "TLS extension SNI" purely at the application
> layer, the server-side of the SSL stack doesn't care about it.

No, it isn't. There is no reason that a TLS implementation cannot accept
bytes from the network layer and indicate when it is ready to send on a
message, instead of accepting records.

Sincerely,
Watson Ladd
>
>
> >
> > It seems entirely possible that this will be the case anyway, given the
> > new handshake flows proposed for TLS 1.3.
> >
> > I don't think this is a good reason to avoid the improvement.
>
>
> The more bogus and backwards-incompatible changes go into TLSv1.3,
> the more unlikely it will be that we will ever support it.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls