Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 31 October 2017 21:26 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 28AC013F74B for <tls@ietfa.amsl.com>; Tue, 31 Oct 2017 14:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 jG4uBpVw-c-z for <tls@ietfa.amsl.com>; Tue, 31 Oct 2017 14:26:32 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C3F13F745 for <tls@ietf.org>; Tue, 31 Oct 2017 14:26:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7E7EBE79; Tue, 31 Oct 2017 21:26:29 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I9ABSajA4Q5; Tue, 31 Oct 2017 21:26:28 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 37A39BE74; Tue, 31 Oct 2017 21:26:28 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509485188; bh=YerkZLsYLQdqLi/SXwpT0xKou+WyikftVKzdyJYHPKs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JkxG2hG5mtnDWvv0Oi1Rj6KXyT4ZBf8zJSd+xtgxdmLQ0HtN6sKfekEZUtQKTKUal iAZQ4ua56D74AkLIgHbNhn8g7s3qAmGtCBRl2CU7Tx/5JQy39HYq81Q22bU4AYGNxq dGSO1Q2j61SdeBkcx4o/djVFkMvNBJlka522cN6U=
To: "Owen Friel (ofriel)" <ofriel@cisco.com>, Richard Barnes <rlb@ipv.sx>, "<tls@ietf.org>" <tls@ietf.org>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <CAL02cgRS715Vc+4_QNDSNBW8LP1f-Rmp0FW9W_pyHHpAnkX7Sg@mail.gmail.com> <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6d448c71-8585-be88-302d-feee7e098ac9@cs.tcd.ie>
Date: Tue, 31 Oct 2017 21:26:27 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="PRK0APALIKBuI8rxmI4a2sLw0cm3S2hTQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yhGlFvX6AS9tKS1f3pVd4VHajsc>
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 31 Oct 2017 21:26:34 -0000

Hi Owen,

On 31/10/17 21:03, Owen Friel (ofriel) wrote:
>> Interesting. One bit puzzles me: wouldn't the new content-type
>> give the game away and cause middleboxes to block this?
>> 
>> S.
>> 
> [ofriel] The intention isn’t to try and obscure the fact that there 
> is an ATLS session. Even if that new content-type was not defined,
> it would be easy to write a simple pattern match script on the
> middlebox to identity the JSON body and leading base64 bytes of the
> TLS records in the body.

So that leaves me puzzled still, sorry.

I can't think of a situation with a middlebox that isn't ok
with the client doing proper TLS but is ok with ATLS.

Can you give an example of such a situation?

In case it helps, I can imagine that some middleboxes won't
(yet) know about this and will let it through for a while,
but that seems fairly brittle. So, I'd have thought it may
be worthwhile trying to hide what's what here if you want
it to be robust against an antagonistic middlebox or censor.
But maybe you guys analysed that already and figured it'd
not work. (Which brings me back to "puzzled":-)

Cheers,
S.


> 
>