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

From: Paul Wouters <[email-masked]>
Date: Fri, 20 Jan 2012 18:54:36 -0500 (EST)

The only changes to the document is a typo (out of bound -> out
of band) found by Bill Frantz and an updated reference to a newer
draft-ietf-dane-protocol version.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-oob-pubkey-01.txt

I believe this document is ready for WGLC.

Paul

---------- Forwarded message ----------
Date: Fri, 20 Jan 2012 18:06:02
From: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], 
[email-masked],
     [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-ietf-tls-oob-pubkey-01.txt

A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been successfully 
submitted by Paul Wouters and posted to the IETF repository.

Filename:	 draft-ietf-tls-oob-pubkey
Revision:	 01
Title:		 TLS Out-of-Band Public Key Validation
Creation date:	 2012-01-20
WG ID:		 tls
Number of pages: 10

Abstract:
    This document specifies a new TLS certificate type for exchanging raw
    public keys 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

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Jan 2012 02:23:23 +0100 (MET)

>     public key of the TLS server before it starts a (non-resumed) TLS

(1)

I'm confused about this paragraph with respect to later parts of the
document.  Maybe I've read the document too quickly, but I didn't
find an explanation how exactly this new certificate type could be
used to "reduce the latency of a TLS client that is already in
posession of a validated public key".

Since the new certificate type "RawPublicKey" is in reality a
PKIX SubjectPublicKeyInfo, every server in posession of an X.509 cert
could simply agree to this extension when proposed by the client,
extract the SubjectPublicKeyInfo from this X.509 server certificate
and send it as RawPublicKey in the ServerCertificate handshake message.
This would reduce the amount of data in the Server's Certificate and
optional CertificateRequest Handshake message. (and when the server
requested it, it would reduce the size of the Client's Certificate
handshake message as well, provided the client had a credential).

Is is that reduction in size of the handshake message that was meant?

(2)

Personally, I believe it would be quite reasonable, for servers
implementing this in addition to regular X.509 support, to also
use X.509 certs as containers for the raw public keys so that no
changes whatsoever are required for the adminstrative parts
(creation and management of server TLS credentials).

Is the intention to actively suggest to (server) implementations of
this document to generally extract and use of the SubjectPublicKeyInfo
as RawPublicKey for whatever X.509 certificate the server might have,
then this requirement, that was copied from rfc6091, would become
superfluous:

                                                            This
   extension MUST be omitted if the client only supports X.509
   certificates.

btw. I believe that MUST (from rfc6091) is in conflict with rfc2119 section 6.

Likewise, is the intention to actively suggest to (client) implementations
of this document to extract SubjectPublicKeyInfo from X.509 Server
Certificates that they received on a full handshake with that server
and where available to validate (PKIX/DANE/whathaveyou) and attempt to
use it in a sucessor TLS handshake with that server as a RawPublicKey
with the TLS extension defined in this document?

(3)

I'm wondering about any kind of "server has more than one credential
scenario", which comes in two different flavours (and mixtures thereof):

   (a) virtual hosting, several distinct server certificates and
       their selection guided by TLS extension SNI

   (b) ciphersuites that require distinct keypairs (RSA,DSA,ECDSA)

I believe with respect to (a) the interaction of the extension defined in
this document with TLS extension SNI should be specified.  This would
be essential if the intention of (2) applies that clients&servers are
expected to extract SubjectPublicKey Infos from X.509 certificates that
they would use as X.509 certs in regular TLS handshakes without this
extension.

With respect to (b), I believe that it should be spelled out that
clients(!) may have to restrict the list of TLS cipher suites
that they propose in ClientHello, when using the TLS extension
defined in this document, to those algorithms for which they
actually have server RawPublicKeys available.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 23 Jan 2012 22:29:40 -0800

I am going to have to disagree with the statement that the document is ready
for WGLC.  I have refrained from reading this document before because I am
not truly convinced that this is a good idea.

1.   I have a hard time with the second paragraph in the abstract - firstly
the concept of a black list seems to be problematic as a method of deciding
that an oob key is or is not good.  A white list could essentially be a list
of names and keys and thus work.  However there are going to be issues of
trust in terms of how the white list is updated that are exactly the same
for getting PKIX to work.

2.  In section 1.1 you state "...a TLS server must always send a list of
trusted CA keys and..." this does not make sense to me.  There is no list of
trusted CA keys, there is an EE certificate and then the list of CA
certificates that certify the EE certificate (and each other).  There is no
statement that these are trusted CA keys.  5246 explicitly says that the
trust anchor (i.e. the TRUSTED CA key) does not need to be sent in the chain
of certificates.

Even more troubling is that I cannot find anything that defines an extension
which says - I know who you are don't send me any certificates (or perhaps
only the EE certificate).  However I do note that you state that RFC 6066
does have the flag to say don't send me the chain - this appears to greatly
lessen the argument that you have a large problem in terms of not sending
the EE certificate.

Why do you not just have an extension to say - don't send me the EE
certificate I already think I know who you are.  That would solve you issue
without any need for the new certificate extension type.

I don't believe that this provides a good motivation for the document.  The
small embedded device is a better motivation that is presented here.

3. For section 1.2 - see previous item.  Again I think the small embedded
device is a much better statement of applicability.  You should be looking
at cases for raw public keys not for PKIX.

4.  I have absolutely no idea how to create a certificate which contains
only the subject public key info structure.  Many of these fields are not
optional and therefore cannot be omitted.  Also you have said that the
entire problem is that you cannot deal with the PKIX structure, and how you
are suddenly doubling the amount of code that I need to deal with PKIX since
I now have both a certificate with fields and a certificate w/o fields.  Why
do you not say that your data structure for a "raw key certificate" is just
going to be the SubjectPublicKeyInfo DER encoded structure?  This would be
much simpler and clearer as well as reducing the amount of ASN.1 processing
substantially.

5.  You are missing text that needs to be in place about the use of client
authentication from a raw key.  I don't know if this is what you really want
to do or not.  It is going to be much harder for a server to do the oob
authentication without registration of some type.  Additionally this would
mean that your justification of wanting to suppress the sending of the
server certificate would need to be documented as not working at all if you
want to do client authentication.  Since one case where you might want to do
the suppression would be a re-authentication process for protected client
auth, this does not make any since (in this case you already have the
servers certificates from the previous handshake).  Does this mean that you
want to have the ability to have an asymmetric method of specifying the
"certificate type"  so that one can do bare key from server to client, but
pkix certificate from client to server?  This is not an issue for the case
of PGP since one can assume that both the server and the client are going to
use PGP certificates for the purpose of authentication.  

6.  Security considerations - para #2 - It is easy to establish the
authenticity of the public key - just see if the cryptography works.  What
you want to be able to authenticate is the binding between the public key
and the entity or service you are attempting to contact.

7.  Security considerations - does not talk about client/public key binding
authentication by the server at all - this is a short coming

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Wouters
> Sent: Friday, January 20, 2012 3:55 PM
> To: [email-masked]
> Subject: [TLS] New Version Notification for
draft-ietf-tls-oob-pubkey-01.txt
> (fwd)
> 
> 
> The only changes to the document is a typo (out of bound -> out of band)
> found by Bill Frantz and an updated reference to a newer draft-ietf-dane-
> protocol version.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls