Re: [TLS] draft-jay-tls-psk-identity-extension-01

[Raja ashok]

Hi David & Nikos,

3rd version of the draft-jay-tls-psk-identity-extension has been submitted. 
Your valuable comments are also fixed.
Please go through once and provide me your suggestion.

@Andreas : Requesting you also to go through and provide your suggestion.


Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which 
is intended only for the person or entity whose address is listed above. Any 
use of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by 
phone or email immediately and delete it!


-Original Message-
From: Raja ashok 
Sent: 21 September 2016 23:17
To: 'David Woodhouse'; Nikos Mavrogiannopoulos
Cc: 'jayaraghavend...@gmail.com'; tls@ietf.org
Subject: RE: draft-jay-tls-psk-identity-extension-01

Hi David & Nikos,

My comments are inlined in below mail, please check it.

-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: 19 September 2016 13:04
To: Nikos Mavrogiannopoulos; Raja ashok; jayaraghavendra...@huawei.com
Subject: Re: draft-jay-tls-psk-identity-extension-01

On Sat, 2016-09-17 at 09:53 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  We were with David implementing the draft-jay-tls-psk-identity-
> extension-01 on openconnect VPN, however we noticed that the latest 
> version of TLS 1.3 modified the identity extension in an incompatible 
> way. I am not sure if the new format can be used in place of the old 
> one. For that we would like to ask what is your plan about it. Would 
> you include the new format with some guidance on how to be used under 
> tls 1.2, or would you stick to the existing format?

[ashok]  : PSK Identity extension specified in our extension differs from the 
extension specified in TLS1.3. In TLS1.3 PSK identity extension they are trying 
to exchange whether its DHE based PSK or not and also authentication mechanism 
(PSK or cert based authentication), all these things for key_share extension. 
So that TLS1.3 has PskKeyExchangeModes and PskAuthenticationModes. But I hope 
these are not required for lower versions (TLS1.2, 1.1 and 1.0). So the 
extension proposed in this draft is only for usage with TLS1.2, 1.1 and 1.0. 
And I feel, we can make this as a separate extension to avoid confusion with 
TLS1.3 extension. If we feel anything needs to be inherited from TLS1.3 
extension, we can do it.

A couple of other comments on looking in detail at the draft...

RFC4279 §5.1 says that PSK identities MUST be a character string, encoded in 
UTF-8.

But the TLSv1.3 draft doesn't say this anywhere, and in fact in §4.5.1 it seems 
to suggest that for session resumption, we use a ticket constructed according 
to RFC5077 as the PSK identity. Which would probably be binary.

If TLSv1.3 is going to allow non-UTF8 PSK identities and TLSv1.2 still doesn't, 
then it would be useful to clarify precisely what is allowed in 
draft-jay-tls-psk-identity-extension.

[ashok] : PSK identity extension specified in this draft also expects the PSK 
ID as character string in UTF format, similar to RFC 4279. I will update this 
point in our draft, thanks for reminding me.

Another difference I note between your draft and the current TLSv1.3 draft is 
that in TLSv1.3, the PreSharedKeyExtension data returned by the server is just 
an index in the identities offered by the client; not a copy of the identifier 
itself:

   struct {
   select (Handshake.msg_type) {
   case client_hello:
   PskIdentity identities<6..2^16-1>;

   case server_hello:
   uint16 selected_identity;
   }
   } PreSharedKeyExtension;


...
   selected_identity The server’s chosen identity expressed as a
 (0-based) index into the identities in the
 client’s list.

[ashok] : I feel sending the selected ID is better, otherwise while process 
"server hello" msg, client has to maintain the PSK ID list in the same order in 
which it sent. Already there was a discussion in TLS1.3 group for sending 
selected ID instead of index. 

And a final nitpick... replace every instance it "it's" with "its" :)

[ashok] : I will check and fix it. I will upload a revised draft. Thanks for 
your comments.


-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation




Raja Ashok
HUAWEI TECHNOLOGIES CO.,LTD. 

E-mail: raja.as...@huawei.com
www.huawei.com

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[David Woodhouse]

On Wed, 2016-09-21 at 13:49 -0700, Eric Rescorla wrote:
> 
> Is there a real-world use-case where this is relevant?

The number ten might be a little excessive. But there is talk of
multiple sessions being simultaneously for resumption, and multiple PSK
identities in the original meaning of that term.

So I suppose there are certainly use cases where a "HRR and let the
client *guess* what we might like instead" model would lead to more
round-trips than an explicit indication from the server.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[Eric Rescorla]

On Wed, Sep 21, 2016 at 1:43 PM, David Woodhouse 
wrote:

> On Wed, 2016-09-21 at 13:36 -0700, Eric Rescorla wrote:
> > >
> > I don't see how this is appreciably easier than just having the
> > client offer one and then the server HRR.
>
> If I have ten PSK identities I can offer, it may take nine round-trips
> before I send the one you want.
>
> If I list them all in my first ClientHello and you *tell* me which one
> you want, that's only one more round-trip.


Is there a real-world use-case where this is relevant?

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[David Woodhouse]

On Wed, 2016-09-21 at 13:36 -0700, Eric Rescorla wrote:
> > 
> I don't see how this is appreciably easier than just having the
> client offer one and then the server HRR.

If I have ten PSK identities I can offer, it may take nine round-trips
before I send the one you want.

If I list them all in my first ClientHello and you *tell* me which one
you want, that's only one more round-trip.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[Ilari Liusvaara]

On Wed, Sep 21, 2016 at 09:33:11PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> > On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> 
> > [1] E.g. altering hello_finished to be a list, one entry for each
> > identity, or omitting it entierely for "implicit finished with the
> > used 0-RTT key before ServerHello" trick I outlined earlier.
> > 
> > (Neither is probably pleasant to implement... The latter is probably
> > easier if the library architecture is suitable).
> 
> I had also suggested including a hello_finished only for the first
> (preferred) PSK identity. If the server doesn't want that one, it can
> send a HelloRetryRequest with a PreSharedKeyExtension indicating which
> PSK identity it *does* want.
> 
> Or did I miss a reason why that wasn't sufficient and *each*
> ClientHello needed to be validated? I confess I've only been looking at
> this for the last day or so.

Basically, you need the binder (finished) for whatever PSK you actually
wind up using, or you have attacks in some cases.

So it would technically be possible to have multiple PSK identites,
and use HRR to change the one used (followed by client signaling
finished for that one in new ClientHello).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[Eric Rescorla]

On Wed, Sep 21, 2016 at 1:33 PM, David Woodhouse 
wrote:

> On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> > On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> > >
> > > On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> > >
> > > >
> > > > [ashok] : I feel sending the selected ID is better, otherwise while
> > > > process "server hello" msg, client has to maintain the PSK ID list in
> > > > the same order in which it sent. Already there was a discussion in
> > > > TLS1.3 group for sending selected ID instead of index.
> > > There is also discussion of supporting only a *single* PSK identity in
> > > TLSv1.3. If that happens, is there a real need for the extension to
> > > permit more than one identity in TLS <= 1.2.
> > Is the intended usecase some "IoT"/"embedded" devices? If so, I think
> > this is *extremely* bad idea.
> >
> > Those things tend to have very long lifespans, so one shouldn't put
> > one out except with cutting-edge stuff. Anything less, and there is
> > substantial risk of it going bad during lifetime.
> >
> > It would be possible to retrofit an extension to do multiple identites
> > at once into TLS 1.3 even if baseline TLS 1.3 allows only one, altough
> > implementing it probably will not be pleasant.[1]
>
> Typically I would expect that a given IoT client would still support
> only one form of PSK, and offer one identifier. The update model would
> be that the server accepts *either* the old or the new keys, and
> clients are slowly upgraded to offer the latter. But still only one at
> a time?
>
> > [1] E.g. altering hello_finished to be a list, one entry for each
> > identity, or omitting it entierely for "implicit finished with the
> > used 0-RTT key before ServerHello" trick I outlined earlier.
> >
> > (Neither is probably pleasant to implement... The latter is probably
> > easier if the library architecture is suitable).
>
> I had also suggested including a hello_finished only for the first
> (preferred) PSK identity. If the server doesn't want that one, it can
> send a HelloRetryRequest with a PreSharedKeyExtension indicating which
> PSK identity it *does* want.
>

I don't see how this is appreciably easier than just having the client
offer one and then
the server HRR.

-Ekr


>
> Or did I miss a reason why that wasn't sufficient and *each*
> ClientHello needed to be validated? I confess I've only been looking at
> this for the last day or so.
>
> --
> dwmw2
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[David Woodhouse]

On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> > 
> > On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> > 
> > > 
> > > [ashok] : I feel sending the selected ID is better, otherwise while
> > > process "server hello" msg, client has to maintain the PSK ID list in
> > > the same order in which it sent. Already there was a discussion in
> > > TLS1.3 group for sending selected ID instead of index. 
> > There is also discussion of supporting only a *single* PSK identity in
> > TLSv1.3. If that happens, is there a real need for the extension to
> > permit more than one identity in TLS <= 1.2. 
> Is the intended usecase some "IoT"/"embedded" devices? If so, I think
> this is *extremely* bad idea.
> 
> Those things tend to have very long lifespans, so one shouldn't put
> one out except with cutting-edge stuff. Anything less, and there is
> substantial risk of it going bad during lifetime.
> 
> It would be possible to retrofit an extension to do multiple identites
> at once into TLS 1.3 even if baseline TLS 1.3 allows only one, altough
> implementing it probably will not be pleasant.[1]

Typically I would expect that a given IoT client would still support
only one form of PSK, and offer one identifier. The update model would
be that the server accepts *either* the old or the new keys, and
clients are slowly upgraded to offer the latter. But still only one at
a time?

> [1] E.g. altering hello_finished to be a list, one entry for each
> identity, or omitting it entierely for "implicit finished with the
> used 0-RTT key before ServerHello" trick I outlined earlier.
> 
> (Neither is probably pleasant to implement... The latter is probably
> easier if the library architecture is suitable).

I had also suggested including a hello_finished only for the first
(preferred) PSK identity. If the server doesn't want that one, it can
send a HelloRetryRequest with a PreSharedKeyExtension indicating which
PSK identity it *does* want.

Or did I miss a reason why that wasn't sufficient and *each*
ClientHello needed to be validated? I confess I've only been looking at
this for the last day or so.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[Ilari Liusvaara]

On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> 
> > [ashok] : I feel sending the selected ID is better, otherwise while
> > process "server hello" msg, client has to maintain the PSK ID list in
> > the same order in which it sent. Already there was a discussion in
> > TLS1.3 group for sending selected ID instead of index. 
> 
> There is also discussion of supporting only a *single* PSK identity in
> TLSv1.3. If that happens, is there a real need for the extension to
> permit more than one identity in TLS <= 1.2. 

Is the intended usecase some "IoT"/"embedded" devices? If so, I think
this is *extremely* bad idea.

Those things tend to have very long lifespans, so one shouldn't put
one out except with cutting-edge stuff. Anything less, and there is
substantial risk of it going bad during lifetime.

It would be possible to retrofit an extension to do multiple identites
at once into TLS 1.3 even if baseline TLS 1.3 allows only one, altough
implementing it probably will not be pleasant.[1]

Also, has anyone done security analysis of doing PSK negotiation that
way in TLS 1.2 (someone has clearly done that for TLS 1.3, given
some of the attacks posted)...


[1] E.g. altering hello_finished to be a list, one entry for each
identity, or omitting it entierely for "implicit finished with the
used 0-RTT key before ServerHello" trick I outlined earlier.

(Neither is probably pleasant to implement... The latter is probably
easier if the library architecture is suitable).



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-jay-tls-psk-identity-extension-01

[David Woodhouse]

On Wed, 2016-09-21 at 17:46 +, Raja ashok wrote:
> [ashok]  : PSK Identity extension specified in our extension differs
> from the extension specified in TLS1.3. 

Agreed. I suspect it just makes sense to add a sentence to that effect,
to the draft?

> [ashok] : I feel sending the selected ID is better, otherwise while
> process "server hello" msg, client has to maintain the PSK ID list in
> the same order in which it sent. Already there was a discussion in
> TLS1.3 group for sending selected ID instead of index. 

Yes, I agree. In TLS1.3 it kind of makes sense, because the PSK
identifiers there can be huge — they are the full session ticket from
RFC5077. So it makes some sense to send back only an index. But in
TLS <= 1.2 when you're not (ab)using PSK for session resumption, that
motivation goes away and returning the identity itself seems
reasonable. But again, it's just worth calling out the differences
between TLSv1.3 for clarity.

There is also discussion of supporting only a *single* PSK identity in
TLSv1.3. If that happens, is there a real need for the extension to
permit more than one identity in TLS <= 1.2. 

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls