IETF Logo Mail Archive

Re: [TLS] Next Protocol Negotiation 03

Martin Rex <mrex@sap.com> Tue, 22 May 2012 17:57 UTC

Return-Path: <mrex@sap.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 9D56D21F85EF for <tls@ietfa.amsl.com>; Tue, 22 May 2012 10:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 xY-DL0zWDf-8 for <tls@ietfa.amsl.com>; Tue, 22 May 2012 10:57:25 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB06C21F85EA for <tls@ietf.org>; Tue, 22 May 2012 10:57:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4MHvJaD025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2012 19:57:19 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201205221757.q4MHvIFO000482@fs4113.wdf.sap.corp>
To: wtc@google.com
Date: Tue, 22 May 2012 19:57:18 +0200
In-Reply-To: <CALTJjxEmkHGiQ4aumqC9-OhSgCOvrydvqb2EO0XX7iBLtWMBFg@mail.gmail.com> from "Wan-Teh Chang" at May 22, 12 10:47:46 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: agl@chromium.org, tls@ietf.org
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 22 May 2012 17:57:25 -0000

Wan-Teh Chang wrote:
> 
> On Mon, May 21, 2012 at 6:31 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
> >
> > It's a shame that RFC 4680 'TLS Handshake Message for Supplemental Data'
> > couldn't be used for this, it even has a 2 byte 'type' enum which could
> > perhaps map easily to extension types. But its RFC is quite specific about
> > its position in the handshake. Perhaps something of it can be built upon.
> 
> I'm wondering why you're interested in using the SupplementalData
> handshake message.  SupplementalData is sent immediately before the
> Certificate handshake message, so it is not encrypted in the initial
> handshake.  It cannot replace the proposed EncryptedExtensions
> handshake message without amending RFC 4680.


The logical extension of RFC 4680 would be to define another new pair
of TLS handshake messages (EncryptedSupplementalData) with the same
internal structure, that go between CCS and Finished.

-Martin

v2.23.0 | Report a Bug | By Email