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

"Stefan Santesson" <stefans@microsoft.com> Tue, 18 April 2006 17:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuRm-0001Rl-I3; Tue, 18 Apr 2006 13:57:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVuRk-0001RU-J9; Tue, 18 Apr 2006 13:57:04 -0400
Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVuRi-0005MA-7E; Tue, 18 Apr 2006 13:57:04 -0400
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 18:57:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00
Date: Tue, 18 Apr 2006 18:56:59 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA28B7@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <7.0.0.16.2.20060417170510.03659fe0@vigilsec.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00
Thread-Index: AcZiczQV9pG2zD0PT2aJAtK7UKL6GgAnBGRQ
From: "Stefan Santesson" <stefans@microsoft.com>
To: "Russ Housley" <housley@vigilsec.com>, "Eric Rescorla" <ekr@networkresonance.com>
X-OriginalArrivalTime: 18 Apr 2006 17:57:01.0501 (UTC) FILETIME=[7E8706D0:01C66311]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: iesg@ietf.org, tls@ietf.org
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

In, line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security


> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: den 17 april 2006 13:11
> To: Eric Rescorla
> Cc: iesg@ietf.org; tls@ietf.org
> Subject: [TLS] Re: Comments on
draft-santesson-tls-ume-04/draft-santesson-
> tls-supp-00
> 
> Eric:
> 
> >These drafts seem basically sound. Minor comments below.
> >
> >-tls-supp:
> >You should state that only one SupplementalData field may
> >be used per handshake.
> 
> I agree.  This was pointed out by the Gen-ART reviewer too.
> 

[Stefan] I've put this on my change log. To be precise in words, should
the text state that "The client and server MUST NOT send more than one
supplementalData handshake message each."?


> >Somewhere you should note that this data SHOULD NOT be
> >processed by TLS but just passed up to the application.
> 
> I agree.  This was also raised by Cullen.
> 

[Stefan] On my change log

> >-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.
> 
[Stefan] A agree to the proposed path of the reason stated by Russ. I'm
willing to tune down the mentioning of Microsoft as it isn't necessary
for the syntax definitions of this document.

> >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.
> 
[Stefan] I don't see much value in this direction as the server MUST be
prepared for the case where the client chooses not to send any hint. It
may have come to the conclusion that this is not the right server to
send the hint it intended for some reason. Another reason may be that
the user has declined sending his user name to this server in a user
dialog box.

I view sending of hints as completely voluntary at the discretion of the
client. Even after extension exchange.




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

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