Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The TransportLayer Security (TLS) Protocol Version 1.2) to Proposed Standard

From: <[email-masked]>
Date: Mon, 3 Mar 2008 13:41:47 +0200

The text you're quoting is unchanged from TLS 1.1, and RFC 4680 is
clearly a version-independent feature. So yes, you can use it with TLS
1.2 as well.

(The text about ordering handshake messages in TLS 1.0/1.1/1.2 is
intended to apply only to handshake messages defined in those
documents; the intent is not to prevent other documents from defining
new handshake messages that get added somewhere in the middle.)

Best regards,
Pasi 

> -----Original Message-----
> From: ext Mark Brown [mailto:[email-masked]] 
> Sent: 29 February, 2008 18:38
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The 
> TransportLayer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
> 
> Ok, thanks.  
> 
> So, my understanding is that TLS Supplemental Data [RFC4680] is 
> Ok & Standard to use even though it violates the prohibitions 
> below.  Is that right?  (Neither 4366-bis nor 5077 violate 
> prohibitions...)
> 
> --mark
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, February 29, 2008 5:29 AM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
> > TransportLayer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
> > 
> > 
> > I wouldn't say it was overlooked; it's simply not in scope of
> > this document. There are other documents that define new TLS
> > handshake messages (at least RFC 4366(bis) and RFC 5077
> > in addition to RFC 4680), and those messages are not mentioned
> > here either (and don't have to be).
> > 
> > Best regards,
> > Pasi
> > 
> > > -----Original Message-----
> > > From: Mark Brown
> > > Sent: 28 February, 2008 22:57
> > > To: [email-masked]
> > > Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
> > > TransportLayer Security (TLS) Protocol Version 1.2) to
> > > Proposed Standard
> > >
> > > TLS Supplemental Data [RFC4680] was overlooked, e.g. in 
> section 7.4.2.
> > > Server Certificate,
> > >
> > >       The server MUST send a certificate whenever the 
> agreed-upon key
> > >       exchange method uses certificates for authentication (this
> > >       includes all key exchange methods defined in this
> > > document except
> > >       DH_anon).  This message will always immediately follow
> > > the server
> > >                                    ^--No
> > >       hello message.
> > >
> > > Also in section 7.4.7. Client Key Exchange Message,
> > >
> > >       This message is always sent by the client. It MUST 
> immediately
> > >                                                     ^--No
> > >       follow the client certificate message, if it is sent.
> > > Otherwise it
> > >       MUST be the first message sent by the client after it
> > > receives the
> > >       ^--No
> > >       server hello done message.
> > >
> > > Instead, per [RFC4680], ServerCertificate may follow a server's
> > > SupplementalData message.  Also, Client Key Exchange follows
> > > the client
> > > Certificate message and/or the client SupplementalData
> > > message, if these
> > > messages are sent.
> > >
> > > [RFC4680] should also be added to the references section.  It
> > > may be helpful
> > > to add SupplementalData to Figure 1 on page 34 of 
> rfc4346-bis as well,
> > > marked with an asterisk *, following Figure 1 in [RFC4680].
> > >
> > > --mark
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> 
> 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Mar 2008 15:30:35 +0100

TLS versioning and IETF update/obsolete-versioning has different
semantics.  RFC 4680 updates RFC 4346, i.e. TLS 1.1.  If RFC 4346 is
obsoleted by RFC 4346bis (TLS 1.2), then RFC 4680 will not automatically
update RFC 4346bis.  My interpretation is that RFC 4680 will have to be
revised to update RFC 4346bis, in order to apply to TLS 1.2, if you
follow the IETF update/obsolete-versioning semantics.

I think Mark has a point here.  IETF-versioning doesn't handle
version-independent feature, unless such behaviour is explicitly
documented (which it isn't, as far as I can tell, in this case).

However, I think the solution here is to (once RFC 4346bis is published)
revise RFC 4680 to update RFC 4346bis, if there is a need from the
community to use RFC 4680 with TLS 1.2, rather than changing the TLS 1.2
specification.

/Simon

---

From: <[email-masked]>
Date: Tue, 4 Mar 2008 10:10:01 +0200

Simon,

The relationship between updates/obsoletes/references is not (as far 
as I know) clearly defined anywhere, but in practice, there is rarely 
any confusion.

Suppose that someone is implementing RFC AAAA, an optional extension
to a base protocol specified in RFC BBBB, and finds that the base
protocol specification has been updated after RFC AAAA was published
(i.e., RFC BBBB has been obsoleted by RFC CCCC). The implementor
should know whether his/her implementation implements BBBB or CCCC,
and if it's the latter, usually is able to easily tell whether the
extension works with the new version or not.

From this perspective, it doesn't matter much whether RFC AAAA has
"Updates: RFC BBBB" in rfc-index.txt, or just a normative reference to
RFC BBBB -- someone implementing RFC AAAA is faced with exactly the
same question (whether this applies to the newer version or not). And 
there isn't really much consistency today on how "Updates" is used 
when talking about optional extensions to some base protocol -- some 
folks want to have "Updates" on the cover page, others are fine with 
a normative reference (and possibly write separate "roadmap RFCs" so
that it's easier to find all the extensions to the base protocol).

Requiring the IETF to update all RFCs which extend RFC BBBB would be 
a huge job (as a long-time participant in IETF, I'm sure you're aware
how much work is required to update even one word in an RFC), and
especially if confusion is unlikely, unnecessary.

However, if you have a suggestion about text we could add to TLS 1.2,
that could be considered by IESG (however, note that this document
is on telechat agenda already this Thursday).

(Some other SDOs have document numbering/reference schemes which
avoid some parts of this problem (e.g. allowing reference either
to a specific version of some other spec, or the latest version);
but lacking this ability doesn't seem to result in big problems
in practice.)

Best regards,
Pasi

> From: ext Simon Josefsson [mailto:[email-masked]] 
> Sent: 03 March, 2008 16:31
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-ietf-tls-rfc4346-bis (The 
> Transport Layer Security (TLS) Protocol Version 1.2) to 
> Proposed Standard
> 
> obsoleted by RFC 4346bis (TLS 1.2), then RFC 4680 will not
> automatically update RFC 4346bis.  My interpretation is that RFC
> 4680 will have to be revised to update RFC 4346bis, in order to
> apply to TLS 1.2, if you follow the IETF update/obsolete-versioning
> semantics.
> 
> However, I think the solution here is to (once RFC 4346bis is
> published) revise RFC 4680 to update RFC 4346bis, if there is a need
> from the community to use RFC 4680 with TLS 1.2, rather than
> changing the TLS 1.2 specification.
> 
> /Simon
<snip>

---

From: Rob Dugal <[email-masked]>
Date: Tue, 4 Mar 2008 06:19:06 -0500

section 7.4.1.4.1

Why is SHA-224 not supported as a HashAlgorithm? For completeness 
shouldn't TLS 1.2 support all the SHA-2 algorithms?

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Mar 2008 09:58:29 -0800

>shouldn't TLS 1.2 support all the SHA-2 algorithms?

Not everyone agrees with the utility of SHA-224, particularly in a 
protocol where AES-128 is mandatory to implement.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 10:04:13 -0800

At Tue, 4 Mar 2008 09:58:29 -0800,
> protocol where AES-128 is mandatory to implement.

Indeed. 

If you want a MAC with effective algorithmic security the same as
SHA-256 but shorter, that's what truncated MACs are for.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 4 Mar 2008 21:45:20 +0100 (MET)

> SHA-256 but shorter, that's what truncated MACs are for.

SHA-224 is effectively that:

   SHA-224 is based on SHA-256, but it uses an different
   initial value and the result is truncated to 224 bits.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 04 Mar 2008 12:56:44 -0800

At Tue, 4 Mar 2008 21:45:20 +0100 (MET),
>    initial value and the result is truncated to 224 bits.

Yes, that's my point.

Shaving 4 bytes off of the packet size when the MAC is 32
bits is of extremely marginal value. If what you want is
a MAC that has the same algorithmic security as SHA-256
but you're worried about packet size, use SHA-256 truncated
to 80 bits with the truncated_mac extension.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Wed, 5 Mar 2008 06:54:11 -0500

You raise good points but by not having SHA-224 as a supported hash 
algorithm you effectively prevent anyone from using any certificates which 
use SHA-224 in TLS 1.2.
If the certificate doesn't use a hash algorithm found in the 
signature_algorithms extension then it cannot be used in TLS 1.2.

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 14:18:51 +0200

I think you have a point here -- while I agree that using SHA-224 to
construct a MAC isn't very useful here, we probably should support
SHA-224 in signatures (especially those contained in certificates, where
TLS can't really negotiate what the CA uses).
 
Best regards,
Pasi

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Rob Dugal
	Sent: 05 March, 2008 13:54
	To: [email-masked]
	Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The
Transport

	You raise good points but by not having SHA-224 as a supported
hash algorithm you effectively prevent anyone from using any
certificates which use SHA-224 in TLS 1.2. 
	If the certificate doesn't use a hash algorithm found in the
signature_algorithms extension then it cannot be used in TLS 1.2.

---

From: Martin Rex <[email-masked]>
Date: Wed, 5 Mar 2008 15:09:32 +0100 (MET)

> signature_algorithms extension then it cannot be used in TLS 1.2.

Maybe it is a good idea to use this as market pressure to
keep CAs from doing stupid things, such as issuing X.509
certificates with SHA-224 instead of SHA-256 in the signature.

(I hope that NIST didn't come up with a braindead suggestion to do so.)

-Martin

---

From: Len Sassaman <[email-masked]>
Date: Wed, 5 Mar 2008 09:52:27 -0800 (PST)

> (I hope that NIST didn't come up with a braindead suggestion to do so.)

I second this; is it really likely that a CA will issue certs with SHA-224
if SHA-224 is not part of TLS?

--Len.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Mar 2008 09:56:57 -0800

>certificates with SHA-224 instead of SHA-256 in the signature.

I'm with Martin on this one. The reason SHA-224 was invented was to 
have "impedance balance" with TripleDES. Even if you agree with that 
reasoning, there is no reason to use it in certificates. We don't 
need to help them here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 5 Mar 2008 19:47:56 +0100 (MET)

I want to apologize for my rude and inappropriate language in my
last message.

> reasoning, there is no reason to use it in certificates. We don't 

I'm perfectly fine with hash agility, and I think there is value
in truncating keyed hashes/MACs, but for a digital signature on
an X.509 certificate, using SHA-224 instead of SHA-256 looks like
additional complexity without value.

And even then, truncating a regular hash in a generic fashion,
like Eric suggested, seems IHMO to be more appropriate than
to define/add a new hash algorithm on every occasion.

-Martin

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 09:40:29 +0200

> (I hope that NIST didn't come up with a braindead suggestion 

One of the four allowed parameter combinations for DSA in current 
FIPS 186-3 draft is (L=2048, N=224), which potentially (although
not necessarily) could mean SHA-224.

However, the issue at hand is not whether this is a particularly
good idea or not (probably it isn't; and you can send comments
to NIST about that).

The issue is whether we want TLS 1.2 to be as algorithm-agile as 
possible, or try to impose artificial limitations to this agility 
as "market pressure". I would support making this agile, instead
of trying to predict (or control) the future.

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 04:34:58 -0800

> of trying to predict (or control) the future.

Regretfully, I agree with this....

-Ekr

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 6 Mar 2008 09:16:07 -0500

I'd say we want it agile - but not "as agile as possible".  Like in medicine - "flexible" is good, "over-flexible" is an adverse condition.

SHA244 seems a fifth wheel on a cart.

One useful question to ask is: does Suite B include SHA224? And how likely are similar standards from around the world to require SHA224?

And yes, NIST should hear about this.
--
Regards,
Uri

On 3/6/08 2:40 AM, "[email-masked]" <[email-masked]> wrote:

Best regards,
Pasi

---

From: Mike <[email-masked]>
Date: Thu, 06 Mar 2008 07:37:28 -0800

> Regretfully, I agree with this....

There seem to be a lot of strong feelings against SHA-224.
I looked at the FIPS amendment which defines it, and it
doesn't appear to be such a horrible thing.  Can someone
explain how NIST got it so wrong?

Thanks,

Mike

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 6 Mar 2008 10:46:46 -0500

No strong feelings. Just a reaction to an algorithm whose usefulness  
is low now and will decrease further. Compare it to SHA512 whose  
usefulness is expected to increase.
--
Regards,
Uri

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Mar 2008 08:32:04 -0800

At Thu, 06 Mar 2008 07:37:28 -0800,
> explain how NIST got it so wrong?

It's not *bad*. It's just unnecessary.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 06 Mar 2008 13:33:31 -0800

Eric Rescorla wrote, On 2008-03-06 08:32:
> At Thu, 06 Mar 2008 07:37:28 -0800, Mike wrote:

> It's not *bad*. It's just unnecessary.

I would add: Bloat is bad.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 07 Mar 2008 18:18:01 +1300

>It's not *bad*. It's just unnecessary.

I think that only holds true outside the security context.  In this case
however "unnecessary" is synonymous with "bad", because the more unnecessary
features you have to add, the greater the chance of getting something wrong
somewhere in a way that'll come back to bite you later.  Even just the extra
overhead of testing for correctness and interoperability (without the worry of
opening up security holes) is sufficient to make this "bad".

Peter.