ietf-openpgp
[Top] [All Lists]

Re: Proposed Extensions to TLS for OpenPGP

1997-12-31 16:17:17

As Will has now posted PGP's SMTP over TLS document now, I thought I
re-post this comment on authenticating TLS with keys from another
domain (PGP WoT domain).

This would neatly avoid the complexity of adding PGP certificates to
TLS because unauthenticated (and preferably forward secret) modes
could be used for TLS such as ADH (anonymous DH). (ADH-DES-CBC3-SHA
being the strongest of the unauthenticated cipher suites).

The point at which you would tie together the key material from the
PGP WoT based authentication with the TLS pre-master-secret I have not
considered in depth so far.

Adam

==============================8<==============================

Date: Sun, 26 Oct 1997 12:26:52 GMT
From: Adam Back <aba(_at_)dcs(_dot_)exeter(_dot_)ac(_dot_)uk>
To: <another list>

One thing I'd like to see discussed is TLS (Transport Level Security)
for delivering pgp encrypted mails.

One objection to TLS is that it's difficult to authenticate without
key management.  This is true enough, though there is some value in
PFS (Perfect Forward Secrecy) TLS even without authentication -- this
value is that it forces an attacker to be active to even be able to
archive encrytped traffic.

The presumption is that a) active attacks are harder, and that b)
governments will find it harder to do lots of active attacks at once.

So PFS TLS is a good trend for protecting against future government
abuses... if lots of software is using PFS TLS, well government will
have some problems recalling all that software, and persuading people
to downgrade.


That's unauthenticated PFS TLS.

But I reckon this hack works: with PGP you've already got a WoT (Web
of Trust), so you don't need a separate key infrastructure to
authenicate TLS, and this is good because deploying automatic key
infrastructures (such as perhaps for DNSSEC) is complex.

The way to use PGP's WoT for TLS authentication is to have a
communication between MUA (Mail User Agent, eg a future pgp6.0) and
the MTA (Mail Transfer Agent, eg SMTP, or SMTP agent with SMTP
extensions).

It is even possible to have non-interactive, one sided communications
between sending MUA and MTA, and between receiving MTA and MUA which
is a good thing as it is after all store and forward and there may be
some local store and forward hops on the way to the TLS secured SMTP
delivery over the Internet, and some further local hops after receipt.

I figure all that is needed is this:

                           TLS secured link
MUA1 --> MTA1 --> TLS-MTA1 ================> TLS-MTA2 --> MTA2 --> MUA2

MTA1 and MTA2 represent local MTAs just distributing email inside an
organisation (inside the firewall), and just serve to show that any
communications better be one-sided, and not require replies.

TLS-MTA1 and TLS-MTA2 are the MTAs which actually send info out
through the firewall.

The topology of the communications suggests that MUA1 can send to
TLS-MTA1, but can't expect a reply.  And that TLS-MTA2 can send to
MUA2, but can't expect a reply.

You can authenticate the TLS link based on the PGP WoT using that
communications pattern.

MUA1 -> TLS-MTA1 communication would be a key k1 to use for
authentication.  The key would be sent as a mail-header:

X-auth-key: 0x1234132413241324

TLS-MTA1 would authenticate with this key.  (Perhaps computing a hash
of the negotiated DH (Diffie-Hellman) or transient EG (El Gamal) key
and the key.  Perhaps:

auth1 = hash( k1 || negotiated-dh-params )

The authentation information would be sent as a mail header, and the
key information would be removed, so X-auth-key line would be removed,
and this line added:

X-auth: 0x567856785678578578578

Then TLS-MTA2 (the recipient TLS) would just pass this info on
unchanged.

The receiving MUA would also need the information about the
negotiated-dh-parameters, that info would have to be sent to it by the
recieving MTA, presumably with another header:

X-auth-parameters: 0x123413241324, 0x3653563463654563653

or whatever.

Then the receiving MUA can check the X-auth line agains the key k1
included in the PGP encrypted message, by recomputing:

auth1 = hash( k1 || negotiated-dh-params )

The key k1 would be included inside the pgp message (or perhaps be
derived from something which is already there, perhaps k1 = hash(
session-key), the hash of the symmetric session key used to encrypt
the message).

The MUA would use the X-auth field to check the TLS authentication.
A MITM could be flagged by the recipients MUA.

Adam