RE: [TLS] Any advice regarding frequency of generating

[Peter Williams <home_pw@xxxxxxx>]

So, Ive now read the whole TLS 1.0 document very carefully (dont laugh, it was published in 1999, but
only now made default for most internet consumers), and that novel section specifically about 10 times.
 
Neither ephemeral RSA nor the IETF_endorsed export regime of RSAEXPORT were part of SSLv3. its
a bid sad to see certain IETF luminaries be a part of restricting RSA in that way, in its TLS 1.0 standard.
 
(1) we can interpret the phrase "not legal" in technical terms of the IETF material, by considering:-

   export_restriction
       A negotiation not in compliance with export restrictions was
       detected; for example, attempting to transfer a 1024 bit
       ephemeral RSA key for the RSA_EXPORT handshake method. This
       message is always fatal.

Creation of this error by either client or server means: "Servers and clients are
   required to forget any session-identifiers, keys, and secrets
   associated with a failed connection."
 
In US corporations, "forget" means exactly the opposite of its popular meaning: it means 
store all the data in the corporate data rentention logs even more carefully than normally, given
its good basis for suspecting criminal violation of export laws. 
 
(2) its clearly true that TLS 1.0 has ephemeral RSA. And, its in the right section of
the protocol machine, logically. However, the overall text looks poor for the RSA use cases, 
as if RSA_EXPORT was retrofitted at a late stage into text that looks even better formulated 
for the DH use cases that the SSL3 original text. 
 
Now TLS does say:-
 
"Following the hello messages, the server will send its certificate,
   if it is to be authenticated. Additionally, a server key exchange
   message may be sent, if it is required (e.g. if their server has no
   certificate, or if its certificate is for signing only)."
 
Thus SSL server endpoints without PKI certs are clearly allowed. and the key exchange
message is *required*, if the server has no cert.
 
Furthermore, in formal conformance testing terms, the RSAEXPORT controls on the server only 
apply to those servers that have a server cert, given this provides the control signal (by inspecting the 
public key modulus len). TLS status no limits about the case we are interested in,
and actually specifies no controls on how RSAEXPORT is to be handled there, when limiting
ephemeral key gen, and issuance of error alerts.
 
In terms of what I said to Mike, thus, in TLS1.0 protocol for RSA ephemeral, Id now say that one 
creates ephemeral RSA __under endpoint controls__, rather than PKI control limits, when 
(1) responding to an anon-capable ciphersuite, and (2) one does not perform server cert auth, as no 
cert is configured
 
IN commercial systems (vs military systems), servers can be configured to "view" themselves
as having no server cert for any reason the designer selects. This is the same logic in product
design as when handling RSA EKU controls, for certs that have only Signing EKU. If someone send 
you an encrypted email cleartitled "hi Peter: bomb threat in building 8" using your RSA key in key transport 
mode, of course you use the (privileged) software config mode to overide the EKU rule...and use RSA 
to decrypt the damn thing.

---

> From: martin.rex@xxxxxxx
> Subject: Re: [TLS] Any advice regarding frequency of generating
> To: home_pw@xxxxxxx
> Date: Tue, 19 Dec 2006 21:04:45 +0100
> CC: tls@xxxxxxxx
> 
> Peter Williams wrote:
> > 
> > Martin:
> >
> > RSA ephemeral is not "prohibited". Is not standardized, thats true.
> 
> They are standardized and required for SSL ciphersuites with the
> RSA_EXPORT key exchange method when a Server cert with an
> RSA key >512 bit is being used.
> 
> quoting rfc2246 (tls v1.0) 7.4.3. Server key exchange message:
> 
> When this message will be sent:
> This message will be sent immediately after the server
> certificate message (or the server hello message, if this is an
> anonymous negotiation).
> 
> The server key exchange message is sent by the server only when
> the server certificate message (if sent) does not contain enough
> data to allow the client to exchange a premaster secret. This is
> true for the following key exchange methods:
> 
> RSA_EXPORT (if the public key in the server certificate is
> longer than 512 bits)
> DHE_DSS
> DHE_DSS_EXPORT
> DHE_RSA
> DHE_RSA_EXPORT
> DH_anon
> 
> It is not legal to send the server key exchange message for the
> following key exchange methods:
> 
> RSA
> RSA_EXPORT (when the public key in the server certificate is
> less than or equal to 512 bits in length)
> DH_DSS
> DH_RSA
> 
> 
> rfc2246 says "It is not legal" to use ephemeral RSA for ciphersuites
> with the RSA key exchange method. And while the first part at least
> mentions the possibility of sign-only RSA keys, the second part
> completely ignores them.
> 
> What is that supposed to mean anyway? "Not legal (under some jurisdictions?)
> but well within the spec" or "MUST NOT send/use" in spec language?
> 
> 
> >
> > With Russ's non-repudiation proposal, a TLS session can be a form of
> > signature.
> 
> Btw. I completely and thoroughly dislike Russ' proposal for non-repudiation
> (he used the disguise terminology "evidence" though), both from a
> technical standpoint, as well as from a "political" perspective.
> 
> -Martin
>

---

Try amazing new 3D maps Check it out!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls