Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis

Michael D'Errico <mike-list@pobox.com> Mon, 17 May 2010 05:34 UTC

Return-Path: <mike-list@pobox.com>
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 39EAE3A6D00 for <tls@core3.amsl.com>; Sun, 16 May 2010 22:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level:
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_50=0.001]
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 9x30nS82PZ2V for <tls@core3.amsl.com>; Sun, 16 May 2010 22:34:22 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 6B9273A6D0C for <tls@ietf.org>; Sun, 16 May 2010 22:30:27 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B92C5B46B3; Mon, 17 May 2010 01:30:18 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=mbda/SzlVYwB KiX3FITB9fvxyZM=; b=m8UunSmWyDBw9Qj8mSyzgR9js4BiAakzvynffbA4MVtn 5WZsmSBX7mhiwWb0J3/o34QcaWgysv/xOagdxsiKb5i/ydVKEfGa8GgL+rMNM4jj 19I3lrseEV9lJzd0WZiBp1ZjnIl3OJS3iwFwstbu9EEY0n/ZHd8z2UdUJ/ZhjXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=kQIzul SjCLg4YGBEGPmrGWQr/g/+dvrInVEjkmeYSPbZHj/N7Bm/+P4oFmO0yjEZZcFBc2 MXREln4EnPi+Bsyv5He5ohQf9DXt5RF/8HDtsvAUOEonHXQhA2pfNuNcVD1EBIFC seIm/Z7ssVq1ulzqagOcvp2gl0q2BiBAu0kzk=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 95282B46B2; Mon, 17 May 2010 01:30:16 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0B22EB46B1; Mon, 17 May 2010 01:30:12 -0400 (EDT)
Message-ID: <4BF0D459.4010806@pobox.com>
Date: Sun, 16 May 2010 22:30:01 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43B2D7@xmb-sjc-225.amer.cisco.com><808FD6E27AD4884E94820BC333B2DB775B82DD0CE1@NOK-EUMSG-01.mgdnok.nokia.com><AANLkTikvkuR5_6kHnpwM19PxSvtBv4qrC1_QldxMnOWE@mail.gmail.com> <4BEE0EAB.5030806@pobox.com> <AC1CFD94F59A264488DC2BEC3E890DE50A67C235@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A67C235@xmb-sjc-225.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 4679075E-6175-11DF-98A7-D033EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
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-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: Mon, 17 May 2010 05:34:24 -0000

I understand the mechanics are that the server doesn't send the
extensions when it's resumed a session.

My question is whether the spec. disallows taking the SNI into
consideration when deciding whether to resume or not.  Suppose
my server handles foo.edu and bar.org at the same IP address
and uses SNI to determine which set of certificates and options
to choose from.

A client might establish a session using SNI=foo.edu.  Later,
it may try to resume that session, but send SNI=bar.org.  Which
should take precedence?  The client may cache sessions based
solely on the IP address and think that it can reuse any session
it's established on that machine in the past.

What if foo.edu doesn't care so much about security and just
wants all connections to work, so its cipher suite list is huge
and it doesn't care if RI is sent, etc.  But bar.org has strong
security and privacy requirements, so its cipher suite list is
short and contains only the best crypto available, and RI is a
must even for initial handshakes.

Would it make sense for the server to resume the old session
from foo.edu and hand it off to the bar.org application?  I'd
say absolutely not.  So in my software, I plan to check for a
match of the SNI prior to allowing a session to be resumed.

I would hate for this to be considered "illegal."

Mike



Joseph Salowey (jsalowey) wrote:
> This clarification is consistent with existing text in the draft and in
> RFC 4366. 
> 
> " Note also that all the extensions defined in this section are
>    relevant only when a session is initiated. ... 
> 
> -  If, on the other hand, the older session is resumed, then the
>       server MUST ignore the extensions and send a server hello
>       containing none of the extension types.  In this case, the
>       functionality of these extensions negotiated during the original
>       session initiation is applied to the resumed session."
> 
> Joe
> 
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>> Michael D'Errico
>> Sent: Friday, May 14, 2010 8:02 PM
>> To: Donald Eastlake
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] Proposed changes to draft-ietf-tls-rfc4366-bis
>>
>> Donald Eastlake wrote:
>>> There having been no objections to the changes posted at the
> beginning
>>> of this thread, I've gone ahead and made them.
>> Sorry, I've been busy.  One of the things added was:
>>
>>     Add to section 3 before the last paragraph to clarify session
>>     resumption behavior:
>>
>>     "When the server resumes a session, the server_name extension
>>     is ignored."
>>
>> I have not yet done it, but I plan to have my session resumption
>> logic look at the SNI to see if it matches the name used for the
>> cached session.  If they don't match, a full handshake will be
>> completed.  We already have to verify that TLS version, cipher
>> suite, and compression method are compatible with the hello
>> parameters.  I don't see why the SNI is any less important.
>>
>> Does the above text suggest that my plan would be non-compliant?
>>
>> Thanks,
>>
>> Mike
>>
>>
>>
>>> Thanks,
>>> Donald
>>> =============================
>>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>  155 Beaver Street   +1-508-634-2066 (home)
>>>  Milford, MA 01757 USA
>>>  d3e3e3@gmail.com