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

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVufp-0005H7-Nu; Tue, 18 Apr 2006 14:11:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVufo-0005GZ-Sz; Tue, 18 Apr 2006 14:11:36 -0400
Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVufn-0006W4-JV; Tue, 18 Apr 2006 14:11:36 -0400
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 19:11:35 +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 19:11:04 +0100
Message-ID: <BF9309599A71984CAC5BAC5ECA62994404AA28C1@EUR-MSG-11.europe.corp.microsoft.com>
In-Reply-To: <861wvubvyu.fsf@raman.networkresonance.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: AcZjErdJSi0PQ+xGSJ+OXmLE2I2QWgAAHX9g
From: "Stefan Santesson" <stefans@microsoft.com>
To: "EKR" <ekr@networkresonance.com>
X-OriginalArrivalTime: 18 Apr 2006 18:11:35.0020 (UTC) FILETIME=[872F72C0:01C66313]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
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

Eric,

On last issue, I will add that explanation to my change log.


Stefan Santesson
Program Manager, Standards Liaison
Windows Security


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@raman.networkresonance.com]
> Sent: den 18 april 2006 10:05
> To: Stefan Santesson
> Cc: Russ Housley; iesg@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-
> santesson-tls-supp-00
> 
> "Stefan Santesson" <stefans@microsoft.com> writes:
> 
> >> 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."?
> 
> Yes, I think that's right.
> 
> 
> >> 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.
> 
> That doesn't really resolve my issue, because it still results in
> incompletely specified semantics.
> 
> 
> >> >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.
> 
> Then that that needs to be stated clearly in the specification.
> 
> -Ekr
> 
> 
> 


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