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

[Hannes Tschofenig <[e-mail]>]

Hi Jim, 

I have missed your review. Sorry about that. 
As I am updating the draft I now found it. 

On Jan 24, 2012, at 8:29 AM, Jim Schaad wrote:

> 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.
> 

The blacklist idea wasn't really worked out. I removed it. 

> 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.
> 

This is a left-over from an earlier draft version where we also tried to incorporate ideas that are now found in 
http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/

I would prefer to remove these paragraphs from the document. 

> 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.
> 

I have polished the text a bit. 

> 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.

We are pretty much free to put whatever we want into a message and so placing only a SubjectPublicKeyInfo works fine. Of course your question about whether putting the SubjectPublicKeyInfo or just the raw key parameters in there is good. We initially had proposed the latter but got the feedback from the group that we should go for the SubjectPublicKeyInfo structure instead because it allows easier re-use.

I tried to implement the extension, only based on RSA keys, as a contribution for the upcoming Smart Object Security workshop. Here is the workshop: http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ and here is the paper: 
https://github.com/hannestschofenig/tschofenig-ids/raw/master/smart-object-security/smart-object-security.pdf

In a nutshell: The amount of ASN.1 functionality for parsing the SubjectPublicKeyInfo structure is very small. 

> 
> 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

To address your last three comments I have re-written the security consideration section. 

I agree with you that the cryptography is easy. Binding the public key to some entity is what we call "out-of-band key validation". 
We offer a few options, namely pre-configuring a list of keys a client would accept from servers, or the the usage of DANE. In the CORE WG folks want to print the hash of the key onto the sensor and then let a human compare the value with what is shown on the screen of some other device. These sort of imprinting procedures are in use today by some consumer devices. 

Maybe we should elaborate a bit more on the DANE or the smart object use case. 

Ciao
Hannes

> 
> 
>> -----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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls