[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TLS endpoint channel bindings in SCRAM
- To: Nicolas Williams <Nicolas.Williams@xxxxxxx>
- Subject: Re: TLS endpoint channel bindings in SCRAM
- From: Dave Cridland <dave@xxxxxxxxxxxx>
- Date: Thu, 02 Apr 2009 12:32:21 +0100
- Cc: <ietf-sasl@xxxxxxx>, <channel-binding@xxxxxxxx>, Mark Novak <Mark.Novak@xxxxxxxxxxxxx>, Larry Zhu <lzhu@xxxxxxxxxxxxxxxxxxxxx>, Sam Hartman <hartmans-ietf@xxxxxxx>, Leif Johansson <leifj@xxxxxxxx>, Paul Leach <paulle@xxxxxxxxxxxxxxxxxxxxx>, Jeffrey Altman <jaltman@xxxxxxxxxxxxxxxxxxxx>, Kevin Damour <kdamour@xxxxxxxxxxxxx>, Stefan Santesson <stefans@xxxxxxxxxxxxx>
- In-reply-to: <20090401225220.GA1500@xxxxxxx>
- List-archive: <http://www.imc.org/ietf-sasl/mail-archive/>
- List-id: <ietf-sasl.imc.org>
- List-unsubscribe: <mailto:firstname.lastname@example.org?body=unsubscribe>
- References: <5690.1237934257.266964@xxxxxxxxxxxxxxxxxxxxxxxx> <20090401225220.GA1500@xxxxxxx>
- Sender: owner-ietf-sasl@xxxxxxxxxxxx
On Wed Apr 1 23:52:20 2009, Nicolas Williams wrote:
1) Do many/most/all TLS implementations output the DER-encoded form
Somewhere between many and most. I suspect all the low-level TLS
stacks (OpenSSL etc) will do. It's the bindings and suchlike I'm more
the server cert? Which ones do/don't?
In the bindings, however, it's pretty trivial to find a function
which either hands back the DER form, or else hands back PEM (base64
of DER), which developers can also use.
2) Is the cert used on the wire generally NOT DER-encoded? If so,
I have absolutely no idea. If I could rely on the cert being DER on
the wire, we could reduce this to implementation notes, aside from
the hash issue. I have no idea how to extract that hash algorithm,
currently, but I could probably figure that out eventually.
hard would it be to change this? (e.g., re-encode the cert and
If it turns out that tls-server-endpoint *can* be readily implemented
at least for the common case of X.509 certificates, then I'd be very
much happier with this outcome.
- By hard-coding a hash function we'd lose hash agility. Hash
is one of the features of the registered tls-server-end-point
Yes - it's not ideal, but I'm hoping that by the time hash agility
becomes an issue, then we'll have support for the more generic form
of the channel binding.
binding type. OTOH, as you note, for SCRAM this is solved by the
existing SCRAM hash agility approach (add a new mech).
- We can't really negotiate which type of channel binding to use.
relatively easy to choose between unique and server-end-point,
choose between two types of server-end-point bindings is much
(unless it's a choice made at specification time, in this case
But clients must stipulate which they have used.
Neither modifying tls-server-end-point nor introducing a
variant of it seem particularly appealing. The former may well
out of the barn's doors, which would leave us only with the
choice (or fix the TLS frameworks :)
I think tls-server-end-point is a fine binding.
My problem is that it'll be years before it's available on many
platforms, and I think we can provide more immediately implementable
security than that.
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade