Re: [TLS] [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00

[Jim Schaad]

Yes I did mean to send this to tls not cfrg - I had just sent mail there and
did not look hard.


> -Original Message-
> From: Christopher Wood 
> Sent: Wednesday, July 1, 2020 2:09 PM
> To: Jim Schaad 
> Subject: Re: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00
> 
> (-lists)
> 
> Hi Jim,
> 
> Before replying, did you mean to cc tls@ instead of cfrg@?
> 
> Thanks!
> Chris
> 
> On Wed, Jul 1, 2020, at 2:02 PM, Jim Schaad wrote:
> > * In section 4 there is a statement that switching the roles of
> > servers which use PSKs will lead to weakening of security properties.
> > As this is a common scenario today in situations where you are doing
> > server-to-server communication, it would be useful to discuss just how
> > and how much this weakening occurs.  This was a complete surprise to
> > me and I don't know if it was supposed to be one.  Are there mitigations
that
> can be made?
> >
> > * In section 7, The first sentence does not read, also It seems a bit
> > difficult to have a MUST in there when most of the items below are
SHOULDs.
> > That seems to be a dissonance.
> >
> > * Section 7.1.1 - The idea of having domain name suffixes on PSKs
> > seems to me to be a bad idea as this would seem to lower privacy levels.
> >
> > * Section 7.1.2 - There seem to me to be three different places where
> > collisions will occur.  The importer function could get a collision,
> > there could be collisions with pre-TLS 1.2 external identifiers and
> > there could be collision with resumption keys.  There has been a huge
> > discussion about this in the EMU group and I don't find the text here
> > to be sensible in term of whether this is or is not a problem.
> >
> > * Section 7.1.2 - One of the things that I kept meaning to get to and
> > just haven't done so yet, is dealing with the question of can the TLS
> > Key binders in the handshake to distinguish between multiple keys that
> > happen to have the same identity.  Perhaps you should look to see if
> > this does work and if it is safe.
> >
> > Jim
> >
> >
> > ___
> > Cfrg mailing list
> > c...@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> >

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

Re: [TLS] draft-ietf-tls-ticketrequests-05

[Ilari Liusvaara]

On Wed, Jul 01, 2020 at 04:52:18PM +, Hannes Tschofenig wrote:
> Hi Tommy, Hi David, Hi Chris,
> 
> I read through the draft and have a few questions.
> 
> 1) Is it really necessary for the client to use two values to
> differentiate the tickets it wants with a new session and with
> resumption. It feels a bit over-designed. I would just have one
> value and that alone would be super useful already.

Consider a client that does:

- Parallel connections
- Does not reuse tickets

Such client needs enough tickets to cover the multiple connections
in case of fresh handshake (might be 5-10 or so), but only needs to
replace the tickets for current connection (1 or 2) in case of
resumption. So any single value will result in oversupply or
undersupply.

> 2) This sentence confuses me:
> "
>Servers SHOULD NOT send more tickets than requested for the handshake
>type selected by the server (resumption or full handshake).
>Moreover, servers SHOULD place a limit on the number of tickets they
>are willing to send, whether for full handshakes or resumptions, to
>save resources.
> "
> 
> Shouldn't the sentence say:
> "
>Servers SHOULD NOT send more tickets than requested for the handshake
>type (resumption or full handshake) indicated by the client.
> "

The server might not want to actually honor request to send 255 tickets.
Even if ticket minting is a fast operation, 255 of them might take non-
trivial time (and bandwidth).

> Even then, I believe the sentence should actually say MUST NOT instead
> of SHOULD NOT. If the client is already taking the effort to indicate
> that it does not want more than a certain number of tickets then it
> might have a reason. I am thinking about the case where the client
> indicates that it does not want any tickets then it would be strange
> for the server expressing support for the extension and still send
> tickets.

If the client signals 0 tickets for handshake and 0 tickets for
resumption, then reasonable interpretation is that client does not
support resumption at all, and it is waste of resources to send it
any tickets.

But how should server interpret client saying it wants 1 ticket for
full handshake and 0 tickets for resumption? A reasonable interpretation
is that client does support tickets and is is willing to reuse tickets.
So if the server is not willing to reuse tickets, the most reasonable
action is to send 1 ticket to the client on resumption (if server is
willing to reuse tickets, the most reasonable act is not send any
tickets on resumption).

Basically, there can be good reasons to send more tickets than
requested. Just that most of the time, sending more tickets will lead
to oversupply.

> 4) I believe it would make sense to define a ticket flag for the
> case where the client does not want to receive any tickets.

The sensible way to indicate that is to send (0,0) as requested
ticket count.

> 5) If a client sends the ClientTicketRequest extension during the
> full handshake is there an expectation that it sends it again in
> the resumption exchange? Would you assume that the server memorizes
> how many tickets the client wanted across the resumption handshakes?
> For example, in the full handshake I use the extension and indicate
> that I want 5 tickets. I get two tickets from the server. Then, I
> run a resumption handshake without transmitting the extension. Is
> the server expected to remember to still send 3 more tickets till
> the quota is exhausted?

I expect each connection to have its own ticket request counts.

In general, it is unsafe to cache extension values across connections
in session. Sure, one probably can not cause anything bad with this
extension, but with things like server_name, very bad stuff can happen
if those are not taken from connection handshake.


> 6) The topic of when to send the tickets is something you mention
> in the document and it is indeed an issue. Have you thought about
> allowing the client to signal to the server when to send the
> tickets? Even making a distinction between "send me all tickets in
> a batch" and "send one after the other with some reasonable time in
> between" would be helpful.

What usecases would there be in spreading tickets in time?


-Ilari

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

Re: [TLS] Proposed change in TLS-Flags

[David Schinazi]

Thanks for the context, everyone!
Based on that, PR looks good to me. Ship it!

David

On Tue, Jun 30, 2020 at 9:18 PM Martin Thomson  wrote:

> More to the point, this makes it more difficult to analyze relative to an
> empty "flag" extension of the likes we currently use.
>
> I haven't implemented this, but I imagine one strategy would be to rewrite
> these flags and pretend that they were empty extensions.  That would allow
> implementations to reuse a lot of infrastructure, like the stuff we added
> for custom extensions.  That would be more difficult if the server can
> speak first.
>
> On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote:
> > Yeah, the thread that Nick mentioned.
> >
> > Also, since there are no such extensions defined in the base TLS 1.3
> > spec, the server can’t assume that the client knows what either the
> > specific flag means, or the entire flags extension means.
> >
> > So suppose we invent some new client authentication scheme for TLS, it
> > does make sense for the server to signal that it supports this so that
> > the client can do. But I don’t think it’s too onerous to require that
> > the client indicate support first.
> >
> > Yoav
> >
> > > On 1 Jul 2020, at 2:30, David Schinazi 
> wrote:
> > >
> > > Hi Yoav,
> > >
> > > Could you elaborate on the rationale for this change please?
> > > I was assuming that the ability for servers to send extensions not
> requested by clients was useful.
> > >
> > > Thanks,
> > > David
> > >
> > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir  wrote:
> > >> Hi
> > >>
> > >> I’ve just submitted the following PR:
> > >>
> > >> https://github.com/tlswg/tls-flags/pull/4
> > >>
> > >> Three changes:
> > >>  * It is no longer allowed to send an empty flags extension. If you
> don’t support any flags, don’t send the extension.
> > >>  * The server is no longer allowed to respond with flag types that
> the client didn’t indicate support for first.
> > >>  * I’ve split the extension description section into a format section
> and a rules section
> > >>
> > >> Please comment. Barring any objections, I’ll merge the PR just before
> the submission deadline.
> > >>
> > >> Yoav
> > >>
> > >> ___
> > >>  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
> >
>
> ___
> 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] Proposed change in TLS-Flags

[Yoav Nir]

I don’t know. There already is an extension for this.

We haven’t discussed whether we want to “cover” semantics that already exist in 
other extensions.

If that’s something the group wants, we can add it, but it’s not generally a 
good thing for a protocol to have two ways of expressing the same thing.

Yoav

> On 1 Jul 2020, at 19:00, Hannes Tschofenig  wrote:
> 
> One question: Wouldn’t you want to register a flag for "Post-Handshake Client 
> Authentication" in this document?
> 
> Ciao
> Hannes
> 
> 
> From: TLS  On Behalf Of Hannes Tschofenig
> Sent: Wednesday, July 1, 2020 5:55 PM
> To: Yoav Nir ;  
> Subject: Re: [TLS] Proposed change in TLS-Flags
> 
> Yoav,
> 
> I looked at the draft and the PR. I am fine with the proposed changes.
> This is a short and useful draft.
> 
> Ciao
> Hannes
> 
> From: TLS  On Behalf Of Yoav Nir
> Sent: Monday, June 29, 2020 11:34 PM
> To:  
> Subject: [TLS] Proposed change in TLS-Flags
> 
> Hi
> 
> I’ve just submitted the following PR:
> 
> https://github.com/tlswg/tls-flags/pull/4
> 
> Three changes:
> • It is no longer allowed to send an empty flags extension.  If you don’t 
> support any flags, don’t send the extension.
> • The server is no longer allowed to respond with flag types that the client 
> didn’t indicate support for first.
> • I’ve split the extension description section into a format section and a 
> rules section
> 
> Please comment. Barring any objections, I’ll merge the PR just before the 
> submission deadline.
> 
> Yoav
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

[TLS] draft-ietf-tls-ticketrequests-05

[Hannes Tschofenig]

Hi Tommy, Hi David, Hi Chris,

I read through the draft and have a few questions.

1) Is it really necessary for the client to use two values to differentiate the 
tickets it wants with a new session and with resumption. It feels a bit 
over-designed. I would just have one value and that alone would be super useful 
already.

2) This sentence confuses me:
"
   Servers SHOULD NOT send more tickets than requested for the handshake
   type selected by the server (resumption or full handshake).
   Moreover, servers SHOULD place a limit on the number of tickets they
   are willing to send, whether for full handshakes or resumptions, to
   save resources.
"

Shouldn't the sentence say:
"
   Servers SHOULD NOT send more tickets than requested for the handshake
   type (resumption or full handshake) indicated by the client.
"

Even then, I believe the sentence should actually say MUST NOT instead of 
SHOULD NOT. If the client is already taking the effort to indicate that it does 
not want more than a certain number of tickets then it might have a reason. I 
am thinking about the case where the client indicates that it does not want any 
tickets then it would be strange for the server expressing support for the 
extension and still send tickets.

3) Does the server really need to send the number of tickets it is planning to 
send back to the client? In the draft you already indicate that the server may 
send fewer tickets than requested by the client. So, the number expressed by 
the client is an upper limit anyway.

4) I believe it would make sense to define a ticket flag for the case where the 
client does not want to receive any tickets.

5) If a client sends the ClientTicketRequest extension during the full 
handshake is there an expectation that it sends it again in the resumption 
exchange? Would you assume that the server memorizes how many tickets the 
client wanted across the resumption handshakes? For example, in the full 
handshake I use the extension and indicate that I want 5 tickets. I get two 
tickets from the server. Then, I run a resumption handshake without 
transmitting the extension. Is the server expected to remember to still send 3 
more tickets till the quota is exhausted?

6) The topic of when to send the tickets is something you mention in the 
document and it is indeed an issue. Have you thought about allowing the client 
to signal to the server when to send the tickets? Even making a distinction 
between "send me all tickets in a batch" and "send one after the other with 
some reasonable time in between" would be helpful.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] Proposed change in TLS-Flags

[Hannes Tschofenig]

One question: Wouldn’t you want to register a flag for "Post-Handshake Client 
Authentication" in this document?

Ciao
Hannes


From: TLS  On Behalf Of Hannes Tschofenig
Sent: Wednesday, July 1, 2020 5:55 PM
To: Yoav Nir ;  
Subject: Re: [TLS] Proposed change in TLS-Flags

Yoav,

I looked at the draft and the PR. I am fine with the proposed changes.
This is a short and useful draft.

Ciao
Hannes

From: TLS  On Behalf Of Yoav Nir
Sent: Monday, June 29, 2020 11:34 PM
To:  
Subject: [TLS] Proposed change in TLS-Flags

Hi

I’ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:
• It is no longer allowed to send an empty flags extension.  If you don’t 
support any flags, don’t send the extension.
• The server is no longer allowed to respond with flag types that the client 
didn’t indicate support for first.
• I’ve split the extension description section into a format section and a 
rules section

Please comment. Barring any objections, I’ll merge the PR just before the 
submission deadline.

Yoav

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed change in TLS-Flags

[Hannes Tschofenig]

Yoav,

I looked at the draft and the PR. I am fine with the proposed changes.
This is a short and useful draft.

Ciao
Hannes

From: TLS  On Behalf Of Yoav Nir
Sent: Monday, June 29, 2020 11:34 PM
To:  
Subject: [TLS] Proposed change in TLS-Flags

Hi

I’ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:

  *   It is no longer allowed to send an empty flags extension.  If you don’t 
support any flags, don’t send the extension.
  *   The server is no longer allowed to respond with flag types that the 
client didn’t indicate support for first.
  *   I’ve split the extension description section into a format section and a 
rules section

Please comment. Barring any objections, I’ll merge the PR just before the 
submission deadline.

Yoav

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Russ Housley]

This update resolves the comments that I posted on the previous version.  
Thanks.

Russ

 
From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Joseph Salowey
Sent: Monday, June 29, 2020 5:59 PM
To: mailto:tls@ietf.org>> mailto:tls@ietf.org>>
Subject: [TLS] 2nd WGLC for Delegated Credentials for TLS
 
This is the second working group last call for Delegated Credentials for TLS.  
The latest draft can be found here: 
https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 
.  There have been 2 
revisions since the last review.  Draft 8 contains changes that were not 
committed in time for draft 7 and draft 9 contains revisions from the previous 
WGLC.  Links to the Diffs between the draft 9 and draft 7 can be found at the 
end of this message.   Please focus your review on the changes between draft 7 
and draft 9.  Please send your comments to the list by July 13, 2020.  
 
Thanks,
 
Sean and Joe
 
[Inline Diff] 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt
 

[Side-by-side Diff] 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt
 


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

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Hannes Tschofenig]

Hi Joe, Hi draft authors,

I reviewed draft-ietf-tls-subcerts-09 and the document is well written and easy 
to understand.

I have only a minor remark regarding the validity time of the delegated 
credential.

In Section 3 you say
"
   In
   the absence of an application profile standard specifying otherwise,
   the maximum validity period is set to 7 days.  Peers MUST NOT issue
   credentials with a validity period longer than the maximum validity
   period.
"

In Section 4 you say the following about the validity time. "This MUST NOT 
exceed 7 days."

I wonder whether it makes sense to just copy the text from Section 3 to Section 
4 have it read the same way.
Having the flexibility to extend this maximum validity time via profiles may 
turn out to be useful, as Section 3 already states.

The use of a new X.509 extension is unfortunate because tools used for creating 
certificates are somewhat behind supporting various extensions.
We ran into this issue for use with device certificates in IoT deployments.

I guess there is nothing to do about this other than trying to add support of 
this extension in popular tools.
Any plans to add support for this extension to the OpenSSL command line tool to 
create certificates?

Ciao
Hannes

From: TLS  On Behalf Of Joseph Salowey
Sent: Monday, June 29, 2020 5:59 PM
To:  
Subject: [TLS] 2nd WGLC for Delegated Credentials for TLS

This is the second working group last call for Delegated Credentials for TLS.  
The latest draft can be found here: 
https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.  There have been 2 
revisions since the last review.  Draft 8 contains changes that were not 
committed in time for draft 7 and draft 9 contains revisions from the previous 
WGLC.  Links to the Diffs between the draft 9 and draft 7 can be found at the 
end of this message.   Please focus your review on the changes between draft 7 
and draft 9.  Please send your comments to the list by July 13, 2020.

Thanks,

Sean and Joe

[Inline Diff] 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt
[Side-by-side Diff] 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls