Re: [TLS] draft-nir-tls-eap-03
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] draft-nir-tls-eap-03
Yoav Nir <ynir at checkpoint.com> writes:
>Regarding section 4.2 (comment (5)) I also believe that identity protection
>is important, but that belief is not universally shared. For example, the
>TLS-PSK protocol does not provide it. I'm not sure what I can do to elaborate
>more on this, except to say (as we have) that "we believe that identity
>protection is a worthy enough goal, so as to justify the extra round-trip.".
>Can you suggest anything stronger?
What about allowing the client to specify whether it wants identity protection
or not, to save the extra RTT? All you'd need is to allow the client to
specify their identity in the hello (as the draft indicates), if the server
gets a client ID as an extension in the hello then they can go straight to the
fastpath version, otherwise there's an extra RTT. IdenFrom tls-bounces at ietf.org Thu May 1 03:45:23 2008
Return-Path: <tls-bounces at ietf.org>
X-Original-To: tls-archive at ietf.org
Delivered-To: ietfarch-tls-archive at core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9ABDD3A6B8B;
Thu, 1 May 2008 03:45:23 -0700 (PDT)
X-Original-To: tls at core3.amsl.com
Delivered-To: tls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id C309F3A6B8B
for <tls at core3.amsl.com>; Thu, 1 May 2008 03:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id MsBrh5iOC6+b for <tls at core3.amsl.com>;
Thu, 1 May 2008 03:45:20 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz
[130.216.12.34])
by core3.amsl.com (Postfix) with ESMTP id 815283A6922
for <tls at ietf.org>; Thu, 1 May 2008 03:45:16 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mailhost.auckland.ac.nz (Postfix) with ESMTP id DF9E418DAD;
Thu, 1 May 2008 22:45:17 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1])
by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id RCPIoEaDPHir; Thu, 1 May 2008 22:45:17 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152])
by mailhost.auckland.ac.nz (Postfix) with ESMTP id F083018DAA;
Thu, 1 May 2008 22:45:16 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz
[130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by iris.cs.auckland.ac.nz (Postfix) with ESMTP
id EA51319EC0B9; Thu, 1 May 2008 22:45:14 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63)
(envelope-from <pgut001 at wintermute01.cs.auckland.ac.nz>)
id 1JrWHq-0005oA-Qp; Thu, 01 May 2008 22:45:14 +1200
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: ah at tr-sys.de, tls at ietf.org, ynir at checkpoint.com
In-Reply-To: <07041089-61BC-4102-8061-100E7D1BC69D at checkpoint.com>
Message-Id: <E1JrWHq-0005oA-Qp at wintermute01.cs.auckland.ac.nz>
Date: Thu, 01 May 2008 22:45:14 +1200
Cc: yaronf at checkpoint.com, Hannes.Tschofenig at siemens.com
Subject: Re: [TLS] draft-nir-tls-eap-03
X-BeenThere: tls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working
group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:tls at ietf.org>
List-Help: <mailto:tls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
<mailto:tls-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces at ietf.org
Errors-To: tls-bounces at ietf.org
Yoav Nir <ynir at checkpoint.com> writes:
>Regarding section 4.2 (comment (5)) I also believe that identity protection
>is important, but that belief is not universally shared. For example, the
>TLS-PSK protocol does not provide it. I'm not sure what I can do to elaborate
>more on this, except to say (as we have) that "we believe that identity
>protection is a worthy enough goal, so as to justify the extra round-trip.".
>Can you suggest anything stronger?
What about allowing the client to specify whether it wants identity protection
or not, to save the extra RTT? All you'd need is to allow the client to
specify their identity in the hello (as the draft indicates), if the server
gets a client ID as an extension in the hello then they can go straight to the
fastpath version, otherwise there's an extra RTT. Identity protity protection seems
to be one of those things that only geeks actually care about - I've never
encountered any user that's even asked about this, but I have had several
queries from users working in resource-constrained environments about how to
minimise the handshake overhead, so a fastpath option would be a good thing.
(Alternatively, make fastpath the default and do an anon-DH + rehandshake with
TLS-EAP if identity protection is really such a big deal).
Peter.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
tection seems
to be one of those things that only geeks actually care about - I've never
encountered any user that's even asked about this, but I have had several
queries from users working in resource-constrained environments about how to
minimise the handshake overhead, so a fastpath option would be a good thing.
(Alternatively, make fastpath the default and do an anon-DH + rehandshake with
TLS-EAP if identity protection is really such a big deal).
Peter.
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.