Rob Dugal | 2 Mar 14:05 2006

new draft "ECMQV Ciphersuites for TLS" for review


Dear TLS Working Group:

I am co-author of a new draft "ECMQV Ciphersuites for TLS"
        http://www.ietf.org/internet-drafts/draft-dugal-tls-ecmqv-00.txt

This draft describes new ciphersuites and a client authentication mode for supporting
Elliptic Curve Menezes-Qu-Vanstone Key Agreement (ECMQV). ECMQV offers some
additional security properties over Elliptic Curve Diffie-Hellman (ECDH).

We are hopeful that this draft will be of interest to members of the working group. We
would like to know if the TLS WG is interested in making this a WG work item.   If not,
we are willing to see it progress as an individual submission.   We would appreciate
the TLS WG review and comment.


Thanks,
Robert

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal <at> certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Internet-Drafts | 2 Mar 21:50 2006
Picon

I-D ACTION:draft-ietf-tls-rfc4346-bis-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: The TLS Protocol
	Author(s)	: T. Dierks, E. Rescorla
	Filename	: draft-ietf-tls-rfc4346-bis-00.txt
	Pages		: 112
	Date		: 2006-3-2
	
   This document specifies Version 1.2 of the Transport Layer Security
   (TLS) protocol. The TLS protocol provides communications security
   over the Internet. The protocol allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping,
   tampering, or message forgery.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tls-rfc4346-bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 138 bytes
Attachment (draft-ietf-tls-rfc4346-bis-00.txt): message/external-body, 68 bytes
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Nelson B. Bolyard | 2 Mar 22:37 2006

very preliminary comments on draft-ietf-tls-rfc4346-bis-00.txt

I just took a quick look at this draft:

> 	Title		: The TLS Protocol
> 	Author(s)	: T. Dierks, E. Rescorla
> 	Filename	: draft-ietf-tls-rfc4346-bis-00.txt
> 	Pages		: 112
> 	Date		: 2006-3-2

It says:

>    This document specifies Version 1.2 of the Transport Layer Security
>    (TLS) protocol. The TLS protocol provides communications security
>    over the Internet. The protocol allows client/server applications to
>    communicate in a way that is designed to prevent eavesdropping,
>    tampering, or message forgery.

But later in the draft, it says:

   version
       The version of the protocol being employed. This document
-->    describes TLS Version 1.1, which uses the version { 3, 2 }. The
       version value 3.2 is historical: TLS version 1.1 is a minor
       modification to the TLS 1.0 protocol, which was itself a minor
       modification to the SSL 3.0 protocol, which bears the version
       value 3.0. (See Appendix A.1).

Pagination of this ID seems irregular.  See page 13, for example.
It contains only 3 lines, the first 3 lines of a paragraph, the rest of
which is on page 14.

This draft uses the ASCII FormFeed (FF) character as if it was an
end-of-line character.  Please change that so that the last line of a
page ends with the usual end-of-line character(s), and the FF character
begins the next line. Some printers & software only recognize the FF
character if it is the first character on a line, e.g. following an
end-of-line character.  So for maximum compatibility...

--

-- 
Nelson B
Lakshminath Dondeti | 4 Mar 00:34 2006

Review (Re: I-D ACTION:draft-ietf-tls-ctr-00.txt)

Hi Nagendra,

I have a few questions and thoughts on the TLS-CTR mode I-D:

On the IV construction:

I see that the nonce is 48 bits in length.  My recollection of David 
McGrew's analysis of CTR mode is that 64 bits of nonce would provide 
128-bit security (for a 128bit key and CTR mode).  My question is on 
the level of security 48-bit nonces provide.  I see that 3686 uses a 
32-bit nonce.  I am confused at what is the right length for the 
nonce.  Some discussion on that might be appropriate in the SEC 
considerations section.  Perhaps David might help clarify (I may have 
misread his paper).

On the block level counter, 3686 specifies a 32-bit counter citing 
IPv6 Jumbograms' requirement.  SRTP makes a note that for multimedia 
apps, that might be safely ignored.  Could you also make a similar 
note in this document, or perhaps you might also want to support 
jumbograms?  (Perhaps IPv6 historians might tell us whether there are 
practical uses for jumbograms).

I don't think it is sufficient to refer to 3686's security 
considerations.  Those notes are written for a different protocol and 
context.  Perhaps you might copy and paste from there and edit the 
text, if you want to reuse text.

best,
Lakshminath

At 03:50 PM 2/28/2006, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Transport Layer Security Working 
>Group of the IETF.
>
>         Title           : AES Counter Mode Cipher Suites for TLS and DTLS
>         Author(s)       : N. Modadugu, E. Rescorla
>         Filename        : draft-ietf-tls-ctr-00.txt
>         Pages           : 9
>         Date            : 2006-2-28
>
>    This document describes the use of the Advanced Encryption Standard
>    (AES) Counter Mode for use as a Transport Layer Security (TLS) and
>    Datagram Transport Layer Security (DTLS) confidentiality mechanism.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>i-d-announce-request <at> ietf.org with the word unsubscribe in the body 
>of the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-tls-ctr-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         mailserv <at> ietf.org.
>In the body type:
>         "FILE /internet-drafts/draft-ietf-tls-ctr-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <2006-2-28154500.I-D <at> ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ctr-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt>
>_______________________________________________
>TLS mailing list
>TLS <at> lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/tls
Nikos Mavrogiannopoulos | 4 Mar 09:55 2006

some more questions and comments on draft-ietf-tls-ctr-00.txt

On Wed 01 Mar 2006 00:50, Internet-Drafts <at> ietf.org wrote:

Hello,
 I've read the CTR draft and I have some questions on it, phrased below.
I'm not familiar with the counter mode and attacks on it, thus my 
questions are based on facts that were not clear while reading the 
document and after having read rfc3686 (which was mandatory for
me to read to understand the CTR draft).

1. What is the size of IV generated after the ciphersuite is generated? 
128 bits? In that case why not generate only 48 bits if the rest of the
bits are not used?

2. What is the purpose of having the blk_ctr and the seq_num used in the 
counter and reinitialized for every record packet? What do they protect
from?

3. What is the rationale behind constructing a counter block in the
given way? Why not use the full 128 bit IV? 

4. terminology: sometimes different than rfc2246. Say the abreviations 
PT block and CT block are never used in rfc2246. Also "nonce" could be
"random bytes" to match rfc2246.

5. At par 3.1.1. It says "A given counter block MUST never be
 used more than once with the same key.". But this is not up
 to the implementation to choose, thus must instead of MUST
 may be more appropriate.

6. Same paragraph: It gives a brief description of CTR, but I think
it can be confusing to somebody who doesn't know CTR. It says
"Each PT block is XORed with a block of the key stream to generate the
   ciphertext, CT.  The AES encryption of each counter block results in
   128 bits of key stream."
but nowhere before it was mentioned that CTR mode is supposed to 
generate a key stream.

regards,
Nikos Mavrogiannopoulos
Dondeti, Lakshminath | 5 Mar 09:06 2006

Review of draft-modadugu-dtls-short-00

Hi Nagendra,

I didn't understand a few things in the DTLS-SHORT spec., and have some questions for my clarification.

* Length field:

From the description, negotiating the length field is clear, but not how it affects the Record format.  Is the field completely eliminated and if so is an application layer length field assumed to be reused with the encoding specified?  Reusing another SEQ number might be ok, but I am not sure whether the specified encoding can always be imposed on the said SEQ number.  Any insight into this would be helpful.

* Length field verification:

Are you suggesting that a receiver try various guesses on the SEQ number and try them out with MAC verification?  Do you plan to specify any limitations on the number of attempts?

* Frequency of change cipher spec:

Ok, before I go into this, I am confused about the mapping between 2B epoch + 6B SEQ in DTLS vs. the various possible combinations of lengths for epoch and SEQ numbers in the table in DTLS-SHORT and the note "without shortening the actual sequence number."  Perhaps I am just dense, an explanation will help.

If in fact the shorter epoch, SEQ combinations are going to be used, does it mean there is a ChangeCipherSpec every 2^14 records in the smallest epoch+SEQ number case?

* Version field:

I have a naive question here (perhaps all of these are naive).  If the version field is indeed "mostly redundant" why not just remove it from the main DTLS spec?  Perhaps that field is in there for DTLS is TLS look-alike reasons?

* Length field:

Is the length field redundant because it can be calculated from length fields from elsewhere in a UDP packet, as long as there is only one record per fragment?

* implicit header (IH):

The list of fields to be excluded does not inlcude the epoch field.  Please explain.

If the SEQ and/or epoch fields are not included, could you explain how to maintain those in the presence/absence of application layer (e.g., RTP) numbers.

* Order of DTLS header fields in Section 6 (probably just editorial):

I am confused by the order of fields in Section 6 and its impact on the processing steps.

The original order of DTLS fields is as follows:

        ContentType type;
        ProtocolVersion version;
        uint16 epoch;               // New field
        uint48 sequence_number;       // New field
        uint16 length;

The order in Section 6 is as follows:

      Content type
      Version
      Length
      Sequence Number

Why is the order changed?

Perhaps it is an error?   It's probably just editorial as I can't think of any impact on processing steps as we are dealing with fixed headers.

* IH processing:

"The initial value of ESN (the expected sequence number) is set to 1 + (sequence number of the Finished message record), which should be the sequence number of the first application data record."

Why "first"?  Can there be more than one record in the packet?

* Trial decryption process:

Bear with me as I walk through the record receipt processing.  I see three cases: a record with
  Case 1) excluded the DTLS header, but encrypted from the beginning of the application layer header, or
  Case 2) a full DTLS header, or
  Case 3) excluded DTLS header and unencrypted application layer header (e.g., RTP, RTCP, or it could be anything really).

Case 3 could be interesting as I wonder whether there are any collisions between the DTLS header and another application layer header.  Another thing that comes to my mind is that there is no reason to stop a future application to come up with a payload structure that matches the above.  Perhaps it doesn't matter (I haven't worked through the possibilities in my mind), or to make things simple, DTLS-SHORT can be ruled out for such an application.

Dealing with cases 1 and 2 only, the receiver could try to parse the first 13 bytes as a DTLS header:

If the type matches allowed ContentTypes, it can sanity check the version, sequence number and length (just in case encrypted text matches the type field or something), decrypt using the sequence number as the IV (assuming counter mode), verify the MAC and if all is well pass the record up to the next layer.

If that fails, the receiver might try to parse the record as an RTP header (or other APP-Layer header); in case of RTP, it can extract the RTP-SEQ number from there, figure out the IV, verify the MAC and if all goes well, accept the record.  One corner case here is a burst loss of 2^16 or so records and that makes things slightly interesting.  I'd assume a few guesses on the IV (e.g., IV = higherOrderBits||RTP-SEQ, higherOrderBits+1||RTP-SEQ) could be tried.

If those two steps fail, another short cut might be to have a local policy that for a given DTLS connection, the record MUST contain either a DTLS header or a known APP-Layer header.  That might allow the receiver to simply discard the packet without any further processing.

Without such policy-based processing, an adversary may simply put random bits at the beginning of the record to confuse the receiver.  The concept of trying all sequence numbers based on a replay window might be very expensive.  First, that could mean generating as many keystreams as the length of the replay window, and second, even that might not be sufficient if you want to consider the possibility of records to the right side of the replay window.  Wouldn't it be a lot of processing without a definitive result?  In other words, if an application layer sequence number (a la RTP) is not present, is it possible that receivers might discard perfectly legitimate packets (assuming an adversary drops or a burst length -- L = replay window size -- packets) until one with an explicit DTLS header arrives?

I guess I would conclude that the encrypted MAC semantics of TLS/DTLS makes this difficult for the generic case.  Have you considered defining an extension to change that?

Editorial: Step 5 in the processing steps in the I-D needs clarification.  Why "prepend" an application_data header with a sequence number?  What does that mean?  That's not how the sender prepares the record.

Thanks in advance for your response.

best regards,
Lakshminath
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Eric Rescorla | 7 Mar 02:29 2006

Review of draft-dugal-tls-ecmqv-00

1. It would be nice somewhere around sections 1-2 to have an overview
of the inputs to ECMQV. In particular, the requirement for 
the client to have two key pairs--one of which is always
ephemeral--is sufficiently different from classic DH that
it makes sense to review here.

As usual, it would be nice to have some kind of ladder diagram
that summarizes the exchanges at an abstract level.

S 3.
As a practical matter, how likely is it that client and server
will share a group?

S 4.1.
What about DSA-signed certificates?

S 4.2.
As I understand this scheme, the ECMQV-capable ECDSA key in
the certificate is used to sign the server's ephemeral
ECMQV key. Unless I'm missing something, there's no security
reason why the server's static key needs to be an EC key
at all. It could just as well be an RSA key. True, the
server needs to communicate the group that the ephemeral
key is generated in but that could be sent in the ServerKeyExchange,
as in TLS/ECC. Have I missed something?

You write:

   The client retrieves the server's ephemeral ECMQV public key from the
   ServerKeyExchange message.

Probably worth mentioning that it needs to verify the SKE.

S 4.6.
Nit:    "demonstrate it's control". Should be "its"
Same error in 4.7.
Hasim al-Aidaros | 8 Mar 05:27 2006
Picon

Improving Bulk data transfer phase in TLS protocol, codes needed.

Dear TLS working group,
My name is Aidros doing Master study in University Putra Malaysia in SSL Development.
I'm glad to participate and share knowledge with you. This is the firs participation.
My project is to Improve Bulk data transfer phase performance (Record Layer) using Parallelism (reducing the processing time).
Unfortunately, Most of developing researchers focusing on Handshake phase improvement without touching data transfer phase.

Bulk data procedure after fragmentation:
1. Hashing the data using HMAC to calculate MAC value.
2. Encrypting the data plus the MAC value.

To simulate this process I would like to get:
the HMAC code followed by Encryption code,  i mean:
the code has three inputs: MAC key, Encryption key, IV if necessary and Data.
the one output : (MAC and Data) encrypted and time if available.
I search already in openssl-0.9.7i, but the Encryption, hashing and HMAC codes are all separated.
I hope you help me how to find this combination code at least you give me anyone contact for this matter.
Crypto algorithm preferred: AES or RC4 for Encryption, MD5 or SH1 for HMAC.


Thanks for your anticipation help.
we keep in touch.

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Vipul Gupta | 9 Mar 02:48 2006
Picon

Re: Review of draft-dugal-tls-ecmqv-00

I'm confused by this part of Section 4.6 which reads

" ... demonstrate it's control over the private half of the  
*certified* ECMQV
    public key"

because Section 4.5 appears to allow a case where the client has no
certified ECMQV key

  "If the client has sent a certificate with an MQV key, ecmqv_ephemeral
    will contain the client's ephemeral public key for the MQV  
operation;
    ***otherwise ecmqv_ephemeral will contain an ephemeral public key  
that
    is used as the ephemeral public key for the MQV operation and ecmqv
    will contain a second ECMQV public key which takes the place of the
    certified key***"

What am I missing?

vipul
Brian Minard | 10 Mar 15:45 2006

Re: Review of draft-dugal-tls-ecmqv-00

Section 4.6 only applies when the client has a suitable
certificate. In 4.5, the situation when the client cannot produce
a suitable certificate is similar to ECHDE except 2 emphemeral
keys are provided.

Does this improve 4.5:

   Actions of the sender:

      ecqmv_ephemeral MUST contain an ephemeral ECMQV public key.

      If the client has not sent a certificate with an
      ECMQV-capable key, then ecmqv MUST contain a second
      ephemeral ECMQV public key.

On Wed, Mar 08, 2006 at 05:48:55PM -0800, Vipul Gupta wrote:

> I'm confused by this part of Section 4.6 which reads
>
> " ... demonstrate it's control over the private half of the
> *certified* ECMQV public key"
>
> because Section 4.5 appears to allow a case where the client
> has no certified ECMQV key
>
>  "If the client has sent a certificate with an MQV key,
> ecmqv_ephemeral will contain the client's ephemeral public
> key for the MQV operation; ***otherwise ecmqv_ephemeral will
> contain an ephemeral public key that is used as the ephemeral
> public key for the MQV operation and ecmqv will contain a
> second ECMQV public key which takes the place of the certified
> key***"
>
> What am I missing?

Gmane