Re: [TLS] possible new work item: not breaking TLS

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 13 July 2017 15:52 UTC

Return-Path: <prvs=83673f80db=uri@ll.mit.edu>
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 4536E12EE8D for <tls@ietfa.amsl.com>; Thu, 13 Jul 2017 08:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 yHKGK61x8pYB for <tls@ietfa.amsl.com>; Thu, 13 Jul 2017 08:52:41 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8CF129B53 for <tls@ietf.org>; Thu, 13 Jul 2017 08:52:40 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id v6DFqWsb003440; Thu, 13 Jul 2017 11:52:35 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, tls chair <tls-chairs@tools.ietf.org>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] possible new work item: not breaking TLS
Thread-Index: AQHS+8+nbhJkbtO5NkyhZG32p2qUhqJR6HKA
Date: Thu, 13 Jul 2017 15:52:31 +0000
Message-ID: <253E111A-5B80-4477-B1EF-E0785EA202AD@ll.mit.edu>
References: <f7a9beb6-ad71-89a9-22b8-05126e30170b@cs.tcd.ie>
In-Reply-To: <f7a9beb6-ad71-89a9-22b8-05126e30170b@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.23.0.170610
x-originating-ip: [172.25.177.195]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3582791551_695363862"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-13_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707130247
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/otJHsboKxuhEBPPZuh9POONVXB0>
Subject: Re: [TLS] possible new work item: not breaking TLS
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: Thu, 13 Jul 2017 15:52:44 -0000

I support allocating a time slot for the arguments against the draft-green (and similar/related approaches).

I also support documenting the above arguments, possibly in a TLS WG draft.
--
Regards,
Uri Blumenthal

On 7/13/17, 08:00, "TLS on behalf of Stephen Farrell" <tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:

    
    Hi again TLS WG chairs,
    
    I've done a bit more work on the collection of arguments
    against the latest break-TLS proposal. [1] I plan to keep
    working on that so more input is welcome. (Corrections
    where I've gotten stuff wrong are even more welcome.)
    
    I'd like to again request some time on the agenda to
    allow discussion of those points in a more structured
    manner than will be possible during the mic-line scrum
    that'll likely follow a sales-pitch for draft-green.
    
    I'd also like to ask the WG if we think it'd be useful
    to document the arguments against that and other "let's
    break-tls" proposals we've seen in the past in an RFC.
    If people think it would be useful, I'd be willing to
    do work to edit such a draft, or help edit that.
    
    Thanks,
    S.
    
    [1] https://github.com/sftcd/tinfoil