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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Feb 2012 10:45:49 +0200

Hi Martin, 

I don't think I have responded to your review already. 

On Jan 21, 2012, at 3:23 AM, Martin Rex wrote:

> Paul Wouters wrote:
>> 
>> 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
>> 
>> 
>>    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.
> 
> 
> (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".
> 

Think about a radio technology like IEEE 802.15.4
http://en.wikipedia.org/wiki/IEEE_802.15.4
It is a low bandwidth radio with a small MTU. 

The small MTU leads to fragmentation and potentially to retransmissions. The low bandwidth increases latency for longer data transfers. 

Maybe this needs to be more clear in the draft. 

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

Yes. The SubjectPublicKeyInfo part of the certificate is much smaller than the entire certificate. 
Additionally, there is also the lower implementation overhead for a TLS stack that only supports raw public keys (which is useful for smart objects). 

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

The document does not mandate a specific way to store the raw public keys. 
You could, for example, create self-signed certificate using one of the many available tools but then only transmit the SubjectPublicKeyInfo part of the cert. 

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

If a server only has X.509 certificate support then it makes not sense to advertise the support for raw public keys. 

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

> 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?
> 
> 
No, that's not the intention. 

The server only sends the SubjectPublicKeyInfo and not the certificate.

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

What would you like to specify? 

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

It is a pure policy issues how many ciphersuites to advertise. 
I am not sure I would add a lot of advice by saying that. 

Ciao
Hannes

> 
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls