Subject: Re: [TLS] draft-ietf-tls-psk-new-mac-aes-gcm-01 : portfolio question

From: Peter Gutmann <[email-masked]>
Date: Thu, 28 Aug 2008 01:37:32 +1200

Eric Rescorla <[email-masked]> writes:

>We've got a bunch of documents that specify SHA-256. I don't think it's
>somehow a feature to have an entirely parallel track of documents in some
>sandbox that only differ in that they specify SHA-384.

I think it does.  For 15-odd years SSL/TLS got along with the universal-
standard MD5 and then SHA-1, and now it's added SHA-256.  Oh, and a bunch of
extra baggage that's been dragged along not for any good security reason but
just because it's in the same algorithm family.

The S/MIME and PKIX approach to this has shown (well, in the PKIX case at
least for some level of "shown") that it's quite possible to break out the
algorithms into distinct documents - you'd have a common subset of { RSA, DH,
AES, SHA-256 } in the base spec, and then various special-case algorithms in
their own drafts.  That way instead of having to update a dozen different RFCs
every time a new algorithm comes out (newAlgo with this TLS mechanism, newAlgo
with that TLS mechanism, newAlgo with the other TLS mechanism, ... ) you
publish a single new RFC "Use of newAlgo with TLS" that covers its use with
all TLS mechanisms (PSK, SRP, GCM, etc) that might be affected by it.  This
ongoing ripple-update problem was the reason why the other groups broke out
the add-on algorithms into their own documents.

>> it's only the Suite B stuff that keeps getting forced on us.
>
>It's not getting forced on you and you can happily ignore it.

I can ignore it if I'm calling the shots, but the people calling the shots are
bureaucrats enforcing checkbox-compliance whose understanding of crypto is
"it's on the list, there must be some reason for it so we'll make it a
mandatory-to-implement item".  As a result you can't happily ignore it, you
have to unhappily implement it even if it makes no sense at all to have it
there.  Anything mentioned in the spec, no matter how irrational or useless,
will become a mandatory-to-implement item in a checkbox-compliance
environment.

>2. The document in question (draft-ietf-tls-psk-new-mac-aes-gcm-01)
>   *is* an add-on document and none of these algorithms are mandatory
>   to implement.

So if another standards group mandates GCM (as per this draft), which
algorithms am I supposed to implement?  I can't see anything in the draft
saying that the algorithms are all optional.

Peter.

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

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 27 Aug 2008 16:10:23 +0200

Dear Peter,

> saying that the algorithms are all optional.

In the Security Considerations section:

    The security considerations in RFC 4279, RFC 4758, and [I-D.ietf-
    tls-rsa-aes-gcm] apply to this document as well.  In addition, as
    described in [I-D.ietf-tls-rsa-aes-gcm], these cipher suites may
    only be used with TLS 1.2 or greater.

I think "these cipher suites may only be used with TLS 1.2 or greater" 
is equivalent to "they are optional and are only to be used with TLS1.2 
or greater".

Best regards

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Aug 2008 16:55:29 +0200 (MEST)

> saying that the algorithms are all optional.

Were you looking for some guidance in the document instead of blindly
relying on common sense?

An additional paragraph along the lines:

This document defines a number of TLS ciphersuites to allow for indepent
interoperable implementations.  It does not make applicability statements
about these ciphersuites to usage scenarios.  Other specifications that
intend to reference ciphersuites from this document are required to
reference each ciphersuite seperately and with a seperate requirements
level (mandatory, recommended, optional) for each referenced
cipher suite.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Aug 2008 08:12:03 -0700

At Thu, 28 Aug 2008 01:37:32 +1200,
> just because it's in the same algorithm family.

Peter you had your chance to complain about this back in 
June 2007, when 384 was added--or for that matter you could
have complained when RFC 5246 was in LC. I don't recall you 
doing so. 

> in the base spec, and then various special-case algorithms in

And this is mostly what TLS does as well, but many felt we should have
both SHA-256 and SHA-384 in the base spec.

> saying that the algorithms are all optional.

All new algorithms are optional unless specified otherwise. If some other
standards group requests it, then you're on your own, just as you 
would be if they insisted that your TLS implementation be written in COBOL, 
though the TLS standards are silent on that too.

-Ekr

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 28 Aug 2008 17:14:22 +1200

Eric Rescorla <[email-masked]> writes:
>LPeter you had your chance to complain about this back in June 2007, when 384
>was added--or for that matter you could have complained when RFC 5246 was in
>LC. I don't recall you doing so.

At the time I didn't know that other standards groups that use TLS were going
to be making such a mess of things (some get it right, e.g. IEC 68150 which
profile a single cipher suite - although admittedly a somewhat odd choice -
but others require that you implement everything mentioned in the spec).  This
wasn't a request to retroactively change existing specs but a suggestion for
future work.  PKIX and the S/MIME group managed this too, and (IMHO) the
specs, and particularly the standards process, are the better off for it
because the ripple-update problem is no longer present.

>All new algorithms are optional unless specified otherwise. 

Maybe the spec could make this explicit then, there's nothing in there at the
moment that says this so there's no way for anyone reading the draft (who
hasn't seen your email to this list) to know this.  And even then I think
saying "We don't have to implement SHA-384 because ekr said so in a posting he
made to the TLS list" probably won't work too well in a debate over standards
conformance :-).

Peter.

PS: Apologies for some of the duplicate posts that may have turned up, our
    mail system had a slight hiccup earlier on.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls