Re: [TLS] Updated draft - editorial

"tom.petch" <> Thu, 24 December 2009 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0172F3A6920 for <>; Thu, 24 Dec 2009 10:42:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wL5-rGHYBRCV for <>; Thu, 24 Dec 2009 10:42:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A59893A68E6 for <>; Thu, 24 Dec 2009 10:42:00 -0800 (PST)
X-Trace: 225887954/$PIPEX-ACCEPTED/pipex-customers/
X-SBRS: None
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtYFAJREM0s+vGS0/2dsb2JhbACCXiqFMIhmxEwKgiWCBAQ
X-IronPort-AV: E=Sophos;i="4.47,450,1257120000"; d="scan'208";a="225887954"
X-IP-Direction: IN
Received: from (HELO allison) ([]) by with SMTP; 24 Dec 2009 18:41:41 +0000
Message-ID: <044201ca84c0$6dc51420$0601a8c0@allison>
From: "tom.petch" <>
To: Eric Rescorla <>,
References: <>
Date: Thu, 24 Dec 2009 18:40:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: Re: [TLS] Updated draft - editorial
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Dec 2009 18:42:02 -0000


Some possible clarifications in s.2 (perhaps obvious to those who
have read the previous 2,000 posts, but perhaps not to those
coming to this afresh)

initial intercepted connection
initial intercepted TLS connection request (or ClientHello?)

    He then allows the client's TLS handshake
    The attacker then allows the client's TLS handshake

The handshake is in the clear to the attacker
>From the client to the attacker, the handshake is in the clear

encrypted over the attacker's TLS connection to the server.
encrypted over the attacker's TLS connection to the server,
using the security parameters that the attacker has negotiated

the client communicates with the server over the newly established
the client communicates directly with the server over the newly established

the date used in the
the data used in the

channel binding facility."
"channel binding facility".

Tom Petch

----- Original Message -----
From: "Eric Rescorla" <>
To: <>
Sent: Wednesday, December 16, 2009 10:32 PM
Subject: [TLS] Updated draft

> I've just submitted a new draft that is intended to enact most of
> Pasi's message as well as the noncontroversial editorial comments
> people have raised. Here is what I know still needs work:
> - The final resolution to what's sent in the legacy renegotiation
>   case (see Pasi's message and the text I sent earlier).
> - New text for the identity section in Security considerations.
>   (Pending closure on the list).
> - Make a pass through for clarity for implementors.
>   (Also, I have some text here that Pasi contributed that I
>   need to work in).
> If you think you made a comment which is noncontroversial
> that didn't make it in and/or I screwed up incorporating your
> comment, please let me know and I'll try to fix.
> For some reason, the submission tool is forcing manual
> submission. In the interim you can find it at:
> Thanks,
> -Ekr
> _______________________________________________
> TLS mailing list