Re: [TLS] [DTLS] ACK's for post-handshake authentication requests

[Hanno Becker]

Thanks Ekr. I have created PR https://github.com/tlswg/dtls13-spec/pull/138 
implementing the suggestion.

From: Eric Rescorla 
Sent: Friday, March 27, 2020 4:30 PM
To: Hanno Becker 
Cc: tls@ietf.org 
Subject: Re: [TLS] [DTLS] ACK's for post-handshake authentication requests

Thanks. This seems like a good improvement. I have filed 
https://github.com/tlswg/dtls13-spec/issues/128 to track it.

On Fri, Mar 27, 2020 at 8:29 AM Hanno Becker 
mailto:hanno.bec...@arm.com>> wrote:
I have a minor comment on DTLS 1.3 draft 37.

On the topic of sending ACKs, the draft recommends:

```
ACKs SHOULD NOT be sent for other complete
flights because they are implicitly acknowledged by the receipt of
the next flight, which generally immediately follows the flight.
```

I wonder if the case of post-handshake authentication should be
explicitly mentioned as a potential exception to this rule, since
the TLS 1.3 RFC explicitly mentions that responses to
`CertificateRequest` may be delayed in some contexts:

```
Note: Because client authentication could involve prompting the user,
servers MUST be prepared for some delay, including receiving an
arbitrary number of other messages between sending the
CertificateRequest and receiving a response.
```

In this case, it would be beneficial to immediately explicitly ACK
the `CertificateRequest` message even though it is also implicitly
acked through the eventual response via the `Certificate` message.

Regards,
Hanno
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
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] Gaps in specification of DTLS 1.3 state machine

[Hanno Becker]

Hi Ekr, Martin, Chris,

I have created https://github.com/tlswg/dtls13-spec/pull/137 as a first attempt 
to explicitly mention
that multiple post-handshake messages should be treated via independent state 
machines.

Let me know what you think.

From: TLS  on behalf of Hanno Becker 

Sent: Wednesday, March 11, 2020 2:36 PM
To: Christopher Wood ; tls@ietf.org 
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine

Thanks Eric, Martin and Chris for your input!

For the record: I withdraw my claim that there's an issue with handshake 
message reordering
and the transcript, as already pointed out by Eric and Chris. I also don't see 
any other issues
at the moment with what appears to be the preferred model of duplicated state 
machines
that would require technical changes to the specification.

However, I do believe that the duplication of state machines is non-trivial 
enough to merit
explicit mentioning in the specification. In particular, if I understand things 
correctly, it appears
that it increases the implicit interface between the handshake logic 'layer' 
(which should be
as similar to that for TLS 1.3 implementations as possible) and the underlying 
'messaging' layer,
including the retransmission state machine: For example, the retransmission 
state machine cannot
infer which handshake message belongs to which state machine on its own on the 
basis of handshake
metadata. Instead, this information needs to be provided by the handshake logic 
after inspecting the
message content. As a concrete example, one can consider multiple 
CertificateRequest messages
being sent from Server to Client. When the Client responds to one of them, it 
is only on parsing
of the certificate request context that it becomes clear which state machine 
the message belongs to.
Hence, in a nutshell, while for the main handshake the signaling between 
handshake logic layer
and messaging layer is confined to indicating when a flight or handshake is 
over, the duplication
of state machines seems to add complexity by requiring to add a signal 
indicating which state
machine an incoming message belongs to. Similarly, when sending messages, it 
needs to be
indicated which state machine they belong to.

Overall, I believe that it would be beneficial if the abstract model for the 
retransmission state
machine - including the state machine duplication for post-handshake messages - 
received
some more attention and (potentially formal) analysis.

Cheers,
Hanno

From: TLS  on behalf of Christopher Wood 

Sent: Wednesday, March 11, 2020 1:37 PM
To: TLS@ietf.org 
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine

Thanks for raising this issue and for the discussion, folks!

Given that endpoints *process* handshake messages in sequence, thereby 
preventing any out-of-order processing issues raised earlier on this thread, 
the chairs think no further action is needed to address this comment.

Thanks,
Chris, on behalf of the chairs

On Thu, Mar 5, 2020, at 6:45 AM, Eric Rescorla wrote:
> Hanno,
>
> I do think you are overcomplicating things somewhat.
>
> You can't process handshake messages out of sequence even if they are
> received out of sequence (this is, of course, also the case in TLS,
> it's just that the resequencing happens at the TCP layer).. You have to
> either drop out of order messages or buffer them. Yes, this is
> somewhat irritating, but as you demonstrate below, it's inherent
> in the design of post-handshake messages even if each side is
> only allowed to initiate one transaction at a time.
>
> It might be useful to explain this in the text, but I don't think
> anything else is needed..
>
> -Ekr
>
> On Wed, Mar 4, 2020 at 11:00 PM Hanno Becker  wrote:
> > Thanks Martin for your thoughts.
> >
> > > It's unavoidable in any case. If you generate your own post-handshake 
> > > message and
> > > then have to respond to post-handshake authentication, there will be two 
> > > concurrent
> > > exchanges.
> >
> > Yes that's an instance of the second question b) which the post didn't 
> > further go into.
> >
> > I'm not yet convinced that this situation unavoidably creates the need for 
> > duplicating state machines, though, and think that if possible we should 
> > avoid it for the sake of implementation simplicity.
> >
> > Moreover, even if it is acceptable that state machines should be 
> > duplicated, it isn't clear (to me) how to logically separate them because 
> > they're all tied together by the use of the same global handshake sequence 
> > number. This creates non-trivial ambiguities like the following:
> >
> > Imagine after the handshake the server requests post-handshake 
> > authentication while, simultaneously, the client initiates a key update. 
> > When the server receives the KeyUpdate, it assumes from the handshake 
> > sequence number that it is the reply to his CertificateRequest, and only 
> > when inspecting the type of

Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

[Hanno Becker]

Hi Jonathan,

I have created https://github.com/tlswg/dtls13-spec/pull/139/ as an attempt to 
clarify
the distinction between when to ACK and what to ACK.

Let me know what you think.

Best,
Hanno

From: Jonathan Hammell 
Sent: Monday, March 30, 2020 2:54 PM
To: Hanno Becker 
Cc: Sean Turner ; TLS List 
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

Hi Hanno,

Thank you for your clarifications.  The example you gave helps a lot.
I believe I now understand the text as written in this bullet (first
bullet, not second--my bad).  I no longer think it needs re-wording.

Best regards,
Jonathan

On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker  wrote:
>
> Hi Jonathan,
>
> > In Section 7.1, the 2nd bullet following para 1 reads: "When they
> > receive a message or fragment which is out of order, either because it
> > is not the next expected message or because it is not the next piece
> > of the current message. Implementations MUST NOT send ACKs for
> > handshake messages which they discard as
> > out-of-order, because otherwise those messages will not be retransmitted."
> > This is confusing as the difference between "out of order" messages
> > that require an ACK and those that do not is not quite clear. Also the
> > term "out of order" is written in two ways in this paragraph.
>
> On second read, I agree that this is confusing. The point is that
> while, to my understanding, out-of-order messages should trigger
> the transmission of an ACK acknowledging what has been processed
> so far, the out-of-order messages themselves must not be included
> in those ACKs unless they have been buffered.
>
> In more detail, there are two kinds of feedback signals from the
> handshake layer to the record layer:
>
> 1. Signal whether there is some disruption in the incoming flight
>which the peer should be informed about via an ACK of those
>messages received and processed so far.
>
>That's what the first sentence in the above quote is about.
>
> 2. Signal whether a handshake message has been processed.
>
>That's what the second sentence in the above quote is about,
>which can also be rephased as follows:
>An ACK must only be sent for those records which consist of
>handshake messages each of which has been signalled as
>processed by the handshake layer.
>
>In particular, in situations where a single record contains
>multiple handshake messages/fragments, and the implementation
>processes only some of them, the record must not be acknowledged.
>A real-world example for this would be an implementation which
>supports out-of-order buffering but only contiguous reassembly:
>If the initial fragment of a HS message gets sent in one record
>which is lost, and the final fragment together with a subsequent
>handshake message is sent in another record, then this latter
>record must not be ACKed if the stack drops the fragment.
>
> Unbuffered out-of-order handshake messages do trigger signal 1,
> but they don't trigger signal 2.
>
> At least, that's my understanding.
>
> Best,
> Hanno
> 
> From: TLS  on behalf of Jonathan Hammell 
> 
> Sent: Friday, March 27, 2020 5:10 PM
> To: Sean Turner 
> Cc: TLS List 
> Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
>
> I know that this WGLC was supposed to focus on the diff between -34
> and -37.  I don't have any comments on that diff, but I do have some
> comments on the draft following a re-read of the entire document.
>
> # Minor
>
> The term "deprotection" is used twice in document but never defined.
>
> Section 5.11 abandoning vs destroying association.  In the document we
> see the term "abandon" being used, referring to associations. However
> section 5.11 states that a server "MUST NOT destroy the existing
> association" and then further along it states that "the server MUST
> abandon the previous association". Do abandon and destroy mean the
> same thing?
>
> In Section 7, what does "handshake-containing" mean in the phrase "The
> ACK message is used by an endpoint to indicate
> handshake-containing..."?
>
> In Section 7, what does "non-duplicative" mean in phrase
> "Implementations MUST NOT acknowledge records containing
> non-duplicative handshake messages..."?
>
> In Section 7.1, the 2nd bullet following para 1 reads: "When they
> receive a message or fragment which is out of order, either because it
> is not the next expected message or because it is not the next piece
> of the current message. Implementations MUST NOT send ACKs for
> handshake messages which they discard as
> out-of-order, because otherwise those messages will not be retransmitted."
> This is confusing as the difference between "out of order" messages
> that require an ACK and those that do not is not quite clear. Also the
> term "out of order" is written in two ways in this paragraph.
>
> In Figure 10, the edge going from SENDING to FINISHED has no label to
> differentiate

Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

[Jonathan Hammell]

Hi Hanno,

This is much clearer to me.  I see that you have removed the sentence
I was having a problem with in the bullet: "Implementations MUST NOT
send ACKs for handshake messages which they discard as out-of-order,
because otherwise those messages will not be retransmitted";
logically, I believe you have captured this better by adding "and
processed" above in "The ACK message is used by an endpoint to
indicate which handshake records it has received and processed from
the other side."

Best regards,
Jonathan

On Thu, Apr 2, 2020 at 2:03 PM Hanno Becker  wrote:
>
> Hi Jonathan,
>
> I have created https://github.com/tlswg/dtls13-spec/pull/139/ as an attempt 
> to clarify
> the distinction between when to ACK and what to ACK.
>
> Let me know what you think.
>
> Best,
> Hanno
> 
> From: Jonathan Hammell 
> Sent: Monday, March 30, 2020 2:54 PM
> To: Hanno Becker 
> Cc: Sean Turner ; TLS List 
> Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
>
> Hi Hanno,
>
> Thank you for your clarifications.  The example you gave helps a lot.
> I believe I now understand the text as written in this bullet (first
> bullet, not second--my bad).  I no longer think it needs re-wording.
>
> Best regards,
> Jonathan
>
> On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker  wrote:
> >
> > Hi Jonathan,
> >
> > > In Section 7.1, the 2nd bullet following para 1 reads: "When they
> > > receive a message or fragment which is out of order, either because it
> > > is not the next expected message or because it is not the next piece
> > > of the current message. Implementations MUST NOT send ACKs for
> > > handshake messages which they discard as
> > > out-of-order, because otherwise those messages will not be retransmitted."
> > > This is confusing as the difference between "out of order" messages
> > > that require an ACK and those that do not is not quite clear. Also the
> > > term "out of order" is written in two ways in this paragraph.
> >
> > On second read, I agree that this is confusing. The point is that
> > while, to my understanding, out-of-order messages should trigger
> > the transmission of an ACK acknowledging what has been processed
> > so far, the out-of-order messages themselves must not be included
> > in those ACKs unless they have been buffered.
> >
> > In more detail, there are two kinds of feedback signals from the
> > handshake layer to the record layer:
> >
> > 1. Signal whether there is some disruption in the incoming flight
> >which the peer should be informed about via an ACK of those
> >messages received and processed so far.
> >
> >That's what the first sentence in the above quote is about.
> >
> > 2. Signal whether a handshake message has been processed.
> >
> >That's what the second sentence in the above quote is about,
> >which can also be rephased as follows:
> >An ACK must only be sent for those records which consist of
> >handshake messages each of which has been signalled as
> >processed by the handshake layer.
> >
> >In particular, in situations where a single record contains
> >multiple handshake messages/fragments, and the implementation
> >processes only some of them, the record must not be acknowledged.
> >A real-world example for this would be an implementation which
> >supports out-of-order buffering but only contiguous reassembly:
> >If the initial fragment of a HS message gets sent in one record
> >which is lost, and the final fragment together with a subsequent
> >handshake message is sent in another record, then this latter
> >record must not be ACKed if the stack drops the fragment.
> >
> > Unbuffered out-of-order handshake messages do trigger signal 1,
> > but they don't trigger signal 2.
> >
> > At least, that's my understanding.
> >
> > Best,
> > Hanno
> > 
> > From: TLS  on behalf of Jonathan Hammell 
> > 
> > Sent: Friday, March 27, 2020 5:10 PM
> > To: Sean Turner 
> > Cc: TLS List 
> > Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
> >
> > I know that this WGLC was supposed to focus on the diff between -34
> > and -37.  I don't have any comments on that diff, but I do have some
> > comments on the draft following a re-read of the entire document.
> >
> > # Minor
> >
> > The term "deprotection" is used twice in document but never defined.
> >
> > Section 5.11 abandoning vs destroying association.  In the document we
> > see the term "abandon" being used, referring to associations. However
> > section 5.11 states that a server "MUST NOT destroy the existing
> > association" and then further along it states that "the server MUST
> > abandon the previous association". Do abandon and destroy mean the
> > same thing?
> >
> > In Section 7, what does "handshake-containing" mean in the phrase "The
> > ACK message is used by an endpoint to indicate
> > handshake-containing..."?
> >
> > In Section 7, what does "non-duplicative" mean in phrase
> > "Implement

[TLS] Review of draft-ietf-tls-subcerts-07

[Jonathan Hammell]

The draft looks good.  I have a few minor nits and suggestions.

Section 3, Fourth bullet: s/TLS hadshake/TLS handshake

Section 3, Fourth bullet: To eliminate possible confusion, what is
meant by "certificate’s working key" could be defined more precisely.

Section 3.2, Last paragraph: s/Automated Certificate Managmeent
Encvironment/Automated Certificate Management Environment

Section 3.2, Last paragraph: "It is possible to address the
short-lived certificate concerns above ..." seems to refer to text in
the Introduction.  It is a bit far for use of "above" rather than
indicating the particular section.  Even better would be to add some
text regarding the concerns to Section 3 or 3.1.

Section 4: The definition of "valid_time" could mention that the value
must not exceed 7 days.

Section 4: The phrase
"Minimizing their semantics in this way is intended to mitigate the
risk of cross protocol attacks involving delegated credentials."
could be improved by adding at least one way that the minimized
semantics mitigate such attacks.

Section 6.1: The term "TLS private key" is used for the first time
here. In the rest of the document we see the term "delegated private
key"; are these the same?

Section 6.1: The following phrase describes an important condition for
using delegated credentials:
"Thus, delegated credentials should not be used to send a delegation
to an untrusted party, but is meant to be used between parties that
have some trust relationship with each other."
I think it is important enough to include a similar statement when
describing the solution in Section 3.

Section 6.4: s/cache the certificate chain an re-validate it/cache the
certificate chain and re-validate it


Best regards,
Jonathan

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