Re: [sasl] "Last call" on draft-altman-tls-channel-bindings-05.txt

[Nicolas Williams <[e-mail]>]

I've just posted version -06, incorporating all changes agreed so far.

This pseudo-WGLC started on August 18th.  Tomorrow I'll ask Pasi to take
the next step in the publication process.

Thanks,

Nico
-- 

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMjClP006391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 15:45:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JMjCWS006390; Wed, 19 Aug 2009 15:45:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMjAUj006383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 15:45:11 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JMjAt9009231 for <[e-mail]>; Wed, 19 Aug 2009 22:45:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7JMjAj7064386 for <[e-mail]>; Wed, 19 Aug 2009 16:45:10 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JMQw4c004584; Wed, 19 Aug 2009 17:26:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMQwpe004583; Wed, 19 Aug 2009 17:26:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 19 Aug 2009 17:26:58 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Aug 20, 2009 at 12:25:38AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > But I don't want to guess at what might happen in the future
> > of digital signatures.
> 
> I agree, we could decide to not resolve this concern.
> 
> > Instead I'd rather either say either that tls-server-end-point CB is
> > undefined if the cert's signature alg does not use a signature, or
> > pick a hash function (e.g., SHA-512) to use in such cases.
> 
> If use of SHA-512 is hard-coded, we run into problem when it is phased
> out.  Negotiation any other hash function will be tricky.  Alas, I'm not
> sure leaving it undefined is any better: negotiating what hash function
> to use in that situation seems equally tricky.

I chatted with Jeff Hutzelman about this, and we both concluded that
leaving tls-server-end-point undefined in this case is acceptable
because we could change the spec to define tls-server-end-point for such
signature algorithms when they arise.

> This is one reason where deriving channel binding data from the TLS
> channel using tls-extractor appears more robust: it leaves negotiation
> of the hash function to the TLS protocol.

tls-unique does that already (though not using the extractor).  We're
talking about end-point channel binding types here, which are
independent of actual channels, therefore we couldn't use the extractor.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMeiF6006009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 15:40:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JMeiiP006008; Wed, 19 Aug 2009 15:40:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMegGx006002 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 15:40:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JMeg7s008446 for <[e-mail]>; Wed, 19 Aug 2009 22:40:42 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7JMef5o062222 for <[e-mail]>; Wed, 19 Aug 2009 16:40:41 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JMMU9U004576; Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMMUYM004575; Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 19 Aug 2009 17:22:29 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 19, 2009 at 04:22:24PM -0500, Nicolas Williams wrote:
> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> > For completeness, I would add:
> > 
> >    This algorithm agility resolution mechanism assumes that there is a
> >    mapping from every Public-key signature algorithm to one hash
> >    function algorithm.  This is the case for all practically used public
> >    key signature algorithms today, but if future public-key signature
> >    algorithms would employ multiple hash functions (or none at all) this
> >    specification needs to be updated to resolve which hash function
> >    should be used.
> 
> This brings up a question: what to do in the case of randomized digital
> signatures?  In the case of NIST-SP-800-106 there's still a hash
> function, so that's OK.  But one can imagine a digital signature
> algorithm where a MAC and random key are used instead of a hash.
> 
> ...
> 
> But I don't want to guess at what might happen in the future
> of digital signatures.  Instead I'd rather either say either
> that tls-server-end-point CB is undefined if the cert's
> signature alg does not use a signature, or pick a hash
> function (e.g., SHA-512) to use in such cases.

After asking others I propose the former solution:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)

   The hash function is to be selected as follows:

    - if the certificate's signatureAlgorithm uses a single hash
      function, and that hash function is either MD5 [RFC1321] or SHA-1
      [RFC3174] then use SHA-256 [FIPS-180-2];

    - if the certificate's signatureAlgorithm uses a single hash
      function and that hash function neither MD5 nor SHA-1, then use
      the hash function associated with the certificate's
      signatureAlgorithm;

    - if the certificate's signatureAlgorithm uses no hash functions, or
      multiple hash functions, then this channel binding type's channel
      bindings are undefined at this time (updates to is channel binding
      type may occur to address this issue if it ever arises).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMPsG5005260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 15:25:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JMPsQL005259; Wed, 19 Aug 2009 15:25:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JMPjMO005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 19 Aug 2009 15:25:53 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7JMPcBJ031296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Aug 2009 00:25:40 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090819:[e-mail]::KeyHv/WeE0AMzTIv:03lZ
X-Hashcash: 1:22:090819:[e-mail]::0rTKIlPk8SZjIqkT:ZnPW
X-Hashcash: 1:22:090819:[e-mail]::wy96xQShYma/iDOS:g3wg
Date: Thu, 20 Aug 2009 00:25:38 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Wed, 19 Aug 2009 16:22:24 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> But I don't want to guess at what might happen in the future
> of digital signatures.

I agree, we could decide to not resolve this concern.

> Instead I'd rather either say either that tls-server-end-point CB is
> undefined if the cert's signature alg does not use a signature, or
> pick a hash function (e.g., SHA-512) to use in such cases.

If use of SHA-512 is hard-coded, we run into problem when it is phased
out.  Negotiation any other hash function will be tricky.  Alas, I'm not
sure leaving it undefined is any better: negotiating what hash function
to use in that situation seems equally tricky.

This is one reason where deriving channel binding data from the TLS
channel using tls-extractor appears more robust: it leaves negotiation
of the hash function to the TLS protocol.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JLeiHZ002650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 14:40:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JLei21002648; Wed, 19 Aug 2009 14:40:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JLecNK002636 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 14:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JLebsm028052 for <[e-mail]>; Wed, 19 Aug 2009 21:40:37 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7JLebmJ027639 for <[e-mail]>; Wed, 19 Aug 2009 15:40:37 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JLMOoK004480; Wed, 19 Aug 2009 16:22:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JLMOUh004479; Wed, 19 Aug 2009 16:22:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 19 Aug 2009 16:22:24 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

This brings up a question: what to do in the case of randomized digital
signatures?  In the case of NIST-SP-800-106 there's still a hash
function, so that's OK.  But one can imagine a digital signature
algorithm where a MAC and random key are used instead of a hash.

Traditionally a digital signature

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {rv = rng(rv_len),
		     S(Kp, H(rv ||
			     (pad(M, rv_len) XOR xor_pad_gen(rv) ||
			     rv_length_indicator(rv_len))))
		    }

One could imagine this, however:

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

in which case there'd be no hash function.  Of course, we could define a
pseudo-hash function in that case: H(x) = MAC(mk, x), where mk is the mk
that would appear in the signature.

But I don't want to guess at what might happen in the future
of digital signatures.  Instead I'd rather either say either
that tls-server-end-point CB is undefined if the cert's
signature alg does not use a signature, or pick a hash
function (e.g., SHA-512) to use in such cases.

Comments?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JHOx5g003728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2009 10:24:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7JHOxbX003727; Wed, 19 Aug 2009 10:24:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7JHOY0i003699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 19 Aug 2009 10:24:43 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JGZqFO013219 for <[e-mail]>; Wed, 19 Aug 2009 16:35:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7JGZpEQ043975 for <[e-mail]>; Wed, 19 Aug 2009 10:35:51 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JGHXVB004013; Wed, 19 Aug 2009 11:17:33 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JGHSpp004012; Wed, 19 Aug 2009 11:17:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 19 Aug 2009 11:17:28 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 19, 2009 at 02:14:38AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> >    Description: ...
> 
> Looks fine to me.
> 
> > The text you quote is security considerations text; the normative text
> > already says exactly what you ask for.  But OK:
> >
> >         ...  The algorithm to be used, however, is derived from the
> >    certificate's signature as described in Section 4.1; to recap: use
> >    SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
> >    else use whatever hash function the certificate uses.
> 
> There were two uses of "uses" in the sentence, and the second is still
> present, but at least this is better than before.

Ah yes:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate signature algorithm
   uses.

> > Now, section 4.1 says "if the certificate's signature hash algorithm is
> > ...".  But perhaps it should say "if the hash algorithm used in the
> > certificate's signatureAlgorithm is ...", just to be really accurate and
> > avoid any possible confusion (with, say, the algorithm field of
> > SubjectPublicKeyInfo).  Yes?
> 
> The more precise the better, although SubjectPublicKeyInfo generally do
> not imply any particular hash function.  But for new implementers, it is
> easy to go wrong if the text is not specific.

So let's add that precision and address signature algs that don't use
hash functions:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function is
   to be selected as follows: if the hash algorithm used in the
   certificate's signatureAlgorithm is either MD5 [RFC1321] or SHA-1
   [RFC3174] or if the certificate's signatureAlgorithm does not use any
   hash functions, then use SHA-256 [FIPS-180-2], otherwise use whatever
   hash algorithm is used by the certificate's signatureAlgorithm.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J0EvCG028849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 17:14:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7J0Ev78028848; Tue, 18 Aug 2009 17:14:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7J0Es6h028842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Aug 2009 17:14:55 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7J0Ect1002404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 02:14:47 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090819:[e-mail]::XcO9khQ7yKWKB+bJ:1zR4
X-Hashcash: 1:22:090819:[e-mail]::xQBD+AnB68GkFtvc:5LOR
X-Hashcash: 1:22:090819:[e-mail]::9tI8e5seg85tFhXg:Bi0/
Date: Wed, 19 Aug 2009 02:14:38 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Aug 2009 17:59:34 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
>> Quoting:
>> 
>>    Description: The hash of the TLS server's end entity certificate
>>    [RFC5280] as it appears, octet for octet, in the server's Certificate
>>    message (note that the Certificate message contains a
>>    certificate_list, the first element of which is the server's end
>>    entity certificate.)
>> 
>> I suggest replacing "server's end entity certificate" with "server's
>> certificate".  As far as I understand, it is possibly to use non-EE
>> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
>> terminology is to say "sender's certificate" and there is no requirement
>> to use a EE cert.
>
> OK.  The thing to emphasize is that we're talking about the first cert
> in the certificate_list that would be sent by the server.
>
> (I say "would be" just to be mindful of the TLS client caching
> extensions, but I don't think the I-D has to say "would" since the
> certificate_list will always have been sent at one point or another.)
>
> So how about:
>
>    Description: The hash of the TLS server's certificate [RFC5280] as it
>    appears, octet for octet, in the server's Certificate message (note
>    that the Certificate message contains a certificate_list, the first
>    element of which is the server's certificate.)  The hash function ...

Looks fine to me.

>> Quoting:
>> 
>>    agility.  The algorithm to be used, however, is derived from the
>>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>>    else use whatever hash function the certificate uses.  This
>> 
>> Please say "is signed with" instead of "uses".  Hash values may be
>> present for other purposes in a certificate, but signature fields will
>> typically only use one hash function.
>
> The text you quote is security considerations text; the normative text
> already says exactly what you ask for.  But OK:
>
>         ...  The algorithm to be used, however, is derived from the
>    certificate's signature as described in Section 4.1; to recap: use
>    SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
>    else use whatever hash function the certificate uses.

There were two uses of "uses" in the sentence, and the second is still
present, but at least this is better than before.

> Now, section 4.1 says "if the certificate's signature hash algorithm is
> ...".  But perhaps it should say "if the hash algorithm used in the
> certificate's signatureAlgorithm is ...", just to be really accurate and
> avoid any possible confusion (with, say, the algorithm field of
> SubjectPublicKeyInfo).  Yes?

The more precise the better, although SubjectPublicKeyInfo generally do
not imply any particular hash function.  But for new implementers, it is
easy to go wrong if the text is not specific.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7INI5TT025824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 16:18:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7INI5RS025823; Tue, 18 Aug 2009 16:18:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7INHqD9025813 for <[e-mail]>; Tue, 18 Aug 2009 16:18:01 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7INHp1x009249 for <[e-mail]>; Tue, 18 Aug 2009 23:17:51 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7INHpxw039394 for <[e-mail]>; Tue, 18 Aug 2009 17:17:51 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IMxbUN003790; Tue, 18 Aug 2009 17:59:37 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IMxYwu003789; Tue, 18 Aug 2009 17:59:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Aug 2009 17:59:34 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> Quoting:
> 
>    Description: The hash of the TLS server's end entity certificate
>    [RFC5280] as it appears, octet for octet, in the server's Certificate
>    message (note that the Certificate message contains a
>    certificate_list, the first element of which is the server's end
>    entity certificate.)
> 
> I suggest replacing "server's end entity certificate" with "server's
> certificate".  As far as I understand, it is possibly to use non-EE
> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
> terminology is to say "sender's certificate" and there is no requirement
> to use a EE cert.

OK.  The thing to emphasize is that we're talking about the first cert
in the certificate_list that would be sent by the server.

(I say "would be" just to be mindful of the TLS client caching
extensions, but I don't think the I-D has to say "would" since the
certificate_list will always have been sent at one point or another.)

So how about:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function ...

> Quoting:
> 
>    agility.  The algorithm to be used, however, is derived from the
>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>    else use whatever hash function the certificate uses.  This
> 
> Please say "is signed with" instead of "uses".  Hash values may be
> present for other purposes in a certificate, but signature fields will
> typically only use one hash function.

The text you quote is security considerations text; the normative text
already says exactly what you ask for.  But OK:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.

Now, section 4.1 says "if the certificate's signature hash algorithm is
...".  But perhaps it should say "if the hash algorithm used in the
certificate's signatureAlgorithm is ...", just to be really accurate and
avoid any possible confusion (with, say, the algorithm field of
SubjectPublicKeyInfo).  Yes?

> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

Good point.

Thanks!

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7IMjsmQ023777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 15:45:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7IMjsgl023776; Tue, 18 Aug 2009 15:45:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7IMjju3023744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 18 Aug 2009 15:45:53 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7IMjHA8001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 00:45:19 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: "Last call" on draft-altman-tls-channel-bindings-05.txt
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090818:[e-mail]::phGjYQ2dCe/ST4ZG:27Ek
X-Hashcash: 1:22:090818:[e-mail]::Sp9lVljf2yG9TozZ:1dgY
X-Hashcash: 1:22:090818:[e-mail]::HHy/gYRdIGhZPWU0:AZ1D
Date: Wed, 19 Aug 2009 00:45:17 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 18 Aug 2009 16:34:28 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Quoting:

   Description: The hash of the TLS server's end entity certificate
   [RFC5280] as it appears, octet for octet, in the server's Certificate
   message (note that the Certificate message contains a
   certificate_list, the first element of which is the server's end
   entity certificate.)

I suggest replacing "server's end entity certificate" with "server's
certificate".  As far as I understand, it is possibly to use non-EE
certs, e.g. proxy certs, as a server certificate.  The RFC 5246
terminology is to say "sender's certificate" and there is no requirement
to use a EE cert.

Quoting:

   agility.  The algorithm to be used, however, is derived from the
   certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.  This

Please say "is signed with" instead of "uses".  Hash values may be
present for other purposes in a certificate, but signature fields will
typically only use one hash function.

For completeness, I would add:

   This algorithm agility resolution mechanism assumes that there is a
   mapping from every Public-key signature algorithm to one hash
   function algorithm.  This is the case for all practically used public
   key signature algorithms today, but if future public-key signature
   algorithms would employ multiple hash functions (or none at all) this
   specification needs to be updated to resolve which hash function
   should be used.

Nits:

   note (that is, the first such note in the descritption is a new
                                                   ^
/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7ILqpMd020436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Aug 2009 14:52:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7ILqpe3020435; Tue, 18 Aug 2009 14:52:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7ILqik2020422 for <[e-mail]>; Tue, 18 Aug 2009 14:52:51 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7ILqhR2020925 for <[e-mail]>; Tue, 18 Aug 2009 21:52:44 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7ILqhjn055505 for <[e-mail]>; Tue, 18 Aug 2009 15:52:43 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7ILYUbQ003684; Tue, 18 Aug 2009 16:34:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7ILYSfi003683; Tue, 18 Aug 2009 16:34:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 18 Aug 2009 16:34:28 -0500
From: Nicolas Williams <[e-mail]>
To: [e-mail], [e-mail]
Subject: "Last call" on draft-altman-tls-channel-bindings-05.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Per RFC5056, three channel binding types for TLS have been registered in
the IANA channel binding type registry.  Recently we've decided that we
actually need a Standards-Track RFC to define these channel binding
types so as to make it easier to make normative reference to them.

Therefore we've revived and updated draft-altman-tls-channel-bindings to
include the text of those three channel binding type registrations, as
well as to update introductory and security considerations text.

We seek comments on draft-altman-tls-channel-bindings-05.  In two weeks
we'll request that an AD shepherd this individual submission.  We seek
Proposed Standard status for the resulting RFC.

Consider this a pseudo-WGLC.  Please review and comment.

Thanks,

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HEHShF001938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 07:17:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HEHS98001937; Mon, 17 Aug 2009 07:17:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HEHEpU001912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Aug 2009 07:17:25 -0700 (MST) (envelope-from [e-mail])
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7HBOAPR032448; Mon, 17 Aug 2009 14:24:18 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:24:14 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Aug 2009 14:24:13 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 17 Aug 2009 13:24:12 +0200
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
CC: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Date: Mon, 17 Aug 2009 13:24:11 +0200
Subject: RE: [Editorial Errata Reported] RFC4013 (1812)
Thread-Topic: [Editorial Errata Reported] RFC4013 (1812)
Thread-Index: AcoLNYPxIHHYWOv2TjCf7rf5U7F7aAT9zWyA
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 17 Aug 2009 11:24:13.0406 (UTC) FILETIME=[3F92DFE0:01CA1F2D]
X-Nokia-AV: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hmm.. it looks like there are Unicode characters that are in the
"prohibited output" list, but will get changed to another, allowed
characters during the "Map" or "Normalize" steps.=20

Since "Prohibit" step is done after Map and Normalize, these
characters can actually appear in the input, right? (and this would=20
not be an error)

(For example, it looks like U+0340 is prohibited by Table C.8, but
will get normalized to U+0300, which is allowed.)

So actually should the errata be something like this?

  OLD:
     This profile specifies the following characters as prohibited input:  =
  =20
  NEW:
     This profile specifies the following characters as prohibited output:

 Discussion: Per RFC 3454, the check for prohibited characters
 is done after the "Map" and "Normalize" steps. Characters listed
 here are actually allowed as inputs if they get removed by the=20
 "Map" or "Normalize" steps.

Best regards,
Pasi

> -----Original Message-----
> From: ext Kurt Zeilenga [mailto:[e-mail]]
> Sent: 23 July, 2009 04:32
> To: Jeffrey Hutzelman
> Cc: Simon Josefsson; RFC Errata System; [e-mail]; Eronen Pasi
> (Nokia-NRC/Helsinki); [e-mail]; [e-mail]; ietf-
> [e-mail]
> Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
>=20
>=20
> On Jul 22, 2009, at 1:44 PM, Jeffrey Hutzelman wrote:
>=20
> > There is, however, an error -- the first sentence of this section
> > does in fact claim to be specifying prohibited input characters.
> > The correct fix is to that text, not to the section title.
>=20
>=20
> I support the following errata:
>=20
> OLD:
> 	prohibited input:
>=20
> NEW
> 	prohibited:
>=20
>=20
> Discussion:
> Per RFC 3454, if a prohibited character appears in the input, an error
> must result.  That is, the prohibited characters cannot appear in the
> output.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HEGKV6001773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2009 07:16:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7HEGKIC001772; Mon, 17 Aug 2009 07:16:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7HEG4V7001733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 17 Aug 2009 07:16:15 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7HCojw1021951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Aug 2009 14:50:48 +0200
From: Simon Josefsson <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090817:[e-mail]::QUR2ujEjhRMxq4hw:Dd0
X-Hashcash: 1:22:090817:[e-mail]::0KDVMz+1hNIY3rJD:3T4O
X-Hashcash: 1:22:090817:[e-mail]::AxNNR3r3N9B02bIG:Buq/
X-Hashcash: 1:22:090817:[e-mail]::xDvmvveunHAOh6C8:6h03
X-Hashcash: 1:22:090817:[e-mail]::vP2Wfi462nR6YEEP:EjJ3
X-Hashcash: 1:22:090817:[e-mail]::iJmMGbeqjiU8PHeW:FkTr
X-Hashcash: 1:22:090817:[e-mail]::L+R/9p3V89mLIwdu:NBaa
X-Hashcash: 1:22:090817:[e-mail]::OIYkot2tJDZfzrVz:OWJn
Date: Mon, 17 Aug 2009 14:50:45 +0200
In-Reply-To: <[e-mail]> (Pasi Eronen's message of "Mon, 17 Aug 2009 13:24:11 +0200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think your fix is better.  RFC 3454 talks about prohibiting code
points in the output.  It doesn't say anything about prohibiting code
points in inputs, since the algorithm doesn't work like that.  I don't
think the intention of RFC 4013 was to change the ordering of RFC 3454
algorithm steps, so treating it as a typo in RFC 4013 appears
appropriate to me.

/Simon

<[e-mail]> writes:

> Hmm.. it looks like there are Unicode characters that are in the
> "prohibited output" list, but will get changed to another, allowed
> characters during the "Map" or "Normalize" steps. 
>
> Since "Prohibit" step is done after Map and Normalize, these
> characters can actually appear in the input, right? (and this would 
> not be an error)
>
> (For example, it looks like U+0340 is prohibited by Table C.8, but
> will get normalized to U+0300, which is allowed.)
>
> So actually should the errata be something like this?
>
>   OLD:
>      This profile specifies the following characters as prohibited input:     
>   NEW:
>      This profile specifies the following characters as prohibited output:
>
>  Discussion: Per RFC 3454, the check for prohibited characters
>  is done after the "Map" and "Normalize" steps. Characters listed
>  here are actually allowed as inputs if they get removed by the 
>  "Map" or "Normalize" steps.
>
> Best regards,
> Pasi
>
>> -----Original Message-----
>> From: ext Kurt Zeilenga [mailto:[e-mail]]
>> Sent: 23 July, 2009 04:32
>> To: Jeffrey Hutzelman
>> Cc: Simon Josefsson; RFC Errata System; [e-mail]; Eronen Pasi
>> (Nokia-NRC/Helsinki); [e-mail]; [e-mail]; ietf-
>> [e-mail]
>> Subject: Re: [Editorial Errata Reported] RFC4013 (1812)
>> 
>> 
>> On Jul 22, 2009, at 1:44 PM, Jeffrey Hutzelman wrote:
>> 
>> > There is, however, an error -- the first sentence of this section
>> > does in fact claim to be specifying prohibited input characters.
>> > The correct fix is to that text, not to the section title.
>> 
>> 
>> I support the following errata:
>> 
>> OLD:
>> 	prohibited input:
>> 
>> NEW
>> 	prohibited:
>> 
>> 
>> Discussion:
>> Per RFC 3454, if a prohibited character appears in the input, an error
>> must result.  That is, the prohibited characters cannot appear in the
>> output.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CE8TbB007799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 07:08:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7CE8TD2007798; Wed, 12 Aug 2009 07:08:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7CE8Ju3007775 for <[e-mail]>; Wed, 12 Aug 2009 07:08:28 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 12 Aug 2009 15:08:17 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Wed, 12 Aug 2009 15:08:11 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Dave Cridland <[e-mail]>
CC: Peter Saint-Andre <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <8048.1249935609.418434@puncture>
In-Reply-To: <8048.1249935609.418434@puncture>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Cridland wrote:

> On Mon Aug 10 21:01:13 2009, Peter Saint-Andre wrote:
>
>> Instead of requiring the application of SASLprep, I would prefer  
>> wording
>> such as this:
>>
>>    Before sending the username to the server, the client MUST
>>    ensure that the username is formatted such that the "SASLPrep"
>>    profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
>>    applied to it without failing.
>
> Although initially, my thought was this wasn't needed, I wondered  
> about the consequences.
>
> It seems to me that, unless we assume that both client and server  
> will always have precisely the same concept of "SASLprep", then one  
> would assume the server would always have to apply SASLprep anyway.
>
> SASLprep is, also bound to change - either gradual changes in Unicode  
> will cause problems sufficient to case a rewrite, or we'll change  
> SASLprep itself to be a property-based, instead of table-based,  
> mechanism, and the gradual changes will filter through to  
> implementations.
>
> I'm inclined, therefore, to suggest that not only is this text  
> reasonable, but the "MUST" can probably be reduced to a SHOULD.

I can live with the SHOULD.
 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AKKF6T030609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 13:20:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7AKKFp1030608; Mon, 10 Aug 2009 13:20:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AKKDMp030600 for <[e-mail]>; Mon, 10 Aug 2009 13:20:14 -0700 (MST) (envelope-from [e-mail])
Received: from puncture ((unknown) [217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id <[e-mail]>; Mon, 10 Aug 2009 21:20:10 +0100
X-SMTP-Protocol-Errors: NORDNS
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Message-Id: <8048.1249935609.418434@puncture>
Date: Mon, 10 Aug 2009 21:20:09 +0100
From: Dave Cridland <[e-mail]>
To: Peter Saint-Andre <[e-mail]>, <[e-mail]>, Tom Yu <[e-mail]>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon Aug 10 21:01:13 2009, Peter Saint-Andre wrote:
> Instead of requiring the application of SASLprep, I would prefer  
> wording
> such as this:
> 
>    Before sending the username to the server, the client MUST
>    ensure that the username is formatted such that the "SASLPrep"
>    profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
>    applied to it without failing.
> 
> 
Although initially, my thought was this wasn't needed, I wondered  
about the consequences.

It seems to me that, unless we assume that both client and server  
will always have precisely the same concept of "SASLprep", then one  
would assume the server would always have to apply SASLprep anyway.

SASLprep is, also bound to change - either gradual changes in Unicode  
will cause problems sufficient to case a rewrite, or we'll change  
SASLprep itself to be a property-based, instead of table-based,  
mechanism, and the gradual changes will filter through to  
implementations.

I'm inclined, therefore, to suggest that not only is this text  
reasonable, but the "MUST" can probably be reduced to a SHOULD.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AK1QBH029289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 13:01:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7AK1QkN029288; Mon, 10 Aug 2009 13:01:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from stpeter.im (stpeter.im [207.210.219.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7AK1H85029268 for <[e-mail]>; Mon, 10 Aug 2009 13:01:25 -0700 (MST) (envelope-from [e-mail])
Received: from dhcp-64-101-72-211.cisco.com (dhcp-64-101-72-211.cisco.com [64.101.72.211]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1286F4007B; Mon, 10 Aug 2009 14:01:14 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 14:01:13 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Tom Yu <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/13/09 8:17 PM, Tom Yu wrote:
> This message commences a WG Last Call on the following Internet-Draft:
> 
> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism

Although the WGLC is officially over, I have a question about the use of
SASLprep.

The SCRAM I-D (draft-ietf-sasl-scram-04) says the following:

   Before sending the username to the server, the client MUST
   prepare the username using the "SASLPrep" profile [RFC4013]
   of the "stringprep" algorithm [RFC3454].

In XMPP, we have traditionally used a different stringprep profile
("nodeprep") to prepare usernames. As far as I can see, nodeprep is more
strict than SASLprep. Therefore, any username which is prepared
according to nodeprep would be safe according to SASLprep.

Instead of requiring the application of SASLprep, I would prefer wording
such as this:

   Before sending the username to the server, the client MUST
   ensure that the username is formatted such that the "SASLPrep"
   profile [RFC4013] of the "stringprep" algorithm [RFC3454] can be
   applied to it without failing.

(We have similar wording in RFC 3920 and in rfc3920bis.)

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqAfIkACgkQNL8k5A2w/vwYrwCZATJzn3RcK+Cjs996FnIIr7El
3pwAnR95RzWJWcp6TDv91Er44bNOVa5m
=9AOc
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74FU8YM092124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2009 08:30:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n74FU8bJ092123; Tue, 4 Aug 2009 08:30:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n74FU8kW092116 for <[e-mail]>; Tue, 4 Aug 2009 08:30:08 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 294E828C41C; Tue,  4 Aug 2009 08:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-16.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  4 Aug 2009 08:30:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-16.txt
	Pages           : 24
	Date            : 2009-08-04

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding.  Only GSS-API mechanisms that support channel
binding are supported.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-16.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-16.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7389J44056591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 01:09:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n7389JRt056590; Mon, 3 Aug 2009 01:09:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n7389BA1056565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 3 Aug 2009 01:09:18 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n73897aW008267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 3 Aug 2009 10:09:09 +0200
From: Simon Josefsson <[e-mail]>
To: Peter Saint-Andre <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-02
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090803:[e-mail]::L+9Cnl5J8u9dPdNA:HfsI
X-Hashcash: 1:22:090803:[e-mail]::6hqONuEvHgQDSskp:KzSw
X-Hashcash: 1:22:090803:[e-mail]::SR+1xVA9HZmrMgS0:J3hj
Date: Mon, 03 Aug 2009 10:09:07 +0200
In-Reply-To: <[e-mail]> (Peter Saint-Andre's message of "Fri, 31 Jul 2009 19:14:48 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.96 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Saint-Andre <[e-mail]> writes:

> On 7/30/09 2:37 PM, Simon Josefsson wrote:
>> Alexey Melnikov <[e-mail]> writes:
>> 
>>> Peter Saint-Andre wrote:
>>>
>>>>> SECTION 4
>>>>>
>>>>> Typo: "hashed function" => "hash function"
>>>>>
>>>>> I think the following text is slightly ambiguous:
>>>>>
>>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>>   binding to the external channel.  In this case the server will
>>>>>   advertise both, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, otherwise the
>>>>>   server will advertise only SCRAM-SHA-1.  The "-PLUS" exists to allow
>>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>>
>>>>> This could be read to mean that if a server does not support channel
>>>>> bindings, then it will advertise only all and only SCRAM-SHA-1 (but
>>>>> never, say, SCRAM-SHA-256). I think we mean that if a server does not
>>>>> support channel bindings, then it will advertise only mechanisms of the
>>>>> form SCRAM-SHA-length and never mechanisms of the form
>>>>> SCRAM-SHA-length-PLUS (thus not forbidding support for hash functions
>>>>> other than SHA-1).
>>>>>    
>>>>>
>>>> Alexey and I talked about this in Stockholm. I suggest the following text:
>>>>
>>>>   The "-PLUS" suffix is used only when the server supports channel
>>>>   binding to the external channel.  If the server supports channel
>>>>   binding, it will advertise both the "bare" and "plus" versions of
>>>>   whatever mechanisms it supports (e.g., if the server supports only
>>>>   SCRAM with SHA-1 then it will advertise support for both SCRAM-SHA-1
>>>>   and SCRAM-SHA-1-PLUS); if the server does not support channel
>>>>   binding, then it will advertise only the "bare" version of the
>>>>   mechanism (e.g., only SCRAM-SHA-1).  The "-PLUS" exists to allow
>>>>   negotiation of the use of channel binding.  See Section 6.
>>>>  
>>>>
>>> Ok, this text will be in -04.
>> 
>> Please reassure me that the same change isn't needed in GS2?  I don't
>> see any normative words above, and as far as I can tell the described
>> behaviour is already covered by other text in both SCRAM and GS2 anyway.
>
> Do you think that the former text was not ambiguous?

No, I think your version is definitely better, but I couldn't find
matching text in GS2 to change.  I _think_ your clarification is already
covered by what's in GS2 today, including for example this text:

	      <t>Servers SHOULD advertise both non-PLUS and the
		PLUS-variant of each GS2 mechanism name.  If the
		server cannot support channel binding, it MAY
		advertise only the non-PLUS variant.  If the server
		would never succeed authentication of the non-PLUS
		variant due to policy reasons, it MAY advertise only
		the PLUS-variant.</t>

It doesn't use the same words although I believe the intention is the
same.

/Simon