[TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00

Eric Rescorla <ekr@networkresonance.com> Mon, 17 April 2006 23:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcqm-0007Ku-O1; Mon, 17 Apr 2006 19:09:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcqm-0007JD-3f; Mon, 17 Apr 2006 19:09:44 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcqk-0003Wb-PY; Mon, 17 Apr 2006 19:09:44 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 1B82B222418; Mon, 17 Apr 2006 16:15:59 -0700 (PDT)
To: Russ Housley <housley@vigilsec.com>
In-reply-to: Your message of "Mon, 17 Apr 2006 17:10:36 EDT." <7.0.0.16.2.20060417170510.03659fe0@vigilsec.com>
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18)
Date: Mon, 17 Apr 2006 16:09:40 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060417231559.1B82B222418@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: iesg@ietf.org, tls@ietf.org
Subject: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Russ Housley <housley@vigilsec.com> wrote:
> >-tls-ume:
> >Why is this draft going to Proposed? ISTM that it's pretty
> >hard to interpret without a bunch of MS-proprietary
> >information. There's no need for it to go to Proposed, since
> >both extensions and Supp-data allow code points to be
> >issued via informational.
> 
> This is being discussed.  The reason that I would like to see it as
> standards-track is that the structure supports more than just
> Microsoft names.  The Microsoft names are simply the first ones that
> are supported.

I'm sympathetic to this, but I'm also uncomfortable with having a PS
that's not really implementable in part. That said, this is probably
part of a higher level IETF/IESG policy discussion rather than
a TLS one.


> >S 4:
> >You can do the UPN hint extension exchange and then NOT
> >send supp_data? That seems wrong.
> 
> I agree, if the negotiation is successful, then the supplemental data
> should be sent.

This should be a MUST, IMO. I.e., the peer can and probably
should detect it and throw an error. If it's a SHOULD,
then the document needs to explain how.

Best,
-Ekr


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls