Re: [TLS] Confirming Consensus: Negotiating upper layer protocols

Adam Langley <agl@google.com> Fri, 08 February 2013 13:23 UTC

Return-Path: <agl@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 9049921F8574 for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 05:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level:
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGAUxWDIcjh1 for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 05:23:21 -0800 (PST)
Received: from mail-ia0-x229.google.com (ia-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3221F8497 for <tls@ietf.org>; Fri, 8 Feb 2013 05:23:20 -0800 (PST)
Received: by mail-ia0-f169.google.com with SMTP id j5so4260548iaf.0 for <tls@ietf.org>; Fri, 08 Feb 2013 05:23:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ect3m9dRtxMfEJ4ha5tGRvBMG/d2B08W8O3jTI02Nus=; b=Vrf2LC1fWpisQqDQ6xi9n0LpZj8oagUb60CIDAYW71EZNpTjQs/Suo3dPmz+Rym2Uw lhaXct93btIgGktD0s8rZiwotbeGpGfOnI9ACTkbcxhr/0D7iNG8BzgP/4zHkQzbyE9/ iYSwS9rND7TOO1/9CXb4DdphYzM08ecjkQPrevROzpfFCctYnYvTflIQkKgtnRfNGd6k OFctMa2nd7+MC9W+74X7s9EI5G0kJL/BPqJjdp9mnEr4p0BOho+d05EXEU3xGaVALGAK NN0QhgmcPwYBRd/wSAW7bA13VRiT1lxOpy8onjR5f2GQT1Ndc6TaL6ONLcN3leXbcIhV 9QJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ect3m9dRtxMfEJ4ha5tGRvBMG/d2B08W8O3jTI02Nus=; b=otNqAAWAv/QDnV6hUkNeyoe8c9AkctH2htCMng8k0zeSujx2IYr2mNnuy3v0vNMpo+ pc7WPnGZIwg5kwYDDt6Fjn7obmyJeg7uvFEq2uqxBIexhixCIwqPcg58vX7V5H9neh7I THQ81ddEvo24Qh8a/XraIEWOvQnmPIcYs4tLSrkxuEtH3wDFsqDRiBk0Uq5e4B5g9bUg LTQbGN+I0gmUryEeGIW3eKiyXcFpC/qeXpLHeDBkcj+tphLqcNQfXJjfXFXZOQU1256s mqSPfOd2Kuyc+9lSCrCZ2MtOjBGj6c2uO9SGK/oN85sT7tWjUCCiM5sDCRjyQblRJNgH VbpQ==
MIME-Version: 1.0
X-Received: by 10.50.57.164 with SMTP id j4mr2141542igq.91.1360329800217; Fri, 08 Feb 2013 05:23:20 -0800 (PST)
Received: by 10.231.241.201 with HTTP; Fri, 8 Feb 2013 05:23:20 -0800 (PST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEC55@uxcn10-2.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73333FEC55@uxcn10-2.UoA.auckland.ac.nz>
Date: Fri, 08 Feb 2013 08:23:20 -0500
Message-ID: <CAL9PXLwLQ3TktQ2jHzU_3AHWGjh8409nSjOM713gvRhLbB2m+Q@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
X-Gm-Message-State: ALoCoQlVPy6g+0CFg3IUKLdhs04hR9Lnxcc/QIc0CvrN9EN7dNIC6Y8wxuC44NaSTczQM/TiW645GyXeGbRxBYLbb4IkiVS7tssPgb/EVZXthSNoe678kPj0ajssl/IdCeWhJkRiLuq0dOxxHxvnv/jHfZTJUBRTIyzozlPv0duukGTFn9H4gFNuG9+th8ZSj5J23gmzG1q8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols
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: Fri, 08 Feb 2013 13:23:22 -0000

On Fri, Feb 8, 2013 at 7:47 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Yeah, I'd sorta guessed that, but I'd really prefer it if they used the
> standard TLS format for things.  At the moment I have to drop use of standard
> TLS PDU parsing and switch to an ad-hoc custom-written parser for that one
> data blob, I can't see any good reason to use the nonstandard format when
> everything else in TLS uses the standard one.

The difference between the wording and using the TLS presentation
format is the addition of an extra length prefix. Since the extension
already has a length, it's a little sad that using the presentation
format requires adding another one - it's not as if these structures
are ever extended with extra, optional fields.

None the less, in the interests of being uniform, maybe we should have
another length.


Cheers

AGL