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

["Jim Schaad" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Paul
> Wouters
> Sent: Friday, January 20, 2012 3:55 PM
> To: [e-mail]
> 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.
> 
> 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: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
> [e-mail],
>      [e-mail]
> To: [e-mail]
> 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
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls