Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the WGLC

["Mark Tillinghast" <[e-mail]>]

I would like to remove the SHA-1 stuff completely.
Compatibility with SHA-1 is anathema to me. 

Mark
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Thursday, October 02, 2008 12:00
To: [e-mail]
Subject: TLS Digest, Vol 51, Issue 2

Send TLS mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

   1. Re:  New version of draft-ietf-tls-ecdhe-psk after the WGLC
      ([e-mail])
   2. Re:  New version of draft-ietf-tls-ecdhe-psk after the WGLC
      (Mohamad Badra)
   3. Re:  Last Call: draft-rescorla-tls-suiteb (Suite B Cipher
      Suites for TLS) to Informational RFC (Brian Minard)
   4. Re:  Last Call: draft-rescorla-tls-suiteb (Suite B Cipher
      Suites for TLS) to Informational RFC (Russ Housley)


----------------------------------------------------------------------

Message: 1
Date: Thu, 2 Oct 2008 11:29:21 +0300
From: <[e-mail]>
Subject: Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the
	WGLC
To: <[e-mail]>
Cc: [e-mail]
Message-ID:
	
<[e-mail]>
Content-Type: text/plain;	charset="iso-8859-1"

Mohamad Badra wrote:
> 
> Dear Pasi,
> 
>> The contents of the draft have changed quite a bit since version
>> -02 (which was posted just before the Dublin meeting), and I have
>> some comments about the changes:
> 
> 
> In fact, we discussed adding SHA256 and SHA348 to the document to
> avoid publishing several seperated documents; and if I recall well,
> your recommendation was to do that in one single document. If the
> group doesn't agree with this change, I will post the old version.

I think having them all in a single document is better; it's 
the other changes in -03 I commented.

>  > It's a bit surprising that
>  > e.g. TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, when negotiated in TLS
>  > 1.2, would use the TLS PRF with SHA-1 as the hash function. Note
>  > that e.g.  TLS_DHE_PSK_WITH_AES_128_CBC_SHA (from RFC 4279) would
>  > in this situation use the TLS PRF with SHA-256.
> 
> In this case, I would know where I can read that cipher suites
> described in RFC 4492, when negotiated in TLS 1.2, will use the TLS
> PRF with SHA-256. Do you refer to Section 5 of TLS 1.2?
> 
> The same for TLS_DHE_PSK_WITH_AES_128_CBC_SHA.

Yes, I'm referring to Section 5 of TLS 1.2.

>  > My suggestion would be to say that all these cipher suites can be
>  > negotiated with any TLS version; when used with TLS <1.2, they use
>  > the PRF from that version; when used with TLS >=1.2, they use the
>  > TLS PRF with SHA-256 or SHA-384. (In other words: they'd work the
>  > same way as the cipher suites in RFC 4492/4279/4785.)
>  >
>  > This change would probably allow us to remove the SHA-1 suites
>  > completely.
> 
> With regard to version 2 of the document, only SHA-1 suites are 
> described. So why we need to do this step?

I would ask it this way: if the document has SHA-256/384 based
suites, why does it need the SHA-1 suites?

(Cipher suites isn't one of those things where having more
is automatically better.)

>  > Also, while I can understand combining AES-128 with
>  > SHA-256, and AES-256 with SHA-384, I'm not sure why we need to
>  > combine NULL encryption with three different MACs...
> 
> In the case we are going to remove the SHA-1 suites with NULL
> encryption, only 2 combinations will be available (if we keep the
> logic of moving away from SHA-1 and towards stronger hash
> algorithms, as RFC 5288 and 5289 do).

Yes, but why do we need two combinations? What problem is solved
by having two, instead of just one?

Best regards,
Pasi


------------------------------

Message: 2
Date: Thu, 02 Oct 2008 11:57:48 +0200
From: Mohamad Badra <[e-mail]>
Subject: Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the
	WGLC
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Pasi,

[e-mail] wrote:
> Mohamad Badra wrote:
>> Dear Pasi,
>>
>>> The contents of the draft have changed quite a bit since version
>>> -02 (which was posted just before the Dublin meeting), and I have
>>> some comments about the changes:
>>
>> In fact, we discussed adding SHA256 and SHA348 to the document to
>> avoid publishing several seperated documents; and if I recall well,
>> your recommendation was to do that in one single document. If the
>> group doesn't agree with this change, I will post the old version.
> 
> I think having them all in a single document is better; it's 
> the other changes in -03 I commented.

OK.

> 
>>  > It's a bit surprising that
>>  > e.g. TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, when negotiated in TLS
>>  > 1.2, would use the TLS PRF with SHA-1 as the hash function. Note
>>  > that e.g.  TLS_DHE_PSK_WITH_AES_128_CBC_SHA (from RFC 4279) would
>>  > in this situation use the TLS PRF with SHA-256.
>>
>> In this case, I would know where I can read that cipher suites
>> described in RFC 4492, when negotiated in TLS 1.2, will use the TLS
>> PRF with SHA-256. Do you refer to Section 5 of TLS 1.2?
>>
>> The same for TLS_DHE_PSK_WITH_AES_128_CBC_SHA.
> 
> Yes, I'm referring to Section 5 of TLS 1.2.

OK.

> 
>>  > My suggestion would be to say that all these cipher suites can be
>>  > negotiated with any TLS version; when used with TLS <1.2, they use
>>  > the PRF from that version; when used with TLS >=1.2, they use the
>>  > TLS PRF with SHA-256 or SHA-384. (In other words: they'd work the
>>  > same way as the cipher suites in RFC 4492/4279/4785.)
>>  >
>>  > This change would probably allow us to remove the SHA-1 suites
>>  > completely.
>>
>> With regard to version 2 of the document, only SHA-1 suites are 
>> described. So why we need to do this step?
> 
> I would ask it this way: if the document has SHA-256/384 based
> suites, why does it need the SHA-1 suites?
> 
> (Cipher suites isn't one of those things where having more
> is automatically better.)


Unfortunately, these new arguments aren't presented in WGLC, which would

also have been applicable to the previous two versions.

I don't know, but don't we need a WG consensus on that change?

>>  > Also, while I can understand combining AES-128 with
>>  > SHA-256, and AES-256 with SHA-384, I'm not sure why we need to
>>  > combine NULL encryption with three different MACs...
>>
>> In the case we are going to remove the SHA-1 suites with NULL
>> encryption, only 2 combinations will be available (if we keep the
>> logic of moving away from SHA-1 and towards stronger hash
>> algorithms, as RFC 5288 and 5289 do).
> 
> Yes, but why do we need two combinations? What problem is solved
> by having two, instead of just one?

Which one do you suggest? and why only one of both?
(WRT RFC5288 and 5289 portfolio, I prefer keeping both of them,)

Best regards,
Badra



------------------------------

Message: 3
Date: Thu, 2 Oct 2008 08:00:45 -0400
From: Brian Minard <[e-mail]>
Subject: Re: [TLS] Last Call: draft-rescorla-tls-suiteb (Suite B
	Cipher Suites for TLS) to Informational RFC
To: "[e-mail]" <[e-mail]>
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Here are a couple of clarifications we'd like to see in the draft.


------------------------------

Message: 4
Date: Thu, 02 Oct 2008 11:22:49 -0400
From: Russ Housley <[e-mail]>
Subject: Re: [TLS] Last Call: draft-rescorla-tls-suiteb (Suite B
	Cipher Suites for TLS) to Informational RFC
To: Brian Minard <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Brian:

I'll post an update in a few minutes that includes more information 
on certification paths.

I am confused by your last paragraph.  ECDH_ECDSA is not discussed in 
this draft.  Only, ECDHE_ECDSA is used in this draft.

Russ

At 08:00 AM 10/2/2008, Brian Minard wrote:
>Here are a couple of clarifications we'd like to see in the draft.
>
> From section 4:
>    Server and client certificates used to establish a Suite
B-compliant
>    connection MUST be signed with ECDSA.  For certificates used at the
>    128-bit security level, the subject public key MUST use the P-256
>    curve, and the digital signature MUST be calculated using the P-256
>    curve and the SHA-256 hash algorithm.  For certificates used at the
>    192-bit security level, the subject public key MUST use the P-384
>    curve, and the digital signature MUST be calculated using the P-384
>    curve and the SHA-384 hash algorithm.
>
>Does this only apply to the client/server certificates or every
>certificate in the client/server chain?
>
>Can some guidance be added on certificate key usages and TLS 1.2 for
>Suite B
>(http://www.nsa.gov/ia/industry/Suite_B_Certificate_and_CRL_Profile_200
>80528.pdf)?
>This document clearly requires two different certificates and
>references NIST SP 800-56A (section 5.6.4.2) as the reason for this.
>
>I am wondering if you can confirm that the comment requiring two server
>certificates is directed at servers supporting both ECDH_ECDSA and
>ECDHE_ECDSA key exchange methods (i.e., completely different cipher
>suites). For example, if I deploy a server supporting only one of these
>key exchange methods, that server would only need one certificate.
>
>-----Original Message-----
>From: [e-mail] [mailto:ietf-announce-
>[e-mail]] On Behalf Of The IESG
>Sent: Thursday, September 25, 2008 11:30 AM
>To: IETF-Announce
>Subject: Last Call: draft-rescorla-tls-suiteb (Suite B Cipher Suites
>for TLS) to Informational RFC
> >
>The IESG has received a request from an individual submitter to
>consider
>the following document:
> >
>- 'Suite B Cipher Suites for TLS '
>    <draft-rescorla-tls-suiteb-06.txtas an Informational RFC
> >
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to
>the
>[e-mail] mailing lists by 2008-10-23. Exceptionally,
>comments may be sent to [e-mail] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
> >
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-06.txt
> >
> >
>IESG discussion can be tracked via
> >
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>=15530&rfc_flag=0
> >
>_______________________________________________
>IETF-Announce mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ietf-announce



------------------------------

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls


End of TLS Digest, Vol 51, Issue 2
**********************************
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls