IETF Logo Mail Archive

Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Wed, 18 September 2013 04:25 UTC

Return-Path: <trevp@trevp.net>
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 97E6F11E80F1 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 21:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 eBtWPviZERcH for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 21:25:10 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7FE11E80C5 for <tls@ietf.org>; Tue, 17 Sep 2013 21:25:09 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so6014036wes.9 for <tls@ietf.org>; Tue, 17 Sep 2013 21:25:07 -0700 (PDT)
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 :content-transfer-encoding; bh=yA9rrmqwFiavpwcrnpbmq1PlBgkYUfVzEfGejmeZUQA=; b=JA4SBToQR5SlI5a9a/CXlRX4EhIirHwAMsQZLVbrc1X/R/6DOWMLovt5u65/vKDvos ktX4wZBWSSfJSjiflAyagf4PRdaEx1ulbjAvcKBGYtWZ7KIR1dvNPccPtSUr6mh+zKq0 MoU48MyU0LvKi3U+EgJk1Y/O0U7hdLSDYEo+KHmtHHgNTH+naBqg5ZOypndmZPAN44eI 9qZ4osbFaZfbPNLz4FpAIV7/md90SPyCnt3KePGugRNsfHJ+VOgq1XP8qUN8e2Clz1u7 Wjq6tdWoFhOecpngfzhCIuwL0P+RefbdHU0nz+VcqC9LmQhrTqRex42xNX9CxR9T5pUH jm2g==
X-Gm-Message-State: ALoCoQnxczlZcPAHmJs8bPC+9pD1Wd5NnkMNSHhOcpg6SlAVat2rlF5nhCR6hIZeyxC/mX+Fz2Xk
MIME-Version: 1.0
X-Received: by 10.194.89.233 with SMTP id br9mr29714456wjb.15.1379478307662; Tue, 17 Sep 2013 21:25:07 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 21:25:07 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <0866AA3B-DB43-44C6-95BC-03DCC2C0ADA7@checkpoint.com>
References: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com> <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com> <CAGZ8ZG3R2-Egermz5Vefu18mD2KAvXOXcG++HJut_rLKapeH4Q@mail.gmail.com> <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com> <CAGZ8ZG38x-BEOncUqL3vO9_c15jQU=s-Bkh3cjLvWtdSb8MCCw@mail.gmail.com> <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com> <CAGZ8ZG2i8jefSMXvqrqseCY3_P3Rqp=WN2a_gRt7K__8Gq20Cg@mail.gmail.com> <0866AA3B-DB43-44C6-95BC-03DCC2C0ADA7@checkpoint.com>
Date: Tue, 17 Sep 2013 21:25:07 -0700
Message-ID: <CAGZ8ZG0840WJ9fn9uiAiGKABGC6VkaqvRopFfaE2eWd8wE4RDQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "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: Wed, 18 Sep 2013 04:25:16 -0000

On Tue, Sep 17, 2013 at 8:55 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>
> RFC 5878 is an experimental RFC. If you've looked at its history, it was approved by the IESG in 2006, and an IPR issue surfaced, so approval was withdrawn, and the draft lay dormant for 3 years. If during those three years anyone had come up with some other draft describing an authorization extension, I think that would have been approved instead.

Why is there need of an "authorization extension"?

TLS already has well-designed, standards-track ways of passing
extension data back and forth:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)

Why is that not sufficient?


Trevor

v2.23.0 | Report a Bug | By Email