headers
Win Treese | 5 Jul 2002 19:32
Picon
Favicon

closed last call on Extensions to TLS


The last call period for "Transport Layer Security (TLS) Extensions by
Simon Blake-Wilson et al. (draft-ietf-tls-extensions-04.txt)"

An updated document with the changes described on the mailing list will
be submitted to the IESG for consideration as a Proposed Standard when
it is available.

Win Treese
Chair, TLS working group
treese <at> acm.org

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Nikos Mavroyanopoulos | 12 Jul 2002 12:26

draft-ietf-tls-openpgp-keys

 Currently we have two internet drafts that both describe a way to
use TLS with openpgp keys. The differences between them seem to be
artistic[0], and can be concluded to whether the extension mechanism
should be used, or new ciphersuites should be defined.

Now both of them have a working implementation, and this shows that
there is indeed interest in TLS with openpgp keys.

So I'd like to ask the TLS WG, if there are any objections against TLS with 
openpgp keys? Is there any interest to move any of these drafts to RFC
status?

If we decide that this functionality is needed and requested, we can proceed 
and choose which one to move. But I believe that this should be done later,
in a technical discussion.

Since the reason of not moving any of these drafts to RFC status was the 
lack of support, if you support any of these drafts, please express your 
support in the ietf-tls mailing list.

PS. the drafts can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-01.txt

[0]. I have a strong objection against the keyID as used in the 
draft-ietf-tls-openpgp-02.txt, but this is rather technical and can
be discussed afterwards.

--

-- 
Nikos Mavroyanopoulos
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 24 Jul 2002 18:10

CBC Fix Round 2: Explicit IVs

After going over the discussion of CBC in June, I propose we
make the following change for TLS 1.1.

(1) BlockCipher becomes:

    block-ciphered struct {
        opaque iv[block size];
        opaque content[TLSCompressed.length];
        opaque MAC[CipherSpec.hash_size];
        uint8 padding[GenericBlockCipher.padding_length];
        uint8 padding_length;
    } GenericBlockCipher;

(2) The IV must be pseudorandomly generated. We suggest but do
not require that you use one of the following methods.

    (a) Pseudo-randomly generate the IV.
    (b) Pseudo-randomly generate a dummy plaintext block and
	encrypt it as the first plaintext block. (This has
	the advantage that it doesn't require you to be able
	to reset the IV for block cipher operations which is
	a problem with some hardware).
    (c) Use a fixed block or a counter as a dummy plaintext
	block. (I'm not completely sure this is safe but
	I'm looking into it. Comments welcome.)

(3) The receiver can either:
    (a) Set the IV to iv and decrypt content.
    (b) Decrypt the string (iv || content) and strip the
	first plaintext block.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Housley, Russ | 24 Jul 2002 18:29

Re: CBC Fix Round 2: Explicit IVs

Eric:

It is time to put this issue to bed.  I agree with your proposal.

I am not completely sure what you mean by (2)(c).

Are you suggesting that the IV be generated by encrypting a constant with 
the traffic key?  I would rather not use this approach.  It is exactly the 
information that an attacker needs to mount a dictionary attack.

Are you suggesting that the IV be generated by encrypting a counter with 
the traffic key?  I think that this is acceptable if the counter is 
initialized to a random value ( that has the same size as the block size).

Are you suggesting that the IV be generated by encrypting a counter with a 
locally generated key?  I see no problem here.  I prefer this one to the 
possible interpretations.

Russ

At 09:10 AM 7/24/2002 -0700, Eric Rescorla wrote:
>After going over the discussion of CBC in June, I propose we
>make the following change for TLS 1.1.
>
>(1) BlockCipher becomes:
>
>     block-ciphered struct {
>         opaque iv[block size];
>         opaque content[TLSCompressed.length];
>         opaque MAC[CipherSpec.hash_size];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 24 Jul 2002 18:38

Re: CBC Fix Round 2: Explicit IVs

"Housley, Russ" <rhousley <at> rsasecurity.com> writes:
> I am not completely sure what you mean by (2)(c).
> 
> Are you suggesting that the IV be generated by encrypting a constant with 
> the traffic key?  I would rather not use this approach.  It is exactly the 
> information that an attacker needs to mount a dictionary attack.
I see your point though I'd note that in general it's pretty easy to
mount a dictionary attack on TLS anyway, since the Finished messages
have a fixed 5-byte prefix and most of the protocols we're using
have relatively predictable first messages.

> Are you suggesting that the IV be generated by encrypting a counter with 
> the traffic key?  I think that this is acceptable if the counter is 
> initialized to a random value ( that has the same size as the block size).
I agree that this is superior and no more work.

> Are you suggesting that the IV be generated by encrypting a counter with a 
> locally generated key?  I see no problem here.  I prefer this one to the 
> possible interpretations.
I'd categorize this under (2)(a), cryptographically secure PRNGs.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane