[TLS] Cached-info draft open issues
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 20 February 2013 22:44 UTC
Return-Path: <jsalowey@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 5760B21E8037 for <tls@ietfa.amsl.com>; Wed, 20 Feb 2013 14:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 IIJ-1VSomFon for <tls@ietfa.amsl.com>; Wed, 20 Feb 2013 14:44:15 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD321E8030 for <tls@ietf.org>; Wed, 20 Feb 2013 14:44:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1361400255; x=1362609855; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uUS42326qZKonM2yWUC2X3WcqX1dEMSwY35cKJvIA9k=; b=jvYX28upe/Iu4UgAg8DcCVxfHtRHvvNY60q1Nw04/H9Nb0LW0sqmvdSC wwzj6ZuAv7qM0h+/tq4sOqP6JaBI406Qk6lrUiDYx4jLrVbH+A/g/XRtH xLMpB5G+eVzFxH7RWX2ZARSVaaQo5nMbOkZ2qrqU90QBXsbaMn7wscnHm s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFpRJVGtJXG+/2dsb2JhbABFwGOBAxZzgiEBBDpRASoLCUInBBuICp9FoRGOXUKCVWEDkm2UGoMHgic
X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; d="scan'208";a="179409273"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2013 22:44:15 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1KMiFW5022042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Wed, 20 Feb 2013 22:44:15 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 16:44:15 -0600
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: Cached-info draft open issues
Thread-Index: AQHOD7vOEQmEkKvPOU2LJJMPtLylnw==
Date: Wed, 20 Feb 2013 22:44:14 +0000
Message-ID: <A95B4818FD85874D8F16607F1AC7C628A3B29C@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.249.140]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6390AE9BFC1CB94AAD2B737ACAFE93A1@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] Cached-info draft open issues
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, 20 Feb 2013 22:44:16 -0000
According to my notes we have the following open issue with the draft-ietf-tls-cached-info-13. 1) Whether to include the confirmation of cached objects in the response from the server and what to include in the server hello. We had some discussion earlier on the list. While it didn't seem that we had strong consensus I think this is roughly where things are at: + The inclusion or elimination of the hashed values in some messages could cause ambiguities. Martin Rex raised the issue that the certificate_authorities field may be empty or contain small values that could be confused with a hash. + The server can indicate which cached objects it accepts in the server hello. + The server can then send an empty field in place of the objects it would normally send + The spec would have to define how the empty field was defined for each type. + In order to handle the caching of intermediate certificates a cached object type would be defined for it and the spec would define how the server certificate message is formatted to account for the cached certificates. I'm looking for comments on this approaches and contributions of text for the document. Thanks, Joe
- [TLS] Cached-info draft open issues Joseph Salowey (jsalowey)
- Re: [TLS] Cached-info draft open issues Hannes Tschofenig
- Re: [TLS] Cached-info draft open issues Joseph Salowey (jsalowey)