Subject: Re: Last Call: <draft-salter-rfc5430bis-01.txt> (Suite B Profile for Transport Layer Security (TLS)) to Informational RFC

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 03 Oct 2011 23:28:24 +0200

On 10/03/2011 10:55 PM, The IESG wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Suite B Profile for Transport Layer Security (TLS)'
>    <draft-salter-rfc5430bis-01.txt>  as 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
> [email-masked] mailing lists by 2011-10-31. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

A comment on this draft is that it might be misleading on the security 
levels it claims. It mentions:
   "The Fact Sheet on Suite B Cryptography requires key establishment and
    authentication algorithms based on Elliptic Curve Cryptography and
    encryption using AES [AES].  Suite B algorithms are defined to
    support two minimum levels of security: 128 and 192 bits."

However the (D)TLS Finished message is protected by a 96-bit MAC, thus 
an attacker that can break a 96-bit MAC can manipulate the TLS handshake 
in any way he desires (TLS version rollback, removal of extensions and 
possibly more). IMO this disqualifies the proposed ciphersuites from 
claiming more than 96-bits of security.

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Oct 2011 18:13:51 -0400

Nikos:

> A comment on this draft is that it might be misleading on the security levels it claims. It mentions:
> However the (D)TLS Finished message is protected by a 96-bit MAC, thus an attacker that can break a 96-bit MAC can manipulate the TLS handshake in any way he desires (TLS version rollback, removal of extensions and possibly more). IMO this disqualifies the proposed ciphersuites from claiming more than 96-bits of security.

It is important to distinguish between off-line and on-line attacks.  It is common (though perhaps not universal) to rate the strength of cryptography in terms of resistance to off-line attack, and that is what Suite B minimum levels of security express.  However, there is no commonly agreed metric for strength against on-line attacks.  In practice, resistance to on-line attack can be pragmatically stronger than resistance to off-line attack, while appearing to be mathematically weaker.  In TLS, there is no off-line attack against the MAC in the finished message.  To test a trial guess, the attacker must present it to the intended recipient on-line.  The protocol only allows one chance to get the
"finished" message right.  If the message does not verify, there is a fatal error, the connection is terminated and all cryptographic keys for the connection are discarded.  To be secure, the probability of success has to be low enough to be operationally impractical, as opposed to being low enough to be technologically infeasible.  One could argue that a 32-bit or 64-bit MAC would be plenty generous for security; however, RFC 5246 already specifies that the MAC be no shorter than 96 bits.  That is more than enough to be suitable with ANY metric for on-line cryptographic strength, not just 128 or 192 bits needed for Suite B.

Thanks for the review,
   Margaret Salter
   Russ Housley

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 16 Oct 2011 09:23:22 +0200

On 10/14/2011 12:13 AM, Russ Housley wrote:

>> A comment on this draft is that it might be misleading on the
>> security levels it claims. It mentions: "The Fact Sheet on Suite B
>> Cryptography requires key establishment and authentication
>> algorithms based on Elliptic Curve Cryptography and encryption
>> using AES [AES].  Suite B algorithms are defined to support two
>> minimum levels of security: 128 and 192 bits."
>>
>> However the (D)TLS Finished message is protected by a 96-bit MAC,
>> thus an attacker that can break a 96-bit MAC can manipulate the TLS
>> handshake in any way he desires (TLS version rollback, removal of
>> extensions and possibly more). IMO this disqualifies the proposed
>> ciphersuites from claiming more than 96-bits of security.
> It is important to distinguish between off-line and on-line attacks.
> It is common (though perhaps not universal) to rate the strength of
> cryptography in terms of resistance to off-line attack, and that is
> what Suite B minimum levels of security express.  However, there is
> no commonly agreed metric for strength against on-line attacks.  In
> practice, resistance to on-line attack can be pragmatically stronger
> than resistance to off-line attack, while appearing to be
> mathematically weaker.  In TLS, there is no off-line attack against
> the MAC in the finished message.  To test a trial guess, the attacker
> must present it to the intended recipient on-line.  The protocol only
> allows one chance to get the "finished" message right.  If the
> message does not verify, there is a fatal error, the connection is
> terminated and all cryptographic keys for the connection are
> discarded.  To be secure, the probability of success has to be low
> enough to be operationally impractical, as opposed to being low
> enough to be technologically infeasible.  One could argue that a
> 32-bit or 64-bit MAC would be plenty generous for security; however,
> RFC 5246 already specifies that the MAC be no shorter than 96 bits.
> That is more than enough to be suitable with ANY metric for on-line
> cryptographic strength, not just 128 or 192 bits needed for Suite B.

I understand that an on-line attack might have different security level 
requirements, but maybe it should be made clear on the security 
considerations that the mentioned security levels apply to off-line attacks.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 27 Oct 2011 19:07:46 +0200

On 10/16/2011 09:23 AM, Nikos Mavrogiannopoulos wrote:

>>> security levels it claims. It mentions: "The Fact Sheet on Suite
>>> B Cryptography requires key establishment and authentication 
>>> However the (D)TLS Finished message is protected by a 96-bit
>>> MAC, thus an attacker that can break a 96-bit MAC can manipulate
>>> the TLS handshake in any way he desires (TLS version rollback,
>>> removal of extensions and possibly more). IMO this disqualifies
>>> the proposed ciphersuites from claiming more than 96-bits of
>>> security.
>> It is important to distinguish between off-line and on-line
>> attacks. It is common (though perhaps not universal) to rate the
>> strength of cryptography in terms of resistance to off-line attack,
>> and that is what Suite B minimum levels of security express.

Having a second read on the document I don't think this is the case. The
document specifies
The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

The fact that the SHA-384 is used in the latter case in combination with
AES_256 it implies that SHA256 was replaced by SHA384 to increase the
security (the same way AES-128 was replaced by AES-256). However there
is no evidence that a 96-bit SHA384 based MAC is stronger than a 96-bit
SHA256 MAC.

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Oct 2011 13:37:51 -0400

> is no evidence that a 96-bit SHA384 based MAC is stronger than a 96-bit

Elsewhere in the Suite B profiles, SHA-384 is always paired with AES-256 and EC algorithms using the P-384 curve.  This selection was done for consistency.

Also, make sure you do not confuse the use of ECDSA with SHA-384 with HMAC with SHA-384.

Russ

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 27 Oct 2011 20:46:07 +0200

On 10/27/2011 07:37 PM, Russ Housley wrote:

>>>>> more than 96-bits of security.
>>>> attacks. It is common (though perhaps not universal) to rate 
>>>> the strength of cryptography in terms of resistance to off-line
>>>> attack, and that is what Suite B minimum levels of security
>>>> express.
>> 
>> Having a second read on the document I don't think this is the 
>> case. The document specifies The 
>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 
>> The fact that the SHA-384 is used in the latter case in combination
>> with AES_256 it implies that SHA256 was replaced by SHA384 to
>> increase the security (the same way AES-128 was replaced by
>> AES-256). However there is no evidence that a 96-bit SHA384 based
>> MAC is stronger than a 96-bit SHA256 MAC.
> Elsewhere in the Suite B profiles, SHA-384 is always paired with 
> AES-256 and EC algorithms using the P-384 curve.  This selection was
>  done for consistency.

This is however, cannot be deducted from the document. The document
describes two combinations of suites one of 128-bit security level and
another of 192-bit. In the 128-bit security level a SHA-256 PRF is used
and in the 192-bit the SHA-384 PRF. To someone reading this document it
is apparent that the choice of the SHA-384 PRF is done to increase to a
192-bit security level. However, as you say this is not the case, and
this IMO deserves at least a sentence in the security considerations
section.

> Also, make sure you do not confuse the use of ECDSA with SHA-384 with

I believe I was clearly talking about the TLS PRF (The SHA384 in the
ciphersuite name refers to the PRF).

regards,
Nikos

---

From: Russ Housley <[email-masked]>
Date: Thu, 27 Oct 2011 15:02:24 -0400

> this IMO deserves at least a sentence in the security considerations

If this document were defining the ciphersuites, I might agree.  However, this document is using ciphersuites that are defined in other documents.  This document should not be commenting on the security properties of ciphersuites, except to say that they are sufficient for Suite B.

Russ

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 22:31:07 +0200 (MEST)

Russ Housley wrote:
> If this document were defining the ciphersuites, I might agree.

I agree that the Suite B document does not define (and therefore can
not fix) awkward design choices of existing TLS cipher suite specs.

Personally, I would never attribute a strength higher than 128-bits
symmetric to an AES_256_GCM cipher because of the limitation of the
MAC algorithm (AEAD) to 128 bits.

The longer hash does help in retaining entropy during the
MasterSecret derivation and the traffic keys derivation.

But I do not believe that SHA384 for the PRF is a sensible choice,
IMHO they should have used SHA512 instead -- which uses the *exact*
same algorithm, just a different internal start value and no output
truncation.

The trailing Hash algorithm (SHA256 / SHA384) following a symmetric crypto
algorithm (AES_128_GCM / AES_256_GCM) is also extremely confusing.
A trailing(!) hash algorithm name has originally been used to indicate
the hash for an HMAC-based integrity-protection.

The hash for the PRF ought to have been inserted directly after "TLS",
which would IMHO have been much less confusing.

And btw. I believe that rfc5288 is SERIOUSLY FLAWED in that it
says "MUST NOT be negotiated with other versions of TLS than v1.1",
because this is a very clear violation of rfc2119 section 6 and
entirely unnecessary.

The use of these cipher suites with TLSv1.0 or TLSv1.1 would be
simple and straight-forward (and that does include a SHA-256
and SHA-384 PRF).   TLSv1.0 was explicitly designed to support
other hashes for the PRFs.  While it may not be explicit in the
acutal TLSv1.1 spec, is was clearly addressed in the design
discussion, and it was implemented and shipped for Windows XP,
where you can plug-n-play a crypto provider that will allow
the use of Microsoft's SChannel (an implementation of
TLSv1.0 without support for TLS extensions) to use GOST TLS
cipher suites with all GOST algorithms, including a GOST-based
TLSv1.0 PRF.

In the same fashion, I am very strongly opposed that the Suite B
document contains a MUST USE for the signature algorithm TLS extension.

That MUST is entirely unnecessary, and a MAY perfectly sufficient.
A MUST precludes that the seriously fouled up extension in rfc5246
is updated/replaced with something much more reasonable in a successor
spec (in case that some folks would prefer a new TLS extension with
a sane definition -- the MUST NOT include signature algorithms in
ServerHello made the definition pretty much unfixable).

The availability of the TLSv1.2 PDUs for conveying the signature and
hash algorithm are perfectly sufficient for the interop, the TLS signature
extension could in theory help to disambiguate, but the algororithms
of client and server for the EC algorithms seem sufficiently interlocked
that I consider such ambiguity somewhat unlikely.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Oct 2011 23:52:26 +0200

On 10/27/2011 09:02 PM, Russ Housley wrote:

> If this document were defining the ciphersuites, I might agree.  However, this document is using ciphersuites that are defined in other documents. 

Ok then we have a loop where the documents that define the ciphersuites
don't discuss the security levels because they will be discussed
somewhere else, and the documents that define the security levels don't
actually discuss them because they should have been discussed in the
ciphersuites document.

regards,
Nikos