Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls

From: Will Price <[email-masked]>
Date: Thu, 17 Jan 2002 19:00:56 -0800

Eric Rescorla wrote:
> Will Price <[email-masked]> writes:
> > Another important point about backwards compatibility: the
> > current OpenPGP/TLS draft already has well over a million
> > deployed clients. Every PGP client since I believe 6.0.0
> > (September 1998) supports PGPtls as described in the draft, and
> > every PGP Keyserver since that time period also supports PGPtls.
> I don't find this argument very convincing. You implement things
> that are Internet-Drafts at your own risk. That's why every I-D
> has a disclaimer at the top. If popularity were the criterion
> for standardization, we could disband the IETF and just wait
> for Microsoft to tell us what the standard was.

We published the draft, then we implemented, then we published code.
This is standard procedure for anybody in the IETF. Implementations
and implementation experience are critical factors in the WG, and if
they could be ignored then TLS/SSL would be quite different today I'm
sure you'll admit.

> > In addition to ignoring all the fielded uses and implementations
> > of OpenPGP/TLS, Nikos' proposed changes also suffer from the
> > dependency problem on the TLSEXT draft,
> This is a feature not a bug.

Definitely seems like a bug to me. When I originally designed this,
it was clear that TLS should have had a standard way of choosing a
certificate type much like IKE does. I believe I raised this issue on
the list at the time and the response of the list was IIRC muted
agreement, but there were no plans for a new version of the TLS draft
so it wasn't a discussion that was going to go anywhere. The others I
spoke with in the WG felt that using the cipher suite field was the
way to go.

Writing a draft for a new certificate type which defines an impromptu
technique for how to negotiate an OpenPGP certificate type is clearly
not the way to go. TLS should always have had a certificate type
field built-in. Were TLS to have such a standardized method, the
OpenPGP/TLS draft should be modified to adopt that.

However, it's not particularly important that such a method be
developed. No more than 2 perhaps 3 certificate types will survive
into the future, so that doesn't appear to be a serious concern.
Worrying about running out of 16 bit space for cipher suites is
unnecessary to me. We should now and should always have been
conservative about which cipher suites get assigned numbers. No more
than 20 cipher suites are in active use today, and going forward into
the future I expect those to change but the overall number of
actively used cipher suites will get smaller converging on the
popular few.

- -- Will

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

---

From: Will Price <[email-masked]>
Date: Thu, 17 Jan 2002 20:11:51 -0800

History shows that is not actually true. For instance, TLS is almost
identical to SSL. Why is this? Is it because "implementation
experience" showed that SSL was simply the One True Way to write a
transport security protocol? No. It's because there was a large SSL
installed base of which the TLS designers wanted to take advantage,
and thus the more identical the protocol was the more it would be
accepted.

- From an implementation experience point of view, I would say that the
last four years have demonstrated the cipher suite space issue is not
an issue, and the "we're going to run out of space" argument is the
only one made to defend this negotiation proposal which depends on an
extension proposal. Time has demonstrated that particular sky is not
going to fall, and thus in the absence of any method in the standard
to specify certificate type the cipher suite field remains the
correct place to put this.

Eric Rescorla wrote:
> Implementation experience is an important factor. The existence of
> implementations which were written pre-Proposed and which would be
> broken by a new specification isn't. If you want to argue that your
> implementation experience indicates that this is the right approach
> and some other approach is wrong, go ahead. I don't see you arguing
> that. Rather, I see you arguing that you (and presumably others)
> have implemented a specific approach and would be inconvenienced by
> any other approach, regardless of its technical merits. That's not
> the basis on which the IETF is supposed to make decisions.

- -- Will

---

From: Will Price <[email-masked]>
Date: Thu, 17 Jan 2002 21:11:01 -0800

Eric Rescorla wrote:
> > History shows that is not actually true. For instance, TLS is
> > almost identical to SSL. Why is this? Is it because
> > "implementation
> > experience" showed that SSL was simply the One True Way to write
> > a transport security protocol? No. It's because there was a large
> > SSL installed base of which the TLS designers wanted to take
> > advantage, and thus the more identical the protocol was the more
> > it would be accepted.
> Funny, I think of the TLS experience the opposite way: Despite
> the fact that SSL had an enormous installed base TLS is
> incompatible with SSL.
> 
> > - From an implementation experience point of view, I would say
> > that the last four years have demonstrated the cipher suite space
> > issue is not an issue, and the "we're going to run out of space"
> > argument is the only one made to defend this negotiation proposal
> > which depends on an extension proposal.
> No. Even in the absence of the cipher suite depletion argument,
> your approach would be a clumsy hack. Orthogonality is a good
> thing.

Orthogonality?  Like the orthogonality of lumping the cipher type,
key length, hash type, key exchange type, and export status into one
sixteen bit number?  I don't think so. Sorry, that argument doesn't
fly in the context of TLS. The Orthogonality to the Nth degree
doorway is in the IPsec WG.

For TLS 1.0, the cipher suite remains the right place to put this.
What we wanted in 1998, and what we still want today is a TLS 1.1
which has a field for the certificate type.

I think we both agree in principle that certificate type should have
had its own field. The difference is that you're willing ditch
backwards compatibility and change OpenPGP/TLS to include its own
clumsy hack for specifying the certificate type and depend on yet
another draft, whereas we've done things the TLS 1.0 way in TLS 1.0
and would support fixing the protocol itself in a future rev.

- -- Will

---

From: [email-masked]
Date: Fri, 18 Jan 2002 10:41:23 +0200

Werner Koch wrote:

> On 17 Jan 2002 09:52:24 -0500, Derek Atkins said:
> 
> > You probably do not want to assume that the fingerprint is 20 octets
> > long; fingerprints on v3 RSA keys are only 16 octets long.  So, your
> 
> Left pad them with zeroes and store the fingerprint

maybe right pad fingerprint with keyid.
but there is only space for short 4byte keyid..

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)