headers
Eric Rescorla | 5 Apr 2004 22:53

TLS IANA considerations

TLS 1.1 really should have an IANA considerations section.

I suggest the following changes to RFC 2246, modelled on
Scott's text for the compression draft:

(1) Replace the first two "Note"s of S A.5  with:

    The cipher suite space is divided into three regions:

    1. Cipher suite values with first byte 0x00 (zero)
       through decimal 191 (0xBF) inclusive are reserved for the IETF
       Standards Track protocols.

    2. Cipher suite values with first byte decimal 192 (0xC0)
       through decimal 254 (0xFE) inclusive are reserved
       for assignment for non-Standards Track methods.

    3. Cipher suite values with first byte 0xFF are 
       reserved for private use.

    Additional information describing the role of IANA in the
    allocation of cipher suite code points is described
    in section XXX.

(2) Add an IANA Considerations section:

   Section XXX of this document describes a registry of ciphers suite
   identifiers to be maintained by the IANA, as well as defining a
   number of such cipher suite identifiers. Cipher suite values with the
   first byte in the range 0-191 (decimal) inclusive are assigned via
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 5 Apr 2004 22:57

Premature closes and the session cache

A while back Jostein Tveit suggested that it would
be a good idea to allow sessions to be resumed even
if a connection from that session had been closed
with a Premature Close.

I'd like to see some discussion about this proposed
change. Unless there's a strong consensus that we
should make the change, I would prefer to leave TLS
as-is...

-Ekr
Permalink | Reply | 7 comments |
headers
Eric Rescorla | 5 Apr 2004 22:58

Pre-shared Keys

Folks, 

We have two TLS shared key proposals on the table and they've
both seen almost no discussion. Consider this a call for 
comments/comparisons on the two protocols.

-Ekr
Permalink | Reply | 9 comments |
headers
Tim Dierks | 5 Apr 2004 23:09
Picon

Re: TLS IANA considerations

On Mon, 05 Apr 2004 13:53:40 -0700, Eric Rescorla <ekr <at> rtfm.com> wrote:
>     1. Cipher suite values with first byte 0x00 (zero)
>        through decimal 191 (0xBF) inclusive are reserved for the IETF
>        Standards Track protocols.
> 
>     2. Cipher suite values with first byte decimal 192 (0xC0)
>        through decimal 254 (0xFE) inclusive are reserved
>        for assignment for non-Standards Track methods.
> 
>     3. Cipher suite values with first byte 0xFF are
>        reserved for private use.

I think it's a good idea to add this section.

However, I don't know why we should construct a partition between 1. &
2.; why not just allocate them out of the same space?

Given the amount of time it takes to get an RFC approved, it probably
makes sense for there to be a way for implementors to carve out
proposed allocations without fear of collision. Otherwise, they've got
to use the reserved space, then switch a bunch of clients to allocated
space later. (I believe this happened when some ECC ciphersuites
collided with some AES ciphersuites.)

 - Tim
Permalink | Reply | 0 comments |
headers
Robert R. Gilman | 6 Apr 2004 00:20
Favicon

Re: Premature closes and the session cache

I believe the major problem with destroying the session information
when a connection is unexpectedly closed is that it amplifies the
recovery costs from a denial of service attack.  Inasmuch as the
security of a resumed session is not compromised, I support the
suggested change.
-Bob
----------------------------------------------------
Bob Gilman       rrg <at> avaya.com      +1 303 538 3868

Eric Rescorla wrote:
> A while back Jostein Tveit suggested that it would
> be a good idea to allow sessions to be resumed even
> if a connection from that session had been closed
> with a Premature Close.
> 
> I'd like to see some discussion about this proposed
> change. Unless there's a strong consensus that we
> should make the change, I would prefer to leave TLS
> as-is...
> 
> -Ekr
> 
> 
> 
>      
>
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 6 Apr 2004 11:04
Picon

RE: TLS IANA considerations


Hi,

I agree that an IANA considerations section is needed.
Currently, TLS internet-drafts have just picked numbers, 
and this has caused collisions on several occasions.

A couple of questions:

1) Do you think the 255 range for private use is sufficient for
pre-RFC implementation work, or should something be done to
allow getting real numbers before RFC publication? Maybe
something like draft-kompella-zinin-early-allocation-00.txt?

2) Almost all current I-D that define ciphersuites have already
picked values from the 0 range (ECC, Camellia, SRP, OpenPGP,
GOST).  Are all of them intended for standards track,
or are documents that end up as Information required to
pick new numbers?

3) TLS contains some other numbers in addition to ciphersuites
that might be suitable for IANA allocation. A quick glance found
at least the following: ContentType, HandshakeType, AlertLevel, AlertDescription, and
ClientCertificateType. Probably Standards 
Action or IETF Consensus policy would be ok for them?

Out of curiosity, I put together a first sketch what the IANA 
TLS registry could contain (attached below); especially the
ciphersuite list looks like a mess :-)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Rescorla | 6 Apr 2004 16:25

Re: TLS IANA considerations

<Pasi.Eronen <at> nokia.com> writes:
> I agree that an IANA considerations section is needed.
> Currently, TLS internet-drafts have just picked numbers, 
> and this has caused collisions on several occasions.
>
> A couple of questions:
>
> 1) Do you think the 255 range for private use is sufficient for
> pre-RFC implementation work, or should something be done to
> allow getting real numbers before RFC publication? Maybe
> something like draft-kompella-zinin-early-allocation-00.txt?
I think these are two separate questions.

I think that a range of 255 is fine for private use.
I don't have a problem with early allocation for things that
are destined for public ues.

> 2) Almost all current I-D that define ciphersuites have already
> picked values from the 0 range (ECC, Camellia, SRP, OpenPGP,
> GOST).  Are all of them intended for standards track,
> or are documents that end up as Information required to
> pick new numbers?
Some of them have requested standards track. It's not clear
whather that's their ultimate fate.

If someone can make a strong case that their protocol, while
Informational, is widely deployed and so they need their
ciphersuite #s for compatibility, I don't think that's crazy,
as a grandfathering measure...
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Jablon | 6 Apr 2004 17:56
Favicon

Re: Pre-shared Keys (or Passwords)

I see one shared password proposal, draft-ietf-tls-srp-06, and one
shared key proposal, draft-ietf-tls-sharedkeys-02.

As they primarily address different problems, they can be considered
independently, although it may be helpful to some to compare the differences.

If the primary goal is to achieve any of the security objectives of TLS,
using a shared password in place of the key in the shared key
proposal is not likely to meet that goal. In contrast, the shared-password
proposal can use either shared passwords, shared keys, or shared keys
where the randomness is limited to that of a password, as authenticators
without compromising security. However, the Security Considerations
section of draft-ietf-tls-srp-06 should be amended to discuss measures
to limit on-line guessing.

If the primary goal is to minimize CPU consumption when using a high-grade
pre-shared key (for example, with 80 independently random bits), then the
proposal in draft-ietf-tls-sharedkeys-02 achieves that goal, without sacrificing
basic security objectives. However, the shared-key proposal needs to be
amended to strongly discourage, rather than encourage, use of
passwords as keys for that method.

-- David

At 01:58 PM 4/5/04 -0700, Eric Rescorla wrote:
>Folks, 
>
>We have two TLS shared key proposals on the table and they've
>both seen almost no discussion. Consider this a call for 
>comments/comparisons on the two protocols.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dondeti, Lakshminath | 6 Apr 2004 18:27

Re: Pre-shared Keys (or Passwords)

There is another PSK based proposal similar to tls-sharedkeys: 
http://www.ietf.org/internet-drafts/draft-eronen-tls-psk-00.txt

regards,
Lakshminath

David Jablon wrote:

>I see one shared password proposal, draft-ietf-tls-srp-06, and one
>shared key proposal, draft-ietf-tls-sharedkeys-02.
>
>As they primarily address different problems, they can be considered
>independently, although it may be helpful to some to compare the differences.
>
>If the primary goal is to achieve any of the security objectives of TLS,
>using a shared password in place of the key in the shared key
>proposal is not likely to meet that goal. In contrast, the shared-password
>proposal can use either shared passwords, shared keys, or shared keys
>where the randomness is limited to that of a password, as authenticators
>without compromising security. However, the Security Considerations
>section of draft-ietf-tls-srp-06 should be amended to discuss measures
>to limit on-line guessing.
>
>If the primary goal is to minimize CPU consumption when using a high-grade
>pre-shared key (for example, with 80 independently random bits), then the
>proposal in draft-ietf-tls-sharedkeys-02 achieves that goal, without sacrificing
>basic security objectives. However, the shared-key proposal needs to be
>amended to strongly discourage, rather than encourage, use of
>passwords as keys for that method.
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Rescorla | 6 Apr 2004 18:34

Re: Pre-shared Keys (or Passwords)

Dondeti, Lakshminath <ldondeti <at> nortelnetworks.com> wrote:

> There is another PSK based proposal similar to tls-sharedkeys:
> http://www.ietf.org/internet-drafts/draft-eronen-tls-psk-00.txt

Quite so. This and the Gutmann proposal are the ones to which
I was referring. 

David Jablon writes:
>
>If the primary goal is to minimize CPU consumption when using a high-grade
>pre-shared key (for example, with 80 independently random bits), then the
>proposal in draft-ietf-tls-sharedkeys-02 achieves that goal, without sacrificing
>basic security objectives. However, the shared-key proposal needs to be
>amended to strongly discourage, rather than encourage, use of
>passwords as keys for that method.

David raises an important point, which is how we should behave
with respect to human-readable passwords used as shared
keys, but AFAICT that's an orthogonal issue to the question
of how we handle a shared key when we have it, which
is the difference between the shared-keys and the tls-psk
proposals.

-ekr
Permalink | Reply | 2 comments |

Gmane