Subject: mmusic-sap-04 comments & clarifications

From: Bill Lewis <[email-masked]>
Date: Tue, 07 Apr 1998 15:07:12 -0700

I ran across what seems like a problem, unless it's just not clearly
expressed.  In the section which describes the SAP Header's 
optional fields: How is a SAP parser to tell when an Optional
field is present?  The only resolution I can see with what's there is
for the Optional fields to become non-Optional when the Encryption
bit is set.
Is this really true?

I also have these comments to pass along:

> Many symmetric encryption algorithms, e.g. DES [6] are known to be easy 
> to break; with such algorithms, it is undesirable to re-use the SEK many
> times.

I assume this is because it's easier to break with more content, but one
thing that isn't addressed is storage and brute force attack.  Any
individual key needs to withstand attack for the life of the content
(taking into account economics, of course, but how expensive is it to let
a $1500 Pentium II crunch away for a year?).  I would make sure to use
strong keys to start with...

> 3.3	Encrypted Payload Format 
> 3.3.1	Generic Format
...
> The application is expected to test whether the fields 
> immediately following the timeout field in the main SAP header is 
> compatible with the use of symmetric encryption; in this case it will be
> a padding bit followed by a 31-bit random field, or whether it is 
> compatible with the use of hybrid encryption. In this case there is a 
> very specific format to the first byte of the Privacy header, which 
> follows other time-out field in this case.

This is a heuristic detection method, which I really don't like in a
protocol; is it such a penalty to have an identifier to specify
deterministically?

Thanx!

===============================
Bill Lewis
Intel Corporation
Communication Architecture Labs
Internet Security & Services
[email-masked]
===============================

---

From: Mark Handley <[email-masked]>
Date: Tue, 07 Apr 1998 18:37:03 -0400

>for the Optional fields to become non-Optional when the Encryption

If the header length is non-zero, then there's an authentication
header present.  If the payload is encrypted, the E bit is set, and
the timout field is present, and the payload is encrypted.  

The privacy header should be thought of as a part of the encryption
scheme rather than as a SAP header, and this is where things get a

>protocol; is it such a penalty to have an identifier to specify

I agree with you.  Either all encryption schemes should share a common
encryption header, or all schemes should be dependent on trying all
available keys (each with its defined encryption scheme) when they get
a new announcement.  

Van pushed for the latter, on the basis that the first rule of
security is never to give any additional information away to a
potential attacker.  In any event the set of keys any one user is
likely to have will be small so the cost of trying each is not a big
deal.  If we follow this through, there's no need to define a standard
(encryption-scheme independent) privacy header for hybrid schemes.

The alternative is to go to the opposite extreme and use a standard
privacy header for symmetric encoding too.  In this case, the key-id
field that was originally in SAP should probably be resurrected too,
and prevent you needing to try all your keys for each announcement.
This does definitely give away some information that might potentially
be useful to an attacker.  Not a huge amount maybe, but some.

In the past, Van convinced me that the key-id was a bad idea, and
hence by extension, the encryption format type field is also a bad
idea.  

We should make our (collective) mind up on this issue and not try to
sit on the fence as the current draft does...

Cheers,
	Mark

---

From: aCPPier <[email-masked]>
Date: Tue, 07 Apr 1998 23:31:20 -0400 (EDT)

DO NOT SEND ME ANY MORE EMAILS.
next time I am going to spam you, which means you will probably have
problems with your mail.
It will crach your mail server.
Last warning.

---

From: "Peter T. Kirstein" <[email-masked]>
Date: Wed, 08 Apr 1998 07:36:59 +0100

>sit on the fence as the current draft does...

Mark,

You are well aware that the current draft sits on the fence only because
this was the only way to convince you and Van to agree to proceed. I have
always felt that we should have a standard privacy header, with a format
type indicating that one wanted to have the number of keys tried which is
Van' preferred approach. The asymmetric privacy header is the preferred
approach to all other applications which wish to integrate with  a security
infrasatructure; it is just that this Working Group, or at least a few
members in it, have disliked the idea of having a security infrastructure
at all. I accept that there should be a compromise by which we have a
standard format header - and have mechanisms which work without a security
infrastructute. I do not accept that we have a mechanism that does not
permit plugging in to a security infrastructure.

There are a number of application scenarios, particularly in the commercial
arean, where there is a clear need to use such a security infrastructure.
Moreover, it shoudl be the same one as is used for other application-level
secure activities. we can easily define such a header; it was in the
earlier drafts. The overhead introduced is a trivial number of bytes. It
was removed ony from your and Van's pressure. I would welcome your agreeing
to this approach.

Peter