Re: [TLS] Proposed working group charter update

Nikos Mavrogiannopoulos <nmav@gnutls.org> Mon, 11 April 2011 06:38 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=MZJF19nuyRK9nhvvkMyX+xQGY5KI7LoO1rKeqK8UduW4lLmuilvXC4nkb8p0XmlaS/ 23t4bJ8JvZGfxiQGwFObbBO0faBNg9WB7UVVLMzbIYDGNRchd2Fgx7hOT+Ompu4lDKpR TZeQkk5CzV1Gn7aHC6/kHW0miLg7WlRa9OdMA=
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4DA2A1E4.5020005@gnutls.org>
Date: Mon, 11 Apr 2011 08:38:28 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <5EA8CEC4-43EB-42A3-B189-D2DC33593AB0@cisco.com> <C1A2E067-F7E0-4AAD-96B6-4B28F12A49B4@vpnc.org> <BANLkTin_fvtzeKgjeyEZhdnxhDa=z_KDRA@mail.gmail.com>
In-Reply-To: <BANLkTin_fvtzeKgjeyEZhdnxhDa=z_KDRA@mail.gmail.com>
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tls@ietf.org
Subject: Re: [TLS] Proposed working group charter update
Precedence: list

On 04/11/2011 06:48 AM, Eric Rescorla wrote:
> On Sun, Apr 10, 2011 at 4:10 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> On Apr 10, 2011, at 2:25 PM, Joe Salowey wrote:
>>
>>> The primary goals of the WG are to maintain:
>>>  - The TLS protocol, RFC 5346;
>> That *could* be read to mean that the WG is not supposed to work on TLS 1.3. If that is the intention, then the charter should say so explicitly.
> I hope that's how it should be read. I don't see any pressing need for
> the TLS WG to do a TLS 1.3.

Over the years, I've kept a list of issues of TLS (apply to TLS 1.2).

(I skip all the issues already reported by Peter Gutmann at:
http://www.ietf.org/mail-archive/web/tls/current/msg07608.html )

* Renegotiation semantics are unclear. When one is supposed to
do renegotiation? How to distinguish data before a renegotiation
and after? (especially since application data are allowed
to be processed during a renegotiation). See also
http://www.ietf.org/mail-archive/web/tls/current/msg05607.html

* RFC6066 Max fragment size cannot be used to increase the TLS fragment,
thus punishing hardware accelerated implementations, that have
to stick to the maximum 16k header.

* The RFC6066 truncated HMAC extension is very limited as it
only truncates to 80-bits. It could be very useful especially
in DTLS where the fragment size is very limiting, but not
in its current form. 80-bits should be enough for everybody
is not very convincing. Common security levels should
be allowed at least (64/80/96/128/192/256). This extension
might belong to the core TLS protocol if it is ever made aware
of security levels.

* Short finished message signature fixed to 12 bytes. The provisioning
of TLS 1.2 for ciphersuites to increase it was never used
by ciphersuites that aimed high security levels (AES-256, HMAC-384),
thus it is pretty much already obsolete. It seems the finished
message size should be defined by the TLS protocol itself
to be usable. (this is another argument of TLS being made
aware of security levels).

* TLS version negotiation. If 1.1 and 1.3 is implemented, then
negotiation will always fail if talking to a 1.2 server. This
requires a client to implement all possible TLS protocols
instead of the latest and a fallback (e.g. TLS 1.0).

* AEAD interface was defined only for stream ciphers. If a block
cipher emerges for AEAD it will not be usable with TLS.

* It is not known when is record version acceptable. Is a record
version of 3.55 acceptable? Is 4.0 acceptable? What about 65.35?
There should be at least a ranges of acceptable record version
numbers (for the initial hello message).

Thus for me there should be work to solve those issues.

regards,
Nikos

[TLS] Proposed working group charter update Joe Salowey
Re: [TLS] Proposed working group charter update Robert Cragie
Re: [TLS] Proposed working group charter update Paul Hoffman
Re: [TLS] Proposed working group charter update Eric Rescorla
Re: [TLS] Proposed working group charter update Nikos Mavrogiannopoulos
Re: [TLS] Proposed working group charter update Peter Gutmann
Re: [TLS] Proposed working group charter update Nikos Mavrogiannopoulos
Re: [TLS] Proposed working group charter update Marsh Ray
Re: [TLS] Proposed working group charter update Paul Hoffman
Re: [TLS] Proposed working group charter update Nico Williams
Re: [TLS] Proposed working group charter update Peter Saint-Andre
Re: [TLS] Proposed working group charter update Marsh Ray
Re: [TLS] Proposed working group charter update Yoav Nir
Re: [TLS] Proposed working group charter update Nikos Mavrogiannopoulos
Re: [TLS] Proposed working group charter update Martin Rex
Re: [TLS] Proposed working group charter update Paul Hoffman
Re: [TLS] Proposed working group charter update Martin Rex
Re: [TLS] Proposed working group charter update Nico Williams
Re: [TLS] Proposed working group charter update Yoav Nir
Re: [TLS] Proposed working group charter update Martin Rex
Re: [TLS] Proposed working group charter update Nico Williams
Re: [TLS] Proposed working group charter update Peter Gutmann
Re: [TLS] Proposed working group charter update Joe Salowey
Re: [TLS] Proposed working group charter update Marsh Ray
Re: [TLS] Proposed working group charter update Nikos Mavrogiannopoulos
Re: [TLS] Proposed working group charter update Nikos Mavrogiannopoulos
Re: [TLS] Proposed working group charter update Eric Rescorla
Re: [TLS] Proposed working group charter update Peter Gutmann