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

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Aug 2008 02:35:20 +1200

Eric Rescorla <[email-masked]> writes:
>Peter Gutmann wrote:
>> or whatever pet algorithms other governments want to play with this week?
>
>Uh, that's exactly what we do.

I knew I should have added a footnote to my original message... the various
add-on RFCs that cover the other pet algorithms are an illustration of my
point about sandboxing, they're all nicely optional and buried in locations
where everyone can happily ignore them (additional informational RFCs and the
like), it's only the Suite B stuff that keeps getting forced on us.  The
current draft doesn't contain any MAY clauses so I assume all the algorithms
are mandatory to implement (and it's not just specifically this draft, these
weird USG-only algorithms seem to turn up everywhere).  So I'll ask again:
what makes Suite B so special that it can't be sandboxed like the other pet
algorithms?

Peter.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 24 Aug 2008 07:54:43 -0700

At Mon, 25 Aug 2008 02:35:20 +1200,
Peter Gutmann wrote:
> like),

The RFCs I cited are Proposed Standard.

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

>  The
> current draft doesn't contain any MAY clauses so I assume all the al	gorithms
> weird USG-only algorithms seem to turn up everywhere). 

Well, you could assume that, but you would be wrong. 

1. RFC 5246 lists SHA-384, but it's optional. The MTI is clearly stated
   as TLS_RSA_WITH_AES_128_CBC_SHA, as listed in S 9:
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 I'll ask again:

There's a suite of SHA algorithms all specified in the same NIST
documents. This includes SHA-256 and SHA-384. 

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.

If you want to make an argument that we should simply refuse to
assign code points to a bunch of algorithms, I think that's reasonable
and I'm not sure I would disagree. But I don't agree that having
all the same code points spread out over a zillion separate documents
is somehow a feature.

-Ekr