Re: [TLS] RFC 5878 - why?

Ben Laurie <benl@google.com> Thu, 19 September 2013 10:26 UTC

Return-Path: <benl@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 DAEF621F91AB for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 03:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level:
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDQoUeBcqi8L for <tls@ietfa.amsl.com>; Thu, 19 Sep 2013 03:26:21 -0700 (PDT)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6E21F9196 for <tls@ietf.org>; Thu, 19 Sep 2013 03:26:21 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so15325297ief.29 for <tls@ietf.org>; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rTjR+Uy+Fh/A55GBptPmfvDs8Gwphd9Mlkb/OejCJdc=; b=pgD5fujjvnJ0rkS0Qq9v0Eg+OipH5l1kh9N+INYyhvCaR0IkJwUw/5EdoDOk5V0nDr ilPP6iOB+tpOVT1V9hXZBuUI3LUb756Sv/6HcH/4hBdZUdP3M+SLbtYh0XunwJU1yv1S 8S3pD+jzYKedYwjhfOL8sjZoau0JUPyQeEV/qhEltdTQ3tIWVzQ3Fe+Z8HGeegkePGhJ OThf0pd6Koe1/V4mw3rHE1t2mmF+VNtJAP/+FwrnOqmWG0PQ0vbLbPV2wPldqSDa/BVO 8A2Mq5nhKLJKc2dhcnloINGFLFLgAD95+q2G/zi1IJ7a1r+yT0CexYCIFBxRogKtEAsj /UNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rTjR+Uy+Fh/A55GBptPmfvDs8Gwphd9Mlkb/OejCJdc=; b=jv8ViYH4Zo9Ah9eCXFymLrbRyaeodwEk5PFYQE5nhARhMKMB862s/74DthG28uQqSQ PaZAct7j620BCw5rEbtbDwB+k6mbPethtYBqfZY3JCQDcMlyz089uYFBT7yG2JfxPzxC orN8wdup00re+9oxavZ3qSucbFvHN1KzMNj17SIutoS2M+Gfwtl8AB95mIAvpcXJUrGL 1ZEF+M5oZj0zFBfSgPP0s7OZ7I9M5eew5TeJo53B0cysFhEE7jvMnmkCCKpH9O2YBGnI LXdfuFbCICUpGj7XW9Pe5kR3sHt22FM5sEdI1wO6uj5i9jN+joLEXsAy6zjXnLoIu/Pk avyw==
X-Gm-Message-State: ALoCoQlXZEkqTGOQIRbqP1SxPnJ/bVXHca5EXUxxtZ/bULe3iiG5L4gK1fKm8Gy9wj3euEFFC1zjtHnVsvIJMRLtLf4V8FerQsQIjzGFo3/VpzmuBl/zKz+YHBCk4HXzBV4aZO3JqVz1Vss/ru4dA7pdRjTKDBQLLAXz3p0DU4L9rj90bQ3cdzl/2xYio6XE9ydQiyEOOcwQ
MIME-Version: 1.0
X-Received: by 10.42.51.6 with SMTP id c6mr450675icg.3.1379586363658; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz>
Date: Thu, 19 Sep 2013 11:26:03 +0100
Message-ID: <CABrd9SSM0+91s91pCg7dmppiNmsxGt7Xa_g_OMyRFvKtqcVT2Q@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 10:26:29 -0000

On 19 September 2013 09:55, Peter Gutmann <pgut001@cs.auckland.ac.nz>; wrote:
> Trevor Perrin <trevp@trevp.net>; writes:
>
>>I assume that's why no-one reviewed it carefully.
>
> [...]
>
>>The "Experimental" marking wasn't enough to prevent people like CT, TACK,
>>DTCP, and OpenSSL wasting a lot of time evaluating this and trying to use it
>>in the last couple of years.
>
> This seems to combine the worst of both worlds, no-one was really interested
> in it so it passed without review, but then there was enough interest in it
> later for people to try and implement it.  Can anyone who tried to implement
> it explain why they did so?

In CT's case it was because it seemed convenient at the time - we need
to send authz data during the TLS handshake, and here was a way
already defined to do it. We debated allocating a new extension for
it, but decided against it. In the end, because 5878 had errors that
we did not have the power to correct, we decided to abandon it.

I notice that the authors have not responded to the corrections,
either. So I guess they've abandoned it, too.