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

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

I would like to offer this as aligned proposed wording of section 5,
security considerations.
Thank You,
Mark

> Hello,
> 
> I am good with this:
> 
>    Given the current state of published to date crypto attacks,
>    HMAC-SHA1 apparently is not (yet) so bad that we need to risk
>    breaking interoperability with previous versions of protocols.
>    However, implementers and administrators should monitor the general
>    statements on recommended cryptographic algorithms published from
>    time to time by various forums including the IETF, as a base for
>    the portfolio they support and the policies for strength of
function 
>    acceptable for the cipher suites they set.
> 
> If this emendation is ok with you, lets target it into the current 
> discussion and see where else this kind of admonishment can apply.
>
> Thanks for all your help,
> Mark

Agreed.

  Alfred. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Friday, October 03, 2008 12:00
To: [e-mail]
Subject: TLS Digest, Vol 51, Issue 3

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
      (Mark Tillinghast)
   2.  New Version Notification for draft-rescorla-tls-suiteb-07
      (Russ Housley)
   3. Re:  New version of draft-ietf-tls-ecdhe-psk after the WGLC
      (Alfred H?nes)


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

Message: 1
Date: Thu, 2 Oct 2008 12:13:39 -0700
From: "Mark Tillinghast" <[e-mail]>
Subject: Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the
	WGLC
To: <[e-mail]>
Message-ID:
	
<[e-mail]
as.com>
	
Content-Type: text/plain;	charset="us-ascii"

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
**********************************


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

Message: 2
Date: Fri, 03 Oct 2008 13:44:23 -0400
From: Russ Housley <[e-mail]>
Subject: [TLS] New Version Notification for
	draft-rescorla-tls-suiteb-07
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"; format=flowed


>From: IETF I-D Submission Tool <[e-mail]>
>To: [e-mail]
>Cc: [e-mail],[e-mail]
>Subject: New Version Notification for draft-rescorla-tls-suiteb-07
>Date: Thu,  2 Oct 2008 09:21:06 -0700 (PDT)
>
>A new version of I-D, draft-rescorla-tls-suiteb-07.txt has been 
>successfuly submitted by Russ Housley and posted to the IETF
repository.
>
>Filename:       draft-rescorla-tls-suiteb
>Revision:       07
>Title:          Suite B Cipher Suites for TLS
>Creation_date:  2008-10-02
>WG ID:          Independent Submission
>Number_of_pages: 11
>
>Abstract:
>The United States Government has published guidelines for "NSA Suite
>B Cryptography", which defines cryptographic algorithm policy for
>national security applications.  This document defines a profile of
>TLS which is conformant with Suite B.



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

Message: 3
Date: Fri, 3 Oct 2008 20:44:18 +0200 (MESZ)
From: Alfred H?nes <[e-mail]>
Subject: Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the
	WGLC
To: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=hp-roman8

At Thu, 2 Oct 2008 12:13:39 -0700, Mark Tillinghast wrote:
>
> I would like to remove the SHA-1 stuff completely.
> Compatibility with SHA-1 is anathema to me.
> 
> Mark

Mark, could you please explain why this argument has not been
raised during WGLC, when the draft *only* contained backwards
compatible cipher suites that could also be supported in
previous versions of TLS that lack support of SHA-2 ?
The draft was intended to complement RFC 4279 and RFC 4785
in an equivalent manner with the ECC [1] based key exchanges
from RFC 4492, and as such had been adopted as a WG work item.

And why have similar arguments not been raised before the
publication of RFC 5246 and other recent documents ?
If I understand your reasoning, consequently TLS 1.2 ought
to have deprecated all pre-existent TLS cipher suites using
SHA-1 and covered by that document, as should have RFC 5288
and 5289 for the respectively related earlier cipher suites.
Did you mean that?

I am posting this message because, if I recall correctly,
the recent additions are based on a question I had raised
during WGLC, which triggered a discussion thread.  This would
perhaps have been the proper time to make your voice audible.

As a follow-up, the TLS session in Dublin has consented to
solicit an update of the draft taking the WGLC comments into
proper consideration, and to then forward it to the IESG.
The first step has been done.
The author has judged to include the SHA-2 cipher suites
taking into account that, after the draft had been delayed
by a busy working group until TLS 1.2 had been completed,
this would be now be a commensurate step forward.
Reading the diffs I cannot see that the updated draft
violates the rough consensus achieved at WGLC.  The
additions look clearly structured and follow the spirit
of the previous versions in a straightforward manner.

I am not aware of any recent striking developments in
cryptanalysis since the WGLC that would necessitate an
immediate fundamental reconsideration.  The NIST reportedly
intends to support SHA-1 for more than two years to come.
The primary use of it here anyway is within HMAC -- and that's
commonly still considered not being attacked successfully.
Other IETF WGs currently even hesitate to remove MD-2 and MD-5
from document updates in progress, because they want to leave
the decision to the deployment and the applications using
theirs specifications.  Equally, the PSK cipher suites are
targetted at managed environments that should be able to make
educated decisions on which cryptographic strenght they need.

Mark, therefore I kindly ask you to study the "Working Group
Guidelines and Procedures" (BCP 25, RFC 2418) before you try
to disrupt these procedures.  Thanks.


Kind regards,
  Alfred.

-- 

P.S.: [1]
An interesting (less technical) reading about the development and
the socialization of ECC can be found in a recent research paper
from two of the 'cradles of ECC' :
  A. H. Koblitz, N. Koblitz & A. Menezes; "Ellitic Curve Cryptography:
  The Serpentine Course of a Paradigm Shift";
  Univ. of Washington / Univ. of Waterloo; Aug 2008, revised Sep 2008
available at:
  <http://www.cacr.math.uwaterloo.ca/techreports/2008/cacr2008-19.pdf>
Have a nice reading!  { The authors must also have visited IETF
meetings and followed WG discussions.  :-)  }
If in hurry, skip to Section 13 and look into the mirror.   :-)

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



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

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


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