IETF Logo Mail Archive

[TLS] Revision of draft-friedl-tls-applayerprotoneg posted

"Stephan Friedl (sfriedl)" <sfriedl@cisco.com> Wed, 06 February 2013 03:10 UTC

Return-Path: <sfriedl@cisco.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 D669B21F89E9 for <tls@ietfa.amsl.com>; Tue, 5 Feb 2013 19:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 XSrXkgS-I-5M for <tls@ietfa.amsl.com>; Tue, 5 Feb 2013 19:10:23 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3621F89D5 for <tls@ietf.org>; Tue, 5 Feb 2013 19:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5507; q=dns/txt; s=iport; t=1360120223; x=1361329823; h=from:to:subject:date:message-id:mime-version; bh=iRyL4U/nBCW4oFYY89zt87Os/afLjtA0MAIRpa7f22A=; b=H6QgcP1CtmNA40eFzDIyrXfTu18DoTxK8ysjEpoCCrMzBWdZF0LucyWz x91jQuhlsDqVcMcCambC4RfaN7QXv6ETb/mZ7yG8kYWScNzy+PJPLSicZ 2sqlTxmUQ7NAhA698KVWkmyZj3I5XZE24W5MNwRHCX+122qMb0k6EMkIv g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEbIEVGtJV2d/2dsb2JhbABFgkm9IBZzgiEBBC1eASpWJgEEG4gJmWyTJo4DkHphA5JolAuCcQ2CJA
X-IronPort-AV: E=Sophos; i="4.84,612,1355097600"; d="scan'208,217"; a="173822819"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2013 03:10:22 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r163AMn5016930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Wed, 6 Feb 2013 03:10:22 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 21:10:22 -0600
From: "Stephan Friedl (sfriedl)" <sfriedl@cisco.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Revision of draft-friedl-tls-applayerprotoneg posted
Thread-Index: Ac4EF3brTia13etfR2Sso99Nw3fbAA==
Date: Wed, 06 Feb 2013 03:09:27 +0000
Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.122.147]
Content-Type: multipart/alternative; boundary="_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5xmbalnx02ciscoc_"
MIME-Version: 1.0
Subject: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted
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, 06 Feb 2013 20:55:45 -0000

Hello All,

A revised version of 'Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension' (draft-friedl-tls-applayerprotoneg-01) has been posted.  This version includes a number of significant improvements to the original draft including:

1.            Use of a single extension for both the ClientHello and ServerHello messages
2.            Definition of ProtocolIdentifiers as opaque, non-empty byte strings and the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings
3.            Clarification of the suggested order of client-side ProtocolIdentifiers
4.            Clarification that the server-side extension_data MUST contain exactly one ProtocolIdentifier
5.            Should the server support none of the protocols advertised by the client, then the server SHALL respond with a 'fatal handshake failure alert'.
6.            Addition of Andrei Popov of Microsoft as a co-author

These changes were largely proposed by Andrei and have greatly improved the draft.

I would greatly appreciate any comments and feedback on the draft.

Thanks and Best Wishes,

Stephan

v2.23.0 | Report a Bug | By Email