Re: [TLS] Tr: Behaviour when TLS fails

Eric Rescorla <ekr@networkresonance.com> Thu, 25 September 2008 16:15 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D463A6813; Thu, 25 Sep 2008 09:15:03 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6804D3A6813 for <tls@core3.amsl.com>; Thu, 25 Sep 2008 09:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oqrmSyYScQP for <tls@core3.amsl.com>; Thu, 25 Sep 2008 09:14:57 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 164D53A6808 for <tls@ietf.org>; Thu, 25 Sep 2008 09:14:57 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7B1E350846; Thu, 25 Sep 2008 09:27:28 -0700 (PDT)
Date: Thu, 25 Sep 2008 09:27:28 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Julien ÉLIE <julien@trigofacile.com>
In-Reply-To: <EED13F85BDFC46D0AA43656FC05ABF3B@Iulius>
References: <EED13F85BDFC46D0AA43656FC05ABF3B@Iulius>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080925162728.7B1E350846@romeo.rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Tr: Behaviour when TLS fails
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

At Thu, 25 Sep 2008 08:26:02 +0200,
Julien ÉLIE wrote:
> 
> Hi,
> 
> Would it be possible to have some more information about how to behave when
> a TLS negotiation fails?
> 
> In RFC 4642 on TLS with NNTP, it is written:
> 
>     Upon receiving a 382 response to a STARTTLS command, the client MUST
>     start the TLS negotiation before giving any other NNTP commands.  The
>     TLS negotiation begins for both the client and server with the first
>     octet following the CRLF of the 382 response.  If, after having
>     issued the STARTTLS command, the client finds out that some failure
>     prevents it from actually starting a TLS handshake, then it SHOULD
>     immediately close the connection.
> 
>     [...]
> 
>     If the TLS negotiation fails, both client and server SHOULD
>     immediately close the connection.  Note that while continuing the
>     NNTP session is theoretically possible, in practice a TLS negotiation
>     failure often leaves the session in an indeterminate state;
>     therefore, interoperability can not be guaranteed.
> 
> But we do not know whether the "SHOULD immediately close the connection"
> is in fact a MUST.
> 
> You can see a current discussion about that here:
>     http://groups.google.fr/group/news.software.nntp/browse_frm/thread/aa305c96999afbcf
> 
> 
> Some excerpts below.
> 
> Thanks beforehand for your answer (please CC: me as I am not subscribed
> to the list).

TLS doesn't have any opinion about what you do with the underlying 
transport. So, as far as TLS is concerned, the underlying transport
(TCP) could stay open and you could try to negotiate NNTP on it.
It might even work. It's recommended not for the reasons noted
above. I wouldn't have a problem with 4462 saying MUST, but
I don't think it's required by the logic of TLS.

-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls