Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd)

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Nov 2011 23:47:45 -0800

Extending TLS to support a raw public key seems like a good idea and
I support taking it on.

Extending it to suppress the public key and instead send a hash from server
to the client seems less so; if the server sends the public key, it works
if the client knows either (a) the server public key or (b) a digest of the
public key. Sending a digest only works if the client already knows the
public key, which seems far less likely. If you want to suppress the
server sending the key, a better (and more general) solution is to
resurrect cached-info. This would work with both raw keys and
certificates.

-Ekr

On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters <[email-masked]> wrote:
>
> This is the new version of the draft incorporating the feedback from Quebec
> City
> and the TLS list since then. It changes the draft from a new TLS extension
> to a
> new Certificate Type for raw keys.
>
> It also merges in the unpublished draft material from Hannes Tschofenig
> and Tero Kivinen <[email-masked]> whom had also been working on raw RSA
> TLS keys for use with CoAP (eg devices with no real time clock where
> PKIX validation cannot work)
>
> I did not yet change the draft ofrom individual submission to working group
> item,
> as I was waiting for confirmation on the TLW WG list of the last Quebec City
> meeting.
>
> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01
>
> Paul
>
> ---------- Forwarded message ----------
> Date: Mon, 31 Oct 2011 17:44:35
> From: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
>    [email-masked], [email-masked]
> To: [email-masked]
> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt
> X-Spam-Flag: NO
>
> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been
> successfully submitted by Paul Wouters and posted to the IETF repository.
>
> Filename:        draft-wouters-tls-oob-pubkey
> Revision:        01
> Title:           TLS out-of-band public key validation
> Creation date:   2011-10-31
> WG ID:           Individual Submission
> Number of pages: 11
>
> Abstract:
>   This document specifies a new TLS certificate type for exchanging raw
>   public keys or their fingerprints in Transport Layer Security (TLS)
>   and Datagram Transport Layer Security (DTLS) for use with out-of-band
>   authentication.  Currently, TLS authentication can only occur via
>   PKIX or OpenPGP certificates.  By specifying a minimum resource for
>   raw public key exchange, implementations can use alternative
>   authentication methods.
>
>   One such method is using DANE Resource Records secured by DNSSEC,
>   Another use case is to provide authentication functionality when used
>   with devices in a constrained environment that use whitelists and
>   blacklists, as is the case with sensors and other embedded devices
>   that are constrained by memory, computational, and communication
>   limitations where the usage of PKIX is not feasible.
>
>   The new certificate type specified can also be used to reduce the
>   latency of a TLS client that is already in possession of a validated
>   public key of the TLS server before it starts a (non-resumed) TLS
>   handshake.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 17 Nov 2011 18:40:43 +0800

Hi Paul,

could you please drop this sentence from your draft?

  For example, if public keys were obtained using [DANE] it
  is appropriate to use DNSSEC to authenticate the public keys.

I know that it's just an example, but I can see that this could
lead to chaos and mayhem if the DANE protocol makes different
assertion in the future.  So unless DANE protocol blooms into the
RFC before your draft, please don't make any assumptions, thanks.

And one minor nit, change

   Some small embedded devices use the UDP based [CoAP], a specialized
   constrained networks and nodes for machine-to-machine applications.

to

   Some small embedded devices use the UDP based Constrained Application
   Protocol [CoAP], a specialized web transfer protocol for use with
   constrained networks and nodes for machine-to-machine applications.

or simpler

   Some small embedded devices use the UDP based Constrained Application
   Protocol [CoAP] for use with constrained networks and nodes for
   machine-to-machine applications.

for better readability.

On 1. 11. 2011, at 7:21, Paul Wouters wrote:

> 
> This is the new version of the draft incorporating the feedback from Quebec City
> and the TLS list since then. It changes the draft from a new TLS extension to a
> I did not yet change the draft ofrom individual submission to working group item,
> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository.
> 

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2011 11:20:18 -0500 (EST)

On Thu, 17 Nov 2011, Ondřej Surý wrote:

The -02 draft went out before I could respond to this....

> RFC before your draft, please don't make any assumptions, thanks.

Though I see your point, I cannot really see any case where a TLS
implementation would obtain a public key from DNS without any PKIX
information and without any DNSSEC protection. In this case there is
not even the PKIX fallback information to go on, so regardless of what
DANE decides to do for "validatable PKIX", a TLS client MUST NOT use
a TLSA record containing just a public key if it did not authenticate
that data with DNSSEC.

Perhaps it can be reworded? But I think it is a valid security concern
to point out people should not just pluck spoofable TLSA records from
DNS and build a TLS trust relationship based on that. Even if DANE
decided to always mandata DNSSEC, I think it is a good reminder to
make that explicit in the Security Considerations here?

>   machine-to-machine applications.

Thanks. I've made the changes and the will be in the next draft.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 18 Nov 2011 01:06:52 +0800

> a TLSA record containing just a public key if it did not authenticate

I think it's perfectly fine to say, what you are saying in the first
part of the paragraph:

   Depending on exactly how the public keys were obtained, it may be
   appropriate to use authentication mechanisms tied to the public key
   transport.

but I object to saying what that means in the other (DANE) protocols.

Or speak about the protocols which have the security properties already
defined (LDAPS?).

> DNS and build a TLS trust relationship based on that.

I agree with you, but this is not the place to say that.

> Even if DANE

You can reword it to make it more general - less DANE-centric.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 17 Nov 2011 11:24:12 -0600

Question. This item:
> o  A TLS client has connected to the TLS server before and has cached
> the TLS server certificate chain or TLS server public key for re-use

Is that behavior endorsed by current RFCs, or is server cert caching a
new optimization being enabled by this draft (perhaps in conjunction
with HSTS pinning)?

Seems like that topic could merit a whole nother RFC of its own. Maybe
reference that or drop it from here?

Clearly this document "specifies a new TLS certificate type for
exchanging raw public keys or their fingerprints in TLS and DTLS". But I
guess the deeper question is to what extent this draft intends to
endorse ad-hoc approaches to TLS authentication when it says "By
specifying a minimum resource for raw public key exchange,
implementations can use alternative authentication methods."

In the Security Considerations there is the statement "A client using
this cert_type needs to be confident in the authenticity of the public
key it is using." This is obviously correct, but is it worded strongly
enough?

For example, it's no secret that a great many non-browser TLS client
applications do not bother with cert validation or they fail to check
that the cert matches the host they requested. Often they allow plain IP
addresses in their configuration. Today we can say this is against
various RFCs, but if this draft were accepted perhaps such clients would
be able to simply request cert type RawPublicKey and say "yep, looks
good enough for me therefore I am RFC-compliant!"

This is an ongoing discussion that I encounter among users and app
developers on a regular basis. For example:
> http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2011-02/msg00650.html

On 11/17/2011 10:20 AM, Paul Wouters wrote:
>  not even the PKIX fallback information to go on, so regardless of
> what DANE decides to do for "validatable PKIX", a TLS client MUST
> NOT use a TLSA record containing just a public key if it did not
> authenticate that data with DNSSEC.
>
> Perhaps it can be reworded?

Perhaps you could use a different example such as:

* Certs obtained via LDAP (e.g. http://tools.ietf.org/html/rfc4523 )

* IPsec using X.509 certs http://tools.ietf.org/html/rfc4301

* Established SSH RSA keys (if this is actually well-defined)

Just some ideas.

> But I think it is a valid security concern to point out people
> should not just pluck spoofable TLSA records from DNS and build a TLS
> trust relationship based on that. Even if DANE decided to always
> mandata DNSSEC, I think it is a good reminder to make that explicit
> in the Security Considerations here?

I agree that it's worth repeating on principle, but I don't think it's
necessary to include more of an explanation of the full PKI security
model. Just a reference should do.

- Marsh

---

From: Badra <[email-masked]>
Date: Fri, 18 Nov 2011 21:02:07 +0100

Hi,

What happened to draft-ietf-tls-cached-info-09?

And how does draft-wouters-tls-oob-pubkey differ
from draft-ietf-tls-cached-info-09?

Best regards,
Badra

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Nov 2011 16:06:02 -0500 (EST)

On Fri, 18 Nov 2011, Badra wrote:

> And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09?

cached-info still needs PKIX validation on the first run, and then supports caching
the authentication. oob-pubkey allows for out of bound public key authentication
with tls server suppressing the sending of its (often huge) unneeded PKIX chain.

This avoids conflicting information (eg between DANE and PKIX), removes the need for
(re)generating bogus PKIX containers with self signed certs and dozens of subjctAltnames
and enables CoAP devices with are lacking the resources for PKIX do engage in TLS.

Paul

---

From: Martin Rex <[email-masked]>
Date: Fri, 18 Nov 2011 22:42:01 +0100 (MET)

Paul Wouters wrote:
> Badra wrote:
> cached-info still needs PKIX validation on the first run, and then
> supports caching the authentication. oob-pubkey allows for out of
> bound public key authentication with tls server suppressing the
> sending of its (often huge) unneeded PKIX chain.
> 
> This avoids conflicting information (eg between DANE and PKIX),
> removes the need for (re)generating bogus PKIX containers with
> self signed certs and dozens of subjctAltnames and enables CoAP
> devices with are lacking the resources for PKIX do engage in TLS.

I do not see this as an appropriate characterization.

The use of X.509v1 self-signed certs as public key containers is
pretty trivial and pretty common -- and it works with pretty much
all of the installed base of TLS.

A single X.509v1 self-signed cert means that there is *no* "PKIX Chain"
and it also precludes PKIX validation (which is *NOT* required by TLS, btw.).
For the servers purpose of sending it in the Certificate handshake
message it is a simple blob of a few hundred bytes, so that is the
most trivial part of the protocol.  Parsing the subject key info
from a X.509v1 cert is only marginally more difficult than parsing it
from any other public key format, and doable with a pretty small
code footprint.  You don't need PKIX to do that.

The general rule for TLS handshakes should be that a *real* negotiation
ought to be performed in a fashion that the handshake will succeed in
case there is a chance to make it succeed.  Having one peer make
optimistic false assumptions, fail the handshake and retry with a
different assumption is a defect and should *NOT* be standardized.

A TLS extension to the effect

  Client: "I assume I'm in possession of your key, don't send it"
  Server: "OK, I won't"

would seem pretty strange.

It should probably be something like:

  Client: "I assume your key is <hash-of-key>. If I'm right, you don't
           need to send it"
which may result in two possible answer:

  (A1) Server: "You're wrong.  I will send you my key."
  (A2) Server: "You're correct.  I will omit it from the handshake."

That is basically what the TLS caching extension intends to provide for
existing elements of TLS protocol PDUs (e.g. server cert chain in
the server's Certificate handshake message, certificate_authorities
in the CertificateRequest handshake message).

IMO it would be OK for any _new_ TLS extension to include caching
in order to save network bandwidth on average.

But what I seem to be hearing is "I want to not transfer this information
inside the TLS protocol at all, because parsing this data is so notoriously
difficult.  But you *MUST* have a means to convey (and therefore parse)
that data anyway, or it can not possibly work.  Why would you want to
turn in minuscule trivially solvable problem into a major and entirely
undefined problem?

-Martin

---

From: Badra <[email-masked]>
Date: Fri, 18 Nov 2011 23:24:28 +0100

On Fri, Nov 18, 2011 at 10:06 PM, Paul Wouters <[email-masked]> wrote:

>  And how does draft-wouters-tls-oob-**pubkey differ
>> from draft-ietf-tls-cached-**info-09?
>>
>
> supports caching

And how, in your draft, will the client have a copy of server's
authenticated key?

Currently, the server doesn't need to describe known roots. Does it mean
that the server also has a copy of the client's authenticated key?

Best regards,
Badra

---

From: Paul Wouters <[email-masked]>
Date: Fri, 18 Nov 2011 18:20:06 -0500 (EST)

On Fri, 18 Nov 2011, Badra wrote:

> And how, in your draft, will the client have a copy of server's authenticated key? 

The draft is called "out of band" for a reason :)

One method is to get it via DANE/DNSSEC, for example:

dig -t TYPE65468 _443._tcp.dane.xelerance.com

That will give the client an authenticated hash of the public key. During the TLS
handshake, the TLS server gives the TLS client its public key in the server certificate
of cert_type "RawPublicKey".

The DANE draft does not (yet) have a subtype for "raw key" but is expected to get one as
soon as TLS defines the cert_type (which this draft would do)

> Currently, the server doesn't need to describe known roots. Does it mean that the server also has a copy of the client's authenticated key?

If the TLS server wants to authenticate the TLS client, it will also need and out-of-band
authentication. The TLS client will send its public key in a certificate of cert_type="RawPublicKey"
and the TLS server will have to lookup that key for authentication. (to make that easier on
the server, perhaps we can think about the client version of "SNI", but we left that out of
this draft not to complicate things at this stage)

Paul