Subject: GS2 status, and poll on wire encoding

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2008 15:18:12 +0200

All,

The discussion on GS2 encoding appears to have slowed down.  As far as I
can tell, there is a preference for GS2 to use a textual wire encoding.
Possibly people who haven't spoken up disagree with that preference.  I
am ready to revise the document, but I'd like to understand if someone
would strongly disagree, to avoid wasting time modifying the document.

As far as I know, determining the wire encoding, and waiting for a
GSS-mechanism description of SCRAM, are the only issues that is holding
GS2 back.  If there are other concerns with the current document, please
let me know!

Can we do a quick poll to see determine a way forward?  Post a +1
indicating which of these you prefer:

1) Please make GS2 use a textual wire encoding

2) Please keep the binary wire encoding in GS2

3) I don't care, just get it finished ASAP
   (which would likely mean binary encoding since that is what the
   document currently uses, and rewriting it and reviewing the new
   document will take time)

4) Something else, namely: ....

Of course, the poll is informal, and is just for my information as
document editor.  Feel free to reword my text if it helps you to give a
better answer.

It would be useful if someone else would help to gauge consensus.  If
this thread doesn't lead to a clear answer, hopefully it will serve as
input to asking better questions.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Sep 2008 09:53:30 -0500

> indicating which of these you prefer:

I think the poll is backwards.  We should vote on a layout for SCRAM and
then let GS2 follow it so we can have wire-compatible SCRAM and
SCRAM-as-GS2/GSS-mech.

Sam summarized the SCRAM options that are amenable to Chris and pretty
much anyone else who commented.  Let's start with that.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Sep 2008 13:33:35 -0400

> much anyone else who commented.  Let's start with that.

+1

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 7 Sep 2008 05:51:02 +0200

> 4) Something else, namely: ....

...no preference, but IFF you go for "textual"
please consider case-insensitive hex., no B64.  

 Frank

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Sep 2008 13:34:47 +0200

> please consider case-insensitive hex., no B64.  

Base64 implementations often have a lot of problem that makes them
unsuitable for use in security protocols, so you have a point.  However,
I believe the majority of SASL profiles out there already makes use of
base64, so implementations better have a good implementation of it handy
anyway.  I believe at least GNU SASL and Cyrus SASL does.

The only reason I can see to prefer base64 would be if it is worth the
extra complexity in order to reduce bandwidth.

I don't feel strongly about hex vs base64.  Other thoughts?

/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 8 Sep 2008 22:32:04 +0200

Simon Josefsson wrote:

> I believe at least GNU SASL and Cyrus SASL does.

My MD5 test suite doesn't, it's horribly intolerant
for input without "=" pad characters.  Of course
that mainly means that I should fix it, add a flag
for "4648" vs. "DWIM", or similar.

Over the years all problems I found with this test
suites fall in two categories:

- B64 GiGo effects
- Erratum submitted

 Frank

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 9 Sep 2008 00:39:32 +0200

Frank Ellermann writes:
> My MD5 test suite doesn't, it's horribly intolerant for input without 
> "=" pad characters. Of course that mainly means that I should fix it, 
> add a flag for "4648" vs. "DWIM", or similar.

If a lot of people get the pad character generation/handling wrong, 
maybe that means requiring the padding was a poor choice on part of 
whoever conceived the base64 spec.

(Blah blah descriptive vs. prescriptive grammar blah.)

Arnt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Sep 2008 10:29:09 +0200

"Frank Ellermann" <[email-masked]> writes:

> for input without "=" pad characters.

A good implementation should be intolerant about base64 errors!
Otherwise there are side channels risks or worse problems.

> Of course that mainly means that I should fix it, add a flag for
> "4648" vs. "DWIM", or similar.

I think it would be better if everyone tried to implement the 4648
format and reject non-conforming data, rather than an underspecified
DWIM mode.  I believe GNU SASL strictly follows 4648, and I haven't seen
any problems in that area so far.

/Simon