[Prev][Next][Index][Thread]
Re: 5/29 TLS Meeting Notes
Tom Stephens writes:
>
> A subset (see attendees below)
Unfortunately Tom left my name off his list of attendees.
I also took notes, and a couple days ago sent my notes out to the
attendees of the 5/29 meeting for review. I have heard back from some
of them and incorporated their additions. I will HTMLize these notes
and put them up at http://www.lne.com/ericm/tls_meeting.html.
As I receive more feedback from people who were at the meeting
I will include that in the HTML version.
Here's my notes from the TLS working group meeting
in Palo Alto 5/29/96.
Attendees: 27 people.
9 people from Netscape.
3 from Microsoft.
others from: Consensus, CompuServe, Raptor, DEC, Atalla (Tandem)
iPower (National Semi), Sun, IBM, Terisa, LNE and UCSD.
Microsoft asked Bruce Schneier to moderate.
Bruce did an outstanding job of moderating a somewhat
contentious meeting. It was suprisingly productive.
To start, we made a list of topics. From these we picked
items to not consider at this meeting, because there is
general agreement on what to do about them:
-end-point security
-APIs
-ASN.1
-direct interaction with LDAP/X.509
-certificate management
-cookies to prevent denial of service attacks by forcing parties to
do RSA calculations over and over (IPSEC has done work on this problem)
For all of these I think the groups's feeling was that they are either not
relevant to the TLS standard or should not be in it.
For the rest of the topics, we picked ones that we thought it would
be fruitful to talk about in person rather than on the mailing list.
For these topics, I'll list each topic along with salient points.
For the purposes of this meeting we called the version of the spec that
we are creating "SSL 3.1", although there is extreme disagreement as
to the actual name of the thing we're making...
-----
Independent Algorithim negotiation
This is the idea of seperating the CipheSuites into their components
(MAC, symmetric algorithim, KEA etc) and negotiating those seperately.
For: allows easier replacement of bad algorithims (i.e. MD5 is
broken, so you just stop using it rather than having to stop using all
CipherSuites that use MD5). Makes for easier coding.
Against: allows exponential explosion in combinations, some of
which might not be secure (i.e. CRC32 with 3DES is secure but
CRC32 with RC4-40 is not).
Counter: Also include rules to eliminate poor combinations, method
of exchanging rules unspecified.
Resolution: WG will accept proposal, probably won't be in 3.1.
------
Password authentication
Passwords would be embedded in the SSL negotiation itself
rather than in the application protocol on top of SSL.
For: Strong encryption of password. Standard way of exchanging passwords.
Against: passwords are a legacy of existing apps which already
exchange passwords in the application layer, so password auth
in SSL duplicates this. May not be export-legal. Should encourage
SSL adopters to use (strong) certificate-based auth rather than
weak password-bases auth.
Counter: Add field in protocol to allow for strong encryption of
unspecified data [which almost assuredly won't be export-approved -ericm].
Resolution: tabled for now, Dan Simon to write postition paper.
-----
Certificates
Actually 4 topics:
Certificate Selection
Allows one party to request a specific certificate
For: Needed to support situations where parties have > 1
applicable certificate (i.e. virtual domains in web servers).
Against: Complicated, breaks backwards compatability with SSL3 & 2.
Resolved: length of CLIENT_HELLO message will be allowed to be longer than
the Handshake length, the extra bytes will be unspecified for now
but will allow for forward compatability.
Tom Weinstein to add language to the SSLv3 spec that says
that the handshake header length is what should be read and grokked
by SSLv3 but the rest of the CLIENT_HELLO (if there is more)
should be ignored.
Someone else (I forgot who) will take the action item of proposing
what to do whith the extra bytes in 3.1.
--
Attribute certificates
Attribute certs are certs without keys but with X509.3 attributes.
They're supposed to be short-lived certs to exchange some authenticated
info, prove the granting of temporary priveledges etc.
For: needed feature.
Against: Against: Attribute certificates are for use for access control
at the application layer, and don't really have anything to do
with transport layer security (authetication, confidentiality,
and data integrity).
Resolved: I think we resolved to do it later.
--
Short-cut certs
Short-cutting is when the client already knows the server certiticate
and says so in the CLIENT_HELLO. So both parties can skip
the certificate exchange and get to exchanging keys for the session.
For: gets rid of a round-trip in the key exchange protocol.
Reduces length of protocol exchange.
Makes protocol more symmetric.
Against: requires re-write of protocol. Adds yet another path
of message ordering between client and server.
Makes protocol more symmetric.
Resolved: Requires more symmetry to be workable, so it's tied in
with that- Dan Simon to write paper.
--
CRLs
Certificate Revocation Lists-
For: needed to support complete X.509 cert model.
Against: too many different ways to do CRLs, none of
which are obviously right at this time.
Resolved: tabled for later, much later.
-----
Key Reset
The ability to reset the master key to a specified value.
For: required for pre-encrypted data. Useful for "smart" cards?
Against: Unsure how to do securely?
Resolved: Phil Karlton to write paper.
----
Pre-encrypted data
The ability to pre-encrypt data that will be served via SSL
repeatedly.
For: Saves (server) CPU cycles.
Against: Also requires pre-formatting in SSL record format.
CPU cycle savings minimal compared to public-key operations and
MAC operations. Requires Key Reset. Possible security problems- clients
can discover the pre-encryption key, if that key is used for other
communications with other clients those communications can be compromised.
Resolution: Bennet Yee to write paper.
-----
Pre-MACd data
Data is MACd with MAC secret in the usual SSL way, seperated
into SSL records, saved to a file.
For: Saves (server) CPU cycles.
Against: would reveal MAC secret.
Paul Kocher suggested a possible way to do it securely, wants more
time to think about it.
Resolution: Bennet Yee to write paper
-----
Datagrams
Extend SSL to support unreliable transport i.e. UDP.
For: UDP services could use SSL. Some mixed TCP/UDP services
(i.e. PPTP) could use SSL.
Against: Not in charter. UDP has no flow control so SSL would
have to do it. Some parts already in place (i.e. record sequence
numbering) but not all.
Resolved: Deferred to after 3.1.
-----
Hardwired Hash
Remove the hardwired handshake hash algorithim from the spec, make
it negotiable.
For: MD5 will be broken soon, what if SHA1 is broken soon?
Need to be able to add new algorithims without rewriting spec.
Against: if it's negotiated in the protocol, MITM could force
downgrading to the weakest hash. This would be a problem if
MD5 is broken and left as an option in operating software.
Resolved: Handshake hash algorithims to be specified in an appendix
instead of main document. MD5 to be replaced with RIPEMD-160.
"New" HMAC method to be used, where the pad values are XORd
rather than appended. Paul Kocher to add to spec for 3.1.
-----
Symmetry
Make client and server sides of the protocol (more) symmetric.
For: makes coding easier, code smaller.
Against: too much work to do now. General agreement that it's
good in principle but a pain to spec.
Resolved: not in 3.1. Dan Simon to write paper.
-----
Extensibility
Forward compatability from SSL3.0 to 3.1. CLIENT_HELLO message to
allow for extra fields.
For: Needed to allow SSL3.0 clients to talk to SSL3.0/3.1 servers.
Against: no argument that I can remember other than Netscape
saying that it's too late for them to change their code.
Resolved: SSL3.0 spec to allow CLIENT_HELLO record length to
be longer than the handshake record length. The extra bytes
are for new fields in 3.1. Tom Weinstein to add to SSL3.0 spec.
-----
Compression Algorithim spec
Need at least one (non-encumbered) compression algorithim to put
into spec.
For: compression is good.
Against: no argument.
Resovled: Someone to post specs of an algorithim developed
at DEC that is not patented.
-----
Naming
What should the name of the TLS group's spec be?
Proposals: SSL3.1, STLP, PK1, TLS
There was, as you'd expect, no agreement on this and argument was
split largely on the lines of corporate affiliation.
SSL3.1-
For: name recognition, the spec will be based on SSL3 so the
contribution of SSL should be noted in the name.
Against: SSL is thought of as a Netscape-owned thing, however this
is an IETF-owned spec.
STLP-
For: good name, not SSL.
Against: STLP was the name of the Microsoft "strawman" document
which generated some bad feelings as it appeared that Microsoft
was attempting an "end-run" around the IETF process.
PK1-
PK stands for Paul Kocher and Phil Karlton, two main contributors to
the SSL3 spec. There were two strong votes for this name. :-)
TLS-
For: a name not "owned" by either Microsoft or Netscape (or an
other corporate entity).
Against: zero name recognition, not a sexy-sounding acronym. The
only people who want it are the ones who work for neither Netscape
or Microsoft, although each side seems willing to accept it
when it appears that the other side's name is going to be accepted. :-)
-----
Interaction of Application and TLS
The limits of what the application can do and should be able to limit were
discussed. This is most an implementation/API issue.
The application can query the cipher spec and the
certificate of the connection. It also can set the possible cipher
suite. This would allow the application to know the strength of
encryption, signature, etc for all data passed over a given session.
For: Applications need to know what security services are being provided
Against: An API issue.
Resolution: Mark Davis (IBM) would write a paragraph on this for
inclusion in the spec as guidance to implementers.
--
Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF
References: