Re: Netscape

At 13:38 7/22/96, Tom Weinstein wrote:

>Yes, and that's what we're trying to do.  Get strong crypto in the hands
>of as many people as we can.  I can hardly wait until we get S/MIME in.

What will Netscape do to about the 40bit RC-2 default and the signatures on
the outside of the encryption envelope design flaws in S/MIME? I can't
imagine Netscape releasing software that has these two properties.



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.
   Defeat the Demopublican Unity Party. Vote no on Clinton/Dole in November.
   Vote Harry Browne for President.

Lucky Green wrote:
> 
> At 13:38 7/22/96, Tom Weinstein wrote:
> 
> >Yes, and that's what we're trying to do.  Get strong crypto in the hands
> >of as many people as we can.  I can hardly wait until we get S/MIME in.
> 
> What will Netscape do to about the 40bit RC-2 default and the signatures on
> the outside of the encryption envelope design flaws in S/MIME? I can't
> imagine Netscape releasing software that has these two properties.

  If you know that the recipient can read a message encrypted with
3DES, IDEA, or RC2-128, then you can send the message using one of
these strong algorithms.  Given that you need someones public key
to send them a message, there are several obvious ways to transmit
information about what algorithms they accept along with it.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff Weinstein wrote:
> 
> Lucky Green wrote:
> >
> > At 13:38 7/22/96, Tom Weinstein wrote:
> >
> > >Yes, and that's what we're trying to do.  Get strong crypto in the hands
> > >of as many people as we can.  I can hardly wait until we get S/MIME in.
> >
> > What will Netscape do to about the 40bit RC-2 default and the signatures on
> > the outside of the encryption envelope design flaws in S/MIME? I can't
> > imagine Netscape releasing software that has these two properties.
> 
>   If you know that the recipient can read a message encrypted with
> 3DES, IDEA, or RC2-128, then you can send the message using one of
> these strong algorithms.  Given that you need someones public key
> to send them a message, there are several obvious ways to transmit
> information about what algorithms they accept along with it.

   Yes, we all know that. But which one will Netscape actually _do_?

   If there's one thing we've learned from PGP, it's that configuration 
and per-user key management are killers. The reason why I'm so excited 
about Netscape is that you guys have the _possibility_ to really get 
strong crypto to the masses. Whether you really do that or not is in 
your hands.

   I've made a proposal for solving the 40-bit protocol failure in 
S/MIME. There are other proposals out there too, with various strengths 
and weaknesses. The main advantage of mine is that it requires no 
additional infrastructure - i.e. VeriSign does not have to start 
including algorithm preferences in the DigitalID's they distribute.

   Will Netscape come through?

Raph

Raph Levien wrote:
> 
> Jeff Weinstein wrote:
> >
> > Lucky Green wrote:
> > >
> > > At 13:38 7/22/96, Tom Weinstein wrote:
> > >
> > > >Yes, and that's what we're trying to do.  Get strong crypto in the hands
> > > >of as many people as we can.  I can hardly wait until we get S/MIME in.
> > >
> > > What will Netscape do to about the 40bit RC-2 default and the signatures on
> > > the outside of the encryption envelope design flaws in S/MIME? I can't
> > > imagine Netscape releasing software that has these two properties.
> >
> >   If you know that the recipient can read a message encrypted with
> > 3DES, IDEA, or RC2-128, then you can send the message using one of
> > these strong algorithms.  Given that you need someones public key
> > to send them a message, there are several obvious ways to transmit
> > information about what algorithms they accept along with it.
> 
>    Yes, we all know that. But which one will Netscape actually _do_?
> 
>    If there's one thing we've learned from PGP, it's that configuration
> and per-user key management are killers. The reason why I'm so excited
> about Netscape is that you guys have the _possibility_ to really get
> strong crypto to the masses. Whether you really do that or not is in
> your hands.
> 
>    I've made a proposal for solving the 40-bit protocol failure in
> S/MIME. There are other proposals out there too, with various strengths
> and weaknesses. The main advantage of mine is that it requires no
> additional infrastructure - i.e. VeriSign does not have to start
> including algorithm preferences in the DigitalID's they distribute.

  I don't like the fact that your proposal ties the size of the
bulk encryption key to the size of the public modulus.  There
are legitimate reasons why someone might choose to have a 512
bit modulus even though they prefer longer bulk encryption keys.
Your heuristic would be a good fallback in the absence of more
reliable information.  

  There is another method that does not require verisign or other
CAs to add key size extensions to their certs.  We can define
a new authenticated attribute that gets included in Signed-Data
and Signed-And-Enveloped-Data messages that indicates the
user's key size and algorithm preference.  This has the advantage
that the preference is selected and signed by the user.  This
method was discussed at the S/MIME meeting in January at the
RSA Crypto conference.  I'm a bit surprised that it never
got into the Implementation Guide.  I'll make sure that
we bring it up on the smime list again.

  What we finally implement will probably be a combination of
the three methods, with the user's selection taking precedence
over the CAs selection, which takes precedence over the
heuristic based on modulus size.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

On Tue, 23 Jul 1996, Jeff Weinstein wrote:

>   I don't like the fact that your proposal ties the size of the
> bulk encryption key to the size of the public modulus.  There
> are legitimate reasons why someone might choose to have a 512
> bit modulus even though they prefer longer bulk encryption keys.
> Your heuristic would be a good fallback in the absence of more
> reliable information.  

   I agree. My proposal certainly has its limitations. In addition to the
one you cite, it will make it very difficult to change away from
Triple-DES when the time comes. 

   Of course, your hypothetical user who wants to use a 512-bit key and
128-bit RC2 is still completely screwed by all currently shipping S/MIME
products, as well as the S/MIME spec.

>   There is another method that does not require verisign or other
> CAs to add key size extensions to their certs.  We can define
> a new authenticated attribute that gets included in Signed-Data
> and Signed-And-Enveloped-Data messages that indicates the
> user's key size and algorithm preference.  This has the advantage
> that the preference is selected and signed by the user.  This
> method was discussed at the S/MIME meeting in January at the
> RSA Crypto conference.  I'm a bit surprised that it never
> got into the Implementation Guide.  I'll make sure that
> we bring it up on the smime list again.

   I don't like the fact that your proposal leaves clients with absolutely
no information about symmetric cipher choice until the first round of
signed messages has been exchanged. In this initial round, the protocol is
still dependent on the global default.

   I'm not surprised that it didn't make it to the implementation guide.
Most of the people involved in S/MIME do not have a strong background in
security and do not understand the importance of this issue. In addition,
I suspect that there is a lot of resistance based simply on the added
implementation costs.

   I have no evidence that the protocol weaknesses in S/MIME are being
deliberately encouraged by the NSA, but on the other hand, I have no
evidence that they're not. It would certainly be consistent with tactics
that the organization has been known to use. But on the other hand, "never
ascribe to malice..."

>   What we finally implement will probably be a combination of
> the three methods, with the user's selection taking precedence
> over the CAs selection, which takes precedence over the
> heuristic based on modulus size.

   This approach is fine. If that's what you implement, you have my
blessing.

Raph

P.S. Can we agree not to describe 128-bit RC2 as "strong crypto" until
it's been subject to more serious scrutiny? It's probably a great cypher,
but most cautious crypto-people would far rather place their trust in
Triple-DES.

Raph Levien wrote:
> 
> On Tue, 23 Jul 1996, Jeff Weinstein wrote:
> 
> >   I don't like the fact that your proposal ties the size of the
> > bulk encryption key to the size of the public modulus.  There
> > are legitimate reasons why someone might choose to have a 512
> > bit modulus even though they prefer longer bulk encryption keys.
> > Your heuristic would be a good fallback in the absence of more
> > reliable information.
> 
>    I agree. My proposal certainly has its limitations. In addition to the
> one you cite, it will make it very difficult to change away from
> Triple-DES when the time comes.
> 
>    Of course, your hypothetical user who wants to use a 512-bit key and
> 128-bit RC2 is still completely screwed by all currently shipping S/MIME
> products, as well as the S/MIME spec.

  I can't find anything in the S/MIME spec that makes the combination
of 512-bit RSA key and 128-bit RC2 (or 3DES) illegal.  The spec says
that you must support RSA key sizes from 512 to 1024.  Am I missing
something?

> >   There is another method that does not require verisign or other
> > CAs to add key size extensions to their certs.  We can define
> > a new authenticated attribute that gets included in Signed-Data
> > and Signed-And-Enveloped-Data messages that indicates the
> > user's key size and algorithm preference.  This has the advantage
> > that the preference is selected and signed by the user.  This
> > method was discussed at the S/MIME meeting in January at the
> > RSA Crypto conference.  I'm a bit surprised that it never
> > got into the Implementation Guide.  I'll make sure that
> > we bring it up on the smime list again.
> 
>    I don't like the fact that your proposal leaves clients with absolutely
> no information about symmetric cipher choice until the first round of
> signed messages has been exchanged. In this initial round, the protocol is
> still dependent on the global default.

  How did you get the certificate of the recipient?  I assume that you
got it from a degenerate PKCS#7 Signed-Data message as recommended by
the s/mime spec.  That degenerate message could contain the attribute
I describe.  If you got the certificate by some other means, we would
fall back to your heuristic.

> P.S. Can we agree not to describe 128-bit RC2 as "strong crypto" until
> it's been subject to more serious scrutiny? It's probably a great cypher,
> but most cautious crypto-people would far rather place their trust in
> Triple-DES.

  Certainly.  We will definitely offer 3DES as well as RC2 in our
product.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

On Tue, 23 Jul 1996, Jeff Weinstein wrote:

> Raph Levien wrote:
> 
> >    Of course, your hypothetical user who wants to use a 512-bit key and
> > 128-bit RC2 is still completely screwed by all currently shipping S/MIME
> > products, as well as the S/MIME spec.
> 
>   I can't find anything in the S/MIME spec that makes the combination
> of 512-bit RSA key and 128-bit RC2 (or 3DES) illegal.  The spec says
> that you must support RSA key sizes from 512 to 1024.  Am I missing
> something?

   By "screwed," I mean that, because of the default settings, a user who
wants to receive mail encrypted with ciphers stronger than 40-bit will
still receive a majority of messages encrypted at 40 bits. Since S/MIME
has not been widely deployed yet, this claim is speculation. However,
there is a lot of reason to believe it.

  The problem is not that the combination is illegal, it's that nobody
will actually configure their clients to use it.

> > >   There is another method that does not require verisign or other
> > > CAs to add key size extensions to their certs.  We can define
> > > a new authenticated attribute that gets included in Signed-Data
> > > and Signed-And-Enveloped-Data messages that indicates the
> > > user's key size and algorithm preference.  This has the advantage
> > > that the preference is selected and signed by the user.  This
> > > method was discussed at the S/MIME meeting in January at the
> > > RSA Crypto conference.  I'm a bit surprised that it never
> > > got into the Implementation Guide.  I'll make sure that
> > > we bring it up on the smime list again.
> > 
> >    I don't like the fact that your proposal leaves clients with absolutely
> > no information about symmetric cipher choice until the first round of
> > signed messages has been exchanged. In this initial round, the protocol is
> > still dependent on the global default.
> 
>   How did you get the certificate of the recipient?  I assume that you
> got it from a degenerate PKCS#7 Signed-Data message as recommended by
> the s/mime spec.  That degenerate message could contain the attribute
> I describe.  If you got the certificate by some other means, we would
> fall back to your heuristic.

   Perhaps I'm missing something here. In the model I'm assuming, if I
wanted to send you mail, the first thing I'd do is get your certificate.
Today, I'd do that by going to the VeriSign Web site, but in the near
future I would expect this lookup to be automatic. Either way, it would be
up to VeriSign to ship the algorithm preference information along with the
X.509 cert (whether by degenerate PKCS#7 or some other means). This means
that VeriSign needs to agree to ship the information in response to
queries, and also that users keep the VeriSign database up to date with
respect to algorithm preferences. This is the infrastructure requirement I
referred to, one that isn't present in my proposal.
   After the first exchange of e-mail, the problem goes away. However, I
consider the protection of the inital round to be important.

> > P.S. Can we agree not to describe 128-bit RC2 as "strong crypto" until
> > it's been subject to more serious scrutiny? It's probably a great cypher,
> > but most cautious crypto-people would far rather place their trust in
> > Triple-DES.
> 
>   Certainly.  We will definitely offer 3DES as well as RC2 in our
> product.

   Good. The point I'm making has more to do with representing 128-bit RC2
as being of comparable trustworthiness as 3DES, though, not simply of
offering the option. Since RC2 is slower than 3DES, it's not at all clear
to me why anyone would choose it.

   Just to be clear, I'm not arguing with you because I think Netscape
will ship a bad product. However, I do see a real danger that, in the
field, S/MIME will have severe security problems, mostly because people
don't understand how to use it correctly. Carefully explaining the exact
strengths and limitations of S/MIME is our best hope of it being deployed
as a strong crypto protocol. Since most of the force behind S/MIME now is
from marketing, rather than security, people, I don't see much of that
going on (as a case in point, from a technical perspective, the recent
interoperability testing has been fairly sloppy). It is my hope that
Netscape will do better.

Raph