headers
EKR | 1 Jun 2005 02:15

Re: I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt

"Yngve Nysaeter Pettersen" <yngve <at> opera.com> writes:

> Hello all,
>
> A couple of question and comments:
>
> Sec. 6 says "If a TLS implementation receives a record type it does not
> understand, it SHOULD just ignore it."
>
> If such a record is received after the parties have started encrypting
> the  records, should it try to decrypt the data, or should the
> implementation  throw the record away immediately?

Well, for RC4 you have to at least skip ahead to the next
section of keystream. With the block ciphers in TLS 1.1 you
can just discard the record. Otherwise, I think it's implementation
dependent.

> Sec A.5 specifically forbids the negotiation of 40 bit export ciphers.
>
> Does this also apply to the 56 bit export ciphers that was defined
> just  before the export restrictions were eased? My reading of the
> document  indicates "Yes". But should not also the single DES suites
> (e.g.  TLS_RSA_WITH_DES_CBC_SHA) and perhaps also IDEA also be phased
> out in a  similar manner?

My read of this is no.

> About compatibility: Back in August/September 2004 Opera Software
> performed a test where we released a Technology Preview version of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Yngve N. Pettersen (Developer Opera Software ASA | 1 Jun 2005 03:38
Picon
Favicon

Re: I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt

On Tue, 31 May 2005 17:15:33 -0700, EKR <ekr <at> networkresonance.com> wrote:

> "Yngve Nysaeter Pettersen" <yngve <at> opera.com> writes:
>
>> Hello all,
>>
>> A couple of question and comments:
>>
>> Sec. 6 says "If a TLS implementation receives a record type it does not
>> understand, it SHOULD just ignore it."
>>
>> If such a record is received after the parties have started encrypting
>> the  records, should it try to decrypt the data, or should the
>> implementation  throw the record away immediately?
>
> Well, for RC4 you have to at least skip ahead to the next
> section of keystream. With the block ciphers in TLS 1.1 you
> can just discard the record. Otherwise, I think it's implementation
> dependent.

OK.

>> About compatibility: Back in August/September 2004 Opera Software
>> performed a test where we released a Technology Preview version of
>> Opera  with TLS 1.1 and TLS Extensions enabled. During this test our
>> users  identified more than 120 services (including major banks) that
>> did not  interoperate with a client using either TLS 1.1 or TLS
>> Extensions, or  both. I have so far not been able to find out what is
>> causing the problem.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 1 Jun 2005 06:03

Re: I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve <at> opera.com> writes:
> Yes. The mentioned servers (or their surround support systems) did not
> tolerate clients that used TLS 1.1, or TLS extensions, or both. The
> most  common response (but not the only one) to a Client Hello
> including one or  both of them is to shut down the connection, without
> any alert messages  whatsoever.
>
> There are a number of variations, some servers would accept either,
> but  not both; others would accept TLS 1.1 and extensions, but not TLS
> 1.0 with  extensions, and so on. I classified 5 major types of
> problems.
>
> Some minor variations also existed: One TLS 1.0 capable server
> actually  negotiated SSL v3 when the client asked for TLS 1.1. Another
> used an  incorrect version number (the negotiated) when checking the
> RSA Premaster  Secret.
>
> In one case I saw one server that initially only cut the connection
> when a  TLS 1.1 Hello was sent change to also cutting the connection
> when TLS  Extensions were used, a few weeks later.
>
> See the top post in
> http://my.opera.com/forums/showthread.php?s=&threadid=65055 for more
> examples.
>
> For those interested, Opera 8.0 ships with TLS 1.1 (it still support
> export ciphers) and TLS Server Name Extension support, both controlled
> by  the TLS 1.1 setting, which is disabled by default.

Hmm... That's too bad to hear. That said, I think the documentation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 2 Jun 2005 18:25

ANNOUNCE: PureTLS 0.9b5

ANNOUNCE: PureTLS version 0.9b5
Copyright (C) 1999-2005 Claymore Systems, Inc.

http://www.rtfm.com/puretls

DESCRIPTION
PureTLS is a free Java-only implementation of the SSLv3 and TLSv1
(RFC2246) protocols. PureTLS was developed by Eric Rescorla for
Claymore Systems, Inc, but is being distributed for free because we
believe that basic network security is a public good and should be a
commodity. PureTLS is licensed under a Berkeley-style license, which
basically means that you can do anything you want with it, provided
that you give us credit.

This is a beta release of PureTLS. Although it has undergone a fair
amount of testing and is believed to operate correctly, it no doubt contains 
significant bugs, which this release is intended to shake out. Please
send any bug reports to the author at <ekr <at> rtfm.com>.

CHANGES FROM B4
* SECURITY: Zero OPTIONAL values before parsing. This prevents 
  bleedthrough of those values from previously parsed certificates
  into certificates where they are missing. This is a workaround for a 
  bug in the Cryptix ASN.1 kit.

  The only relevant values are Extensions and Algorithm.Parameters.
  In practice this should not be a problem with Algorithm.Parameters
  Since they're NULL in RSA certificates and always present in real 
  DSA certificates. If you rely on Extensions you should upgrade
  as soon as possible.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 2 Jun 2005 19:25

ANNOUNCE: PureTLS 0.9b5

ANNOUNCE: PureTLS version 0.9b5
Copyright (C) 1999-2005 Claymore Systems, Inc.

http://www.rtfm.com/puretls

DESCRIPTION
PureTLS is a free Java-only implementation of the SSLv3 and TLSv1
(RFC2246) protocols. PureTLS was developed by Eric Rescorla for
Claymore Systems, Inc, but is being distributed for free because we
believe that basic network security is a public good and should be a
commodity. PureTLS is licensed under a Berkeley-style license, which
basically means that you can do anything you want with it, provided
that you give us credit.

This is a beta release of PureTLS. Although it has undergone a fair
amount of testing and is believed to operate correctly, it no doubt contains 
significant bugs, which this release is intended to shake out. Please
send any bug reports to the author at <ekr <at> rtfm.com>.

CHANGES FROM B4
* SECURITY: Zero OPTIONAL values before parsing. This prevents 
  bleedthrough of those values from previously parsed certificates
  into certificates where they are missing. This is a workaround for a 
  bug in the Cryptix ASN.1 kit.

  The only relevant values are Extensions and Algorithm.Parameters.
  In practice this should not be a problem with Algorithm.Parameters
  Since they're NULL in RSA certificates and always present in real 
  DSA certificates. If you rely on Extensions you should upgrade
  as soon as possible.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory S. Chudov | 3 Jun 2005 20:00
Picon
Favicon

Re: draft-chudov-cryptopro-tlsprfneg-00.txt

Greetings.
Unfortunately, TLS does not allow a ciphersuite to choose a different PRF.

Quote from rfc2246:

   HMAC can be used with a variety of different hash algorithms. TLS
   uses it in the handshake with two different algorithms: MD5 and SHA-
   1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
   data). Additional hash algorithms can be defined by cipher suites and
   used to protect record data, but MD5 and SHA-1 are hard coded into
   the description of the handshaking for this version of the protocol.

So adding a cipher suite, which uses different PRF means breaking a
protocol.
Such cipher suites will not be "legitimate" without the support and analysis
from
this working group.

Good luck!
Greg Chudov

----- Original Message ----- 
From: <Pasi.Eronen <at> nokia.com>
To: <ekr <at> rtfm.com>; <tls <at> ietf.org>
Sent: Monday, May 30, 2005 8:58 AM
Subject: RE: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt

Hi,

It does seem that having a way to use some other PRF than the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kais Belgaied | 3 Jun 2005 20:10
Picon

Re: draft-chudov-cryptopro-tlsprfneg-00.txt

Gregory S. Chudov wrote:
> Greetings.
> Unfortunately, TLS does not allow a ciphersuite to choose a different PRF.
> 
> Quote from rfc2246:
> 
>    HMAC can be used with a variety of different hash algorithms. TLS
>    uses it in the handshake with two different algorithms: MD5 and SHA-
>    1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
>    data). Additional hash algorithms can be defined by cipher suites and
>    used to protect record data, but MD5 and SHA-1 are hard coded into
>    the description of the handshaking for this version of the protocol.
> 
> So adding a cipher suite, which uses different PRF means breaking a
> protocol.

or introduce the new/negotiated PRF with a new minor version number of the
protocol: TLS1.1

	Kais.

> Such cipher suites will not be "legitimate" without the support and analysis
> from
> this working group.
> 
> Good luck!
> Greg Chudov
>
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 3 Jun 2005 21:59
Picon
Favicon

I-D ACTION:draft-ietf-tls-rfc2246-bis-12.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 Version 1.1
	Author(s)	: T. Dierks, E. Rescorla
	Filename	: draft-ietf-tls-rfc2246-bis-12.txt
	Pages		: 91
	Date		: 2005-6-3
	
This document specifies Version 1.1 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-rfc2246-bis-12.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-rfc2246-bis-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jostein Tveit | 6 Jun 2005 13:23
Picon
Picon
Favicon

Re: I-D ACTION:draft-ietf-tls-rfc2246-bis-09.txt

Eric Rescorla <ekr <at> rtfm.com> writes:

> Jostein Tveit <josteitv <at> pvv.ntnu.no> writes:
>
>> Section 6.3:
>>>   Implementation note:
>>>       The currently defined which requires the most material is
>>>       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
>>
>> I think "cipher spec" is missing from this sentence.
>
> Thanks.

This typo is still present in draft-ietf-tls-rfc2246-bis-12.txt.

Regards,
--

-- 
Jostein Tveit <josteitv <at> pvv.ntnu.no>
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 6 Jun 2005 13:42
Picon

RE: draft-chudov-cryptopro-tlsprfneg-00.txt

Gregory S. Chudov wrote:
> 
> Greetings.
> Unfortunately, TLS does not allow a ciphersuite to choose a 
> different PRF.
> 
> Quote from rfc2246:
> 
>    HMAC can be used with a variety of different hash algorithms. 
>    TLS uses it in the handshake with two different algorithms: 
>    MD5 and SHA-1, denoting these as HMAC_MD5(secret, data) 
>    and HMAC_SHA(secret, data). Additional hash algorithms can 
>    be defined by cipher suites and used to protect record data, 
>    but MD5 and SHA-1 are hard coded into the description of the 
>    handshaking for this version of the protocol.
> 
> So adding a cipher suite, which uses different PRF means 
> breaking a protocol. Such cipher suites will not be "legitimate" 
> without the  support and analysis from this working group.

I fully agree: a ciphersuite cannot (and definitely should not)
just decide by itself to change that part of RFC 2246. But if 
we (TLS WG) decide to work on alternative PRFs, we will anyway 
need a document that updates this part of RFC 2246/2246bis 
somehow. 

The main alternatives seem to be defining PRF to be a property
that can be negotiated separately from the ciphersuite (and thus
we need a new negotiation mechanism, as proposed in your draft),
or defining PRF to be associated with the ciphersuite (so we can
(Continue reading)

Permalink | Reply | 501 comments |

Gmane