Subject: RE: [TLS] draft-housley-evidence-extns-00.txt

From: <[email-masked]>
Date: Tue, 5 Sep 2006 11:10:53 +0300

BTW, in addition to the discussions Peter mentioned, the idea
of generating more convincing evidence of TLS conversation than
an ordinary log has been explored in some papers/drafts. In
my SSL/TLS related bibtex file I found the following; it might
be worth checking them out for additional idea:

Ibrahim Hajjeh and Ahmed Serhrouchni. Integrating a signature module
in SSL/TLS. In ICETE 2004, 1st International Conference on E-Business
and Telecommunication Networks, Setubal, Portugal, August 2004.

   Abstract: SSL/TLS is currently the most deployed security protocol
   on the Internet.  SSL/TLS provides end-to-end secure communications
   between two entities with authentication and data
   protection. However, what is missing from the protocol is a way to
   provide the non-repudiation service. In this paper, we describe a
   generic implementation of the non-repudiation service as an
   optional module in the SSL/TLS protocol. This approach provides
   both parties with evidence that the transaction has taken place and
   a clear separation with application design and development. We
   discuss the motivation for our approach and our proposed
   architecture.

Ibrahim Hajjeh, Mohamad Badra, Ahmed Serhrouchni, Jacques Demerjian,
and Mohammad Achemlal. TLS sign. Work in progress,
draft-hajjeh-tls-sign-01, October 2005.

   Abstract: TLS protocol provides authentication and data protection
   for communication between two entities. However, missing from the
   protocol is a way to perform non-repudiation service. This document
   defines extensions to the TLS protocol to allow it to perform
   non-repudiation service. It is based on [TLSSign] and it provides
   the client and the server the ability to sign by TLS, handshake and
   applications data using certificates such as X.509.

Si Tiange, Tan Xiangrong, and Dai Yiqi. Digital signature enablement
for TLS protocol.  Journal of Tsinghua University (Science and
Technology), 44(1):58-60,64, January 2004.

   Abstract: TLS (transfer layer security) is the most widely used
   security protocol on the Web. However, the original standard only
   encrypts transfered data and does not implicitly sign data. This
   paper describes an approach for modifying the TLS protocol to
   support the underlying digital signature mechanism. The proposal
   modifies the handshake protocol to negotiate the mechanism , and
   the record layer protocol which signs and verifies the application
   data. The new protocol includes a rollback mechanism to allow the
   peers to gracefully revert to an ordinary TLS protocol when
   needed. This approach is backwards compatible to allow the client
   to interoperate with an ordinary TLS server and vise
   versa. Experiments show that the new protocol provides about 10%
   increase in signature data transfers.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Russ Housley [mailto:[email-masked]] 
> Sent: 30 August, 2006 17:57
> To: [email-masked]
> Subject: [TLS] draft-housley-evidence-extns-00.txt
> 
>
http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt
> 
> I would like the TLS WG to be aware of this document.  Review is 
> encouraged, and comments are welcome.
> 
> I would like to make a presentation about this document at the San 
> Diego IETF so that the TLS WG can decide if this should 
> become a WG document.
> 
> Thanks,
>    Russ

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Rob Dugal <[email-masked]>
Date: Thu, 14 Sep 2006 09:29:23 -0400

Some questions:

In your example the client initiates everything  with the evidence_start1 
alert and also sends the EvidenceRequest. Is it always the sender of the 
evidence_start1 alert that must send the EvidenceRequest? Or in your 
example could the server have also sent the  EvidenceRequest even though 
the client started the entire evidence collection?

Does the EvidenceRequest have to immediately follow the evidence_end2 
alert?  Could there be some interchange of application data before the 
EvidenceRequest ?

How does re-negotiation affect this? Can either side request 
re-negotiation within evidence_start1 & evidence_start2  ? 

Does the evidence creation suite ECDSA_P256_WITH_SHA_256 imply that the 
server certificate must have a public key on curve SEPC256R1 and the 
certificate must be signed with ECDSA and SHA-256? What if the server cert 
was using SHA-1 instead but the key was on the correct curve?

Should the client limit the set of evidence creation suites in the 
client-hello to only those suites for which it has a suitable certificate?

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

Russ Housley <[email-masked]> wrote on 08/30/2006 10:57:10 AM:

> Diego IETF so that the TLS WG can decide if this should become a WG 
document.