Re: Proposed Extensions to TLS for OpenPGP

[Tom Weinstein <tomw@xxxxxxxxxxxx>]

Will Price wrote:
> 
> The alternative seems to be to include another subpacket in the Hello
> packets negotiating certificate type just like compression is negotiated.
> This would also be allowed by the spec as per 7.4.1.2.  If it was to be
> done that way, I felt that this negotiation should have been included in
> the TLS spec.  Since I assume the time for that has passed, I opted for
> the ciphersuite overload.

I don't think it can go into TLS 1.0, but it's definitely something we
should work towards for a TLS 1.1 or 2.0.

>> Here you call out an RSA/3DES/RIPEMD mode.  If that's a good idea,
>> wouldn't it be a good idea with X.509 certificates as well?
> 
> Yes, it would.  Unfortunately once again, I assume the time to add such
> things has passed.  I felt it was important to have more than one hash
> algorithm associated with the OpenPGP certificates, but didn't want to
> use a potentially weak algorithm like MD5 (except where the TLS protocol
> requires MD5).  Were the TLS spec to ignore compatibility, I'm sure MD5
> would be eliminated, so I didn't want to add it to any new ciphersuites.
> RIPEMD-160 seemed an ideal replacement that was already part of OpenPGP.

HMAC-MD5 still appears to be strong.  While it would be nice to eliminate
MD5 from TLS at some point, there don't seem to be a lot of good
alternatives.  In my opinion, RIPEMD-160 hasn't seen enough analysis to
feel comfortable about it.  I'd prefer to give it another few years, at
least.

>> 3. Omitting the DistinguishedName field in the CertificateRequest
>> field seems problematic. I understand PGP doesn't use DNs,
>> but there should be a way to indicate who might be potential signers
>> of a given key.
> 
> OpenPGP keys generally have all the certs they need attached to them
> whereas X509 certs are only a single cert unto themselves thus requiring
> a chain if the specified cert is not directly certified by a root CA. 
> With OpenPGP, if a particular signer key is not found, the client or
> server can use a certserver to look it up.

Although TLS uses the X.509 cert formats, it doesn't require an X.500
directory to operate.  I don't think it's a good idea to require an OpenPGP
cert server, either.

>> 4. In addition, I don't see what the point of prohibiting
>> "Export" ciphers with PGP keys is. Obviously, if you're explicitly
>> calling out cipherSuites, you can simply omit all the export cipher
>> suites from that list, but frankly, stating that  "Export" algorithms
>> also may not be used with OpenPGP keys" seems silly. It's not our
>> place as protocol designers to tell people what they may use.
> 
> The export sections of TLS seem to me to be a holdover from the SSL
> legacy days and are there mostly for compatability.  OpenPGP pays no
> attention to this issue as it isn't appropriate to have such limits in an
> international standard.  Clearly, an implementation could choose to
> implement their own ciphersuites for export algorithms with OpenPGP keys,
> but there doesn't seem to be any reason to specify those as none of the
> export quality algorithms are supported by OpenPGP.  Simply removing the
> statement does seem appropriate however making them implicitly excluded
> rather than explicitly.

While I support the ideal of building standards that use strong crypto, it
does nobody any good to create a standard which won't get implemented.  The
export ciphers exist because in order for US software manufacturers to use
TLS, they have to be able to export the software that includes it.  It is
certainly true that there are many software developers who live in the
free world, but those of us stuck in the US still need to sell software.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before      | tomw@xxxxxxxxxxxx
transcending structure.  -- The Tao of Programming   |