Re: IETF mtg discussion comments

From: "Paul C. Kocher" <pck@best.com>

> Bennet Yee writes:
>> 1.  Does pre-encryption prevent MACs from being encrypted?
>>      [...]
>> 8.  Features are Optional
>>
>> Pre-encryption, pre-MAC-ing, ans password authentication are all
>> independent options that are (typically) server configuration choices.
>
> Pre-encryption selection will require significant changes to how the
> ciphersuites are negotiated, since some can support pre-encrypted data
> and others probably won't be able to (i.e., Fortezza).


At the meeting Paul was extremely apologetic that the IETF process had
broken down and that much TLS work had recently occurred via private
email and/or voice mail; both Paul and Win agreed to fix the process.

Paul, thank you for posting portions of Bennet's comments.

Bennet, I hope you will consider discussing protocol features publicly
on the TLS list instead of in one-to-one email.

------------------

My (incomplete, but perhaps better than nothing :-) notes from the TLS
working group meeting in Montreal last week are as follows:

1. Should the TLS working group use SSL 3.0 as a starting point, or define
a list of requirements and a universe of candidate protocols (SSH, PCT,
Hannah, others?) which satisfy some or all of the requirements?

The question was posed but never definitively answered - my impression
was that there was consensus for using SSL 3.0 as the baseline, but to
give more than just lip service to features of other protocols (such as
SSH's ciphersuite-guessing quick startup) that are missing from SSL.

2. Timing - the real need to have a proposed-standard RFC out in a
short timeframe (by Dec 1996) was acknowledged, but many of those present
were averse to the idea of having the IETF merely rubber-stamp a vendor
proposal.  Jeff Schiller noted that the requirements for proposed standard
are fairly loose - the protocol must be well-specified to allow independent
implementations, but no actual implementations are required.  SSL and SSH
both appear to exceed the requirements for specification quality.  There
is a 6 month to 2 year timeframe between Proposed- and Draft- Standard
status, and a minimum of 4 months between Draft- and (full) Standard.

Christopher Allen was among those strongly in favor of quickly defining
a TLS 1.0 protocol, delaying agreement on contentious elements until a
1.1 version.  I don't have a strong objection to this, as long as there
is a clear understanding and agreement by the commercial sponsors that
additional requirements *must* be resolved by the WG before progressing to
Draft.  The tradeoff is between early adoption of a Proposed standard
and quick progression to Draft; the total time for resolving contentious
issues will probably be the same either way.

3. Specific Features:

 a) Improved set of error alerts: no disagreement on the need for this,
    no discussion of specifics.

 b) Password authentication:

(from pck:)
>  Two issues we need to decide:
>
>    - Whether to support password authentication at the TLS level.
>      (Type 2 can be done today by applications using SSL 3.0)
>      I think everyone here wants to see a certificate-based
>      infrastructure get developed as quickly as possible, but it
>      isn't clear whether giving people an alternative to certs
>      is good (because it helps them make the transision to
>      certs more smooth) or bad (because it gives them a way to
>      avoid switching to certs).
>
>    - Whether passwords have to be protected from brute force
>      attacks.

I don't give much weight to meta- (or religious) arguments that
passwords are good or bad for the proliferation of public key
authentication; the issue is how password support impacts the protocol
(in terms of cryptographic strength, difficulty of analysis, ease of
development, run-time performance, backward compatibility, etc.).

The purpose of password support is to provide authentication-quality
protection, as opposed to exportable-confidentiality-quality, protection
for static (reusable) passwords.  In the absense of export controls,
there would be no need for special protocol support for password
protection - they could just be sent like any other application data.

Dan Simon's presentation leads me to believe that modifying SSL 3.0
to support password protection (by defining two additional handshake
messages, but not requiring any changes to the record layer) can be
done without negative impact on security or performance.  If the
feature is not used, there is no change to the bits-on-the-wire.
There is apparently strong commercial demand for this feature.  My
previous opposition to password support was based on a misunderstanding
of what it accomplished; I now have no objection to including it in
the TLS protocol.

There was no poll on password support taken at the WG meeting.

Paul's 3 approaches:
1) use the standard encryption key - i.e. treat passwords like any other data
2) use a value derived from the master secret to hash passwords
3) give the master secret to applications

1 is the "do nothing" option; 3 is unpleasant because it precludes the
possibility of isolating the crypto subsystem from unwashed, untrustworthy
applications.  Option 2 is preferred - the password authentication secret
should not be the master secret or the MAC secret directly, it should be
derived from the master secret in the same way as the rest of the
"independent" keying material.


  c. Pre-encryption.  A poll was taken on this topic:  precisely 2 of
the members present were in favor of pre-encryption support, a minority
of those present were willing to at least listen to arguments in favor
of pre-encryption, and a majority were strongly (Win used the word
"absolutely") opposed.

That seems like more than rough consensus - although a follow-up should
be taken here on the list to confirm.

My objection to pre-encryption is that even when it is not used, it
requires potentially damaging changes to the MAC calculation (replacement
of the inner hash key with a fixed value).  Aesthetic objections
to "layering violations" aside, I don't believe it's wise to trade off
protocol strength for server efficiency.

And since Web containers being developed for other purposes (document
protection independent of the transmission channel) have the side effect
of providing the same efficiency gains, there is little reason to try to
make pre-encryption "invisible" to clients by trying to disguise
Independent Data Unit Protection as session protection, weakening the
session protection in the process.


  d. Modularity (separation of the record layer from the handshake layer):
This was not discussed by Win, Paul, Netscape or Microsoft, but there was
strong grass-roots support from the floor (including Eric Rescora) that
TLS should be designed to accommodate multiple keying mechanisms.
Unfortunately, the IPSEC working group was unable to achieve consensus
on a key management protocol at this time, but Jeff Schiller set a
deadline of 1 September for the ISAKMP and SKIP sponsors to come to
agreement, otherwise the IESG will make the decision.

If an IETF key management protocol is defined, TLS should be able to use
it.  I am strongly in favor of an independent record layer, for reasons
discussed earlier on this list.  Bennet Yee also made some excellent
comments regarding the requirements a keying API must satisfy.


  e. Negotiated or fixed hash algorithms - little discussion, no resolution.

  f. Dedicated or standard tcp port numbers - ditto.

  g. Name of the protocol - ditto, although like Phil Karlton and Paul
Kocher, I (david P. Kemp) think "PK" has a nice ring to it :-).

Received on Monday, 1 July 1996 17:45:28 UTC