[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] New Version Notification for
From:       Martin Rex <mrex () sap ! com>
Date:       2011-11-18 21:42:01
Message-ID: 201111182142.pAILg1Hd027980 () fs4113 ! wdf ! sap ! corp
[Download RAW message or body]

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

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

[prev in list] [next in list] [prev in thread] [next in thread]