Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Achim Kraus]

Hi Tom,

> I think that I cannot make sense of that 'alternately'.  The subsequent
> paragraphs seem to rule it out as an option.  On a first read I thought
> that a zero length CID was a valid option for Application Data and
> wanted to know which form of header and MAC was appropriate but my
> understanding of the later paragraphs became that a zero length CID can
> only appear in Hello; but I do think that this needs fixing.
>
> I did track the WG discussion last October and did not see anything very
> clear then.

That was a discussion in 2019, see
https://github.com/tlswg/dtls-conn-id/issues/43 and follow the refered PRs.

The outcome:
If the CID is empty, RFC6347 record format is used. That's equivalent to
"empty CID is only used in the extensions of the Hellos".

Best regards
Achim Kraus

Am 12.03.21 um 18:28 schrieb tom petch:


On 12/03/2021 16:18, Achim Kraus wrote:

Hi Tom, Hannes, Thomas,

"A zero-length value indicates that the server will send with the
client's CID but does not wish the client to include a CID (or again,
alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that only
to negate the use of tls_cid record. It may be more straight forward, if
the use of a "zero-length CID" is limited to the ClientHello and the
ServerHello extensions. And later the use of a tls_cid record is then
only for negotiated non-empty CID.

WDYT?


I think that I cannot make sense of that 'alternately'.  The subsequent
paragraphs seem to rule it out as an option.  On a first read I thought
that a zero length CID was a valid option for Application Data and
wanted to know which form of header and MAC was appropriate but my
understanding of the later paragraphs became that a zero length CID can
only appear in Hello; but I do think that this needs fixing.

I did track the WG discussion last October and did not see anything very
clear then.

Tom Petch



best regards
Achim Kraus


Am 12.03.21 um 12:58 schrieb Hannes Tschofenig:

Hi Tom,

I added a few PRs to address your review (see
https://github.com/tlswg/dtls-conn-id/pulls).

Regarding the zero-length CID I believe the current version in the
repo at https://github.com/tlswg/dtls-conn-id might have already
address your remark.

In general, the zero-length CID in the ClientHello / ServerHello
allows us to use CIDs unidirectionally.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch ; last-c...@ietf.org
Cc: tls@ietf.org; tls-cha...@ietf.org;
draft-ietf-tls-dtls-connection...@ietf.org
Subject: Re: [TLS] Last Call:
 (Connection Identifiers for
DTLS 1.2) to Proposed Standard

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:


Some editorial quirks

s.2
lacks the boiler plate of RFC8174


https://github.com/tlswg/dtls-conn-id/issues/88


s.3
I found this unclear until I had understood it all (or perhaps I do
not understand it)

"...or again, alternately, to use a zero-length CID)."
This suggests that a zero length CID is valid in Application Data
which later text seems to contradict; otherwise I cannot see what
this is saying.

"  If DTLS peers have negotiated the use of a CIDs using the
ClientHello and the ServerHello messages "
arguably sending a zero CID and receiving a zero CID is a successful
Hello negotiation perhaps " If DTLS peers have negotiated the use of a
non-zero CID in at least one direction, using the ClientHello and the
ServerHello messages"

"The DTLS peers determine whether incoming and outgoing messages
need.."
seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
determine whether incoming or outgoing, or both, messages need.. "


https://github.com/tlswg/dtls-conn-id/issues/89


s.4
/always recieve CIDs/always receive CIDs/


s.5.1
"the with Encrypt-then-MAC processing described in [RFC7366]."
I do not understand why 'with' is needed

s.5.2
ditto

s.8
/this aspects SHOULD refuse/these aspects SHOULD refuse/


https://github.com/tlswg/dtls-conn-id/issues/90


s.10
I would find this clearer as three sections for the three IANA actions
10.1 new column for ExtensionType
10.2 new value for ExtensionType
10.3 new value for ContentType

"   IANA is requested to allocate an entry to the existing TLS
 "ExtensionType Values" registry, defined in [RFC5246],.."
well no; whatever you think of RFC8447 the name has changed
"   IANA is requested to allocate an entry to the existing "TLS
 ExtensionType Values" registry, defined in [RFC5246],.."
or, if you are picky (which I am not),
 IANA is requested to allocate an entry to the existing "TLS
 "ExtensionType Values" registry, defined in [RFC5246], and
 renamed by RFC8447

An extra column is added but I cannot see what value should be placed
in that column for existing entries.

"The tls12_cid ContentType is only 

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Thomas Fossati]

Hi Tom, all,

On 12/03/2021, 17:29, "tom petch"  wrote:
> On 12/03/2021 16:18, Achim Kraus wrote:
> > Hi Tom, Hannes, Thomas,
> >
> > "A zero-length value indicates that the server will send with the
> > client's CID but does not wish the client to include a CID (or
> > again, alternately, to use a zero-length CID)."
> >
> > My feeling is, the text in the paragraphs following that seems to
> > introduce first the idea of a "zero-length CID", and later use that
> > only to negate the use of tls_cid record. It may be more straight
> > forward, if the use of a "zero-length CID" is limited to the
> > ClientHello and the ServerHello extensions. And later the use of a
> > tls_cid record is then only for negotiated non-empty CID.
> >
> > WDYT?
>
> I think that I cannot make sense of that 'alternately'.  The
> subsequent paragraphs seem to rule it out as an option.  On a first
> read I thought that a zero length CID was a valid option for
> Application Data and wanted to know which form of header and MAC was
> appropriate but my understanding of the later paragraphs became that a
> zero length CID can only appear in Hello; but I do think that this
> needs fixing.

Is your suggestion to remove the parenthetical?  I.e.:

OLD
   A zero-length value indicates that the server will send with the
   client's CID but does not wish the client to include a CID (or again,
   alternately, to use a zero-length CID).

NEW
   A zero-length value indicates that the server will send with the
   client's CID but does not wish the client to include a CID.

> I did track the WG discussion last October and did not see anything
> very clear then.
>
> Tom Petch



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] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[tom petch]

On 12/03/2021 16:18, Achim Kraus wrote:

Hi Tom, Hannes, Thomas,

"A zero-length value indicates that the server will send with the
client's CID but does not wish the client to include a CID (or again,
alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that only
to negate the use of tls_cid record. It may be more straight forward, if
the use of a "zero-length CID" is limited to the ClientHello and the
ServerHello extensions. And later the use of a tls_cid record is then
only for negotiated non-empty CID.

WDYT?


I think that I cannot make sense of that 'alternately'.  The subsequent 
paragraphs seem to rule it out as an option.  On a first read I thought 
that a zero length CID was a valid option for Application Data and 
wanted to know which form of header and MAC was appropriate but my 
understanding of the later paragraphs became that a zero length CID can 
only appear in Hello; but I do think that this needs fixing.


I did track the WG discussion last October and did not see anything very 
clear then.


Tom Petch



best regards
Achim Kraus


Am 12.03.21 um 12:58 schrieb Hannes Tschofenig:

Hi Tom,

I added a few PRs to address your review (see
https://github.com/tlswg/dtls-conn-id/pulls).

Regarding the zero-length CID I believe the current version in the
repo at https://github.com/tlswg/dtls-conn-id might have already
address your remark.

In general, the zero-length CID in the ClientHello / ServerHello
allows us to use CIDs unidirectionally.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch ; last-c...@ietf.org
Cc: tls@ietf.org; tls-cha...@ietf.org;
draft-ietf-tls-dtls-connection...@ietf.org
Subject: Re: [TLS] Last Call:
 (Connection Identifiers for
DTLS 1.2) to Proposed Standard

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:


Some editorial quirks

s.2
lacks the boiler plate of RFC8174


https://github.com/tlswg/dtls-conn-id/issues/88


s.3
I found this unclear until I had understood it all (or perhaps I do
not understand it)

"...or again, alternately, to use a zero-length CID)."
This suggests that a zero length CID is valid in Application Data
which later text seems to contradict; otherwise I cannot see what
this is saying.

"  If DTLS peers have negotiated the use of a CIDs using the
ClientHello and the ServerHello messages "
arguably sending a zero CID and receiving a zero CID is a successful
Hello negotiation perhaps " If DTLS peers have negotiated the use of a
non-zero CID in at least one direction, using the ClientHello and the
ServerHello messages"

"The DTLS peers determine whether incoming and outgoing messages need.."
seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
determine whether incoming or outgoing, or both, messages need.. "


https://github.com/tlswg/dtls-conn-id/issues/89


s.4
/always recieve CIDs/always receive CIDs/


s.5.1
"the with Encrypt-then-MAC processing described in [RFC7366]."
I do not understand why 'with' is needed

s.5.2
ditto

s.8
/this aspects SHOULD refuse/these aspects SHOULD refuse/


https://github.com/tlswg/dtls-conn-id/issues/90


s.10
I would find this clearer as three sections for the three IANA actions
10.1 new column for ExtensionType
10.2 new value for ExtensionType
10.3 new value for ContentType

"   IANA is requested to allocate an entry to the existing TLS
 "ExtensionType Values" registry, defined in [RFC5246],.."
well no; whatever you think of RFC8447 the name has changed
"   IANA is requested to allocate an entry to the existing "TLS
 ExtensionType Values" registry, defined in [RFC5246],.."
or, if you are picky (which I am not),
 IANA is requested to allocate an entry to the existing "TLS
 "ExtensionType Values" registry, defined in [RFC5246], and
 renamed by RFC8447

An extra column is added but I cannot see what value should be placed
in that column for existing entries.

"The tls12_cid ContentType is only applicable to DTLS 1.2."
Good information but I struggle to see what IANA will do with it; I
see nowhere for it to go.


https://github.com/tlswg/dtls-conn-id/issues/91


cheers, t


Tom Petch


On 08/03/2021 11:19, The IESG wrote:




The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document: - 'Connection Identifiers
for DTLS 1.2'
 as Proposed Standard

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the last-c...@ietf.org mailing lists by 2021-03-28.
Exceptionally, comments may be sent to i...@ietf.org instead. In
either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract


 This document specifies the Connection ID (CID) construct for the

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Achim Kraus]

Hi Tom, Hannes, Thomas,

"A zero-length value indicates that the server will send with the
client's CID but does not wish the client to include a CID (or again,
alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that only
to negate the use of tls_cid record. It may be more straight forward, if
the use of a "zero-length CID" is limited to the ClientHello and the
ServerHello extensions. And later the use of a tls_cid record is then
only for negotiated non-empty CID.

WDYT?

best regards
Achim Kraus


Am 12.03.21 um 12:58 schrieb Hannes Tschofenig:

Hi Tom,

I added a few PRs to address your review (see 
https://github.com/tlswg/dtls-conn-id/pulls).

Regarding the zero-length CID I believe the current version in the repo at 
https://github.com/tlswg/dtls-conn-id might have already address your remark.

In general, the zero-length CID in the ClientHello / ServerHello allows us to 
use CIDs unidirectionally.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch ; last-c...@ietf.org
Cc: tls@ietf.org; tls-cha...@ietf.org; 
draft-ietf-tls-dtls-connection...@ietf.org
Subject: Re: [TLS] Last Call:  
(Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:


Some editorial quirks

s.2
lacks the boiler plate of RFC8174


https://github.com/tlswg/dtls-conn-id/issues/88


s.3
I found this unclear until I had understood it all (or perhaps I do
not understand it)

"...or again, alternately, to use a zero-length CID)."
This suggests that a zero length CID is valid in Application Data
which later text seems to contradict; otherwise I cannot see what this is 
saying.

"  If DTLS peers have negotiated the use of a CIDs using the
ClientHello and the ServerHello messages "
arguably sending a zero CID and receiving a zero CID is a successful
Hello negotiation perhaps " If DTLS peers have negotiated the use of a
non-zero CID in at least one direction, using the ClientHello and the
ServerHello messages"

"The DTLS peers determine whether incoming and outgoing messages need.."
seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
determine whether incoming or outgoing, or both, messages need.. "


https://github.com/tlswg/dtls-conn-id/issues/89


s.4
/always recieve CIDs/always receive CIDs/


s.5.1
"the with Encrypt-then-MAC processing described in [RFC7366]."
I do not understand why 'with' is needed

s.5.2
ditto

s.8
/this aspects SHOULD refuse/these aspects SHOULD refuse/


https://github.com/tlswg/dtls-conn-id/issues/90


s.10
I would find this clearer as three sections for the three IANA actions
10.1 new column for ExtensionType
10.2 new value for ExtensionType
10.3 new value for ContentType

"   IANA is requested to allocate an entry to the existing TLS
 "ExtensionType Values" registry, defined in [RFC5246],.."
well no; whatever you think of RFC8447 the name has changed
"   IANA is requested to allocate an entry to the existing "TLS
 ExtensionType Values" registry, defined in [RFC5246],.."
or, if you are picky (which I am not),
 IANA is requested to allocate an entry to the existing "TLS
 "ExtensionType Values" registry, defined in [RFC5246], and
 renamed by RFC8447

An extra column is added but I cannot see what value should be placed
in that column for existing entries.

"The tls12_cid ContentType is only applicable to DTLS 1.2."
Good information but I struggle to see what IANA will do with it; I
see nowhere for it to go.


https://github.com/tlswg/dtls-conn-id/issues/91


cheers, t


Tom Petch


On 08/03/2021 11:19, The IESG wrote:




The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document: - 'Connection Identifiers for DTLS 
1.2'
 as Proposed Standard

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the last-c...@ietf.org mailing lists by 2021-03-28.
Exceptionally, comments may be sent to i...@ietf.org instead. In
either case, please retain the beginning of the Subject line to allow automated 
sorting.

Abstract


 This document specifies the Connection ID (CID) construct for the
 Datagram Transport Layer Security (DTLS) protocol version 1.2.

 A CID is an identifier carried in the record layer header that gives
 the recipient additional information for selecting the appropriate
 security association.  In "classical" DTLS, selecting a security
 association of an incoming DTLS record is accomplished with the help
 of the 5-tuple.  If the source IP address and/or source port changes
 during the lifetime of an ongoing DTLS session then the receiver will
 be unable to locate the correct security 

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Hannes Tschofenig]

Hi Tom,

I added a few PRs to address your review (see 
https://github.com/tlswg/dtls-conn-id/pulls).

Regarding the zero-length CID I believe the current version in the repo at 
https://github.com/tlswg/dtls-conn-id might have already address your remark.

In general, the zero-length CID in the ClientHello / ServerHello allows us to 
use CIDs unidirectionally.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch ; last-c...@ietf.org
Cc: tls@ietf.org; tls-cha...@ietf.org; 
draft-ietf-tls-dtls-connection...@ietf.org
Subject: Re: [TLS] Last Call:  
(Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:
>
> Some editorial quirks
>
> s.2
> lacks the boiler plate of RFC8174

https://github.com/tlswg/dtls-conn-id/issues/88

> s.3
> I found this unclear until I had understood it all (or perhaps I do
> not understand it)
>
> "...or again, alternately, to use a zero-length CID)."
> This suggests that a zero length CID is valid in Application Data
> which later text seems to contradict; otherwise I cannot see what this is 
> saying.
>
> "  If DTLS peers have negotiated the use of a CIDs using the
> ClientHello and the ServerHello messages "
> arguably sending a zero CID and receiving a zero CID is a successful
> Hello negotiation perhaps " If DTLS peers have negotiated the use of a
> non-zero CID in at least one direction, using the ClientHello and the
> ServerHello messages"
>
> "The DTLS peers determine whether incoming and outgoing messages need.."
> seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
> determine whether incoming or outgoing, or both, messages need.. "

https://github.com/tlswg/dtls-conn-id/issues/89

> s.4
> /always recieve CIDs/always receive CIDs/
>
>
> s.5.1
> "the with Encrypt-then-MAC processing described in [RFC7366]."
> I do not understand why 'with' is needed
>
> s.5.2
> ditto
>
> s.8
> /this aspects SHOULD refuse/these aspects SHOULD refuse/

https://github.com/tlswg/dtls-conn-id/issues/90

> s.10
> I would find this clearer as three sections for the three IANA actions
> 10.1 new column for ExtensionType
> 10.2 new value for ExtensionType
> 10.3 new value for ContentType
>
> "   IANA is requested to allocate an entry to the existing TLS
> "ExtensionType Values" registry, defined in [RFC5246],.."
> well no; whatever you think of RFC8447 the name has changed
> "   IANA is requested to allocate an entry to the existing "TLS
> ExtensionType Values" registry, defined in [RFC5246],.."
> or, if you are picky (which I am not),
> IANA is requested to allocate an entry to the existing "TLS
> "ExtensionType Values" registry, defined in [RFC5246], and
> renamed by RFC8447
>
> An extra column is added but I cannot see what value should be placed
> in that column for existing entries.
>
> "The tls12_cid ContentType is only applicable to DTLS 1.2."
> Good information but I struggle to see what IANA will do with it; I
> see nowhere for it to go.

https://github.com/tlswg/dtls-conn-id/issues/91


cheers, t

> Tom Petch
>
>
> On 08/03/2021 11:19, The IESG wrote:
>
>
> >
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document: - 'Connection Identifiers for 
> > DTLS 1.2'
> > as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> > solicits final comments on this action. Please send substantive
> > comments to the last-c...@ietf.org mailing lists by 2021-03-28.
> > Exceptionally, comments may be sent to i...@ietf.org instead. In
> > either case, please retain the beginning of the Subject line to allow 
> > automated sorting.
> >
> > Abstract
> >
> >
> > This document specifies the Connection ID (CID) construct for the
> > Datagram Transport Layer Security (DTLS) protocol version 1.2.
> >
> > A CID is an identifier carried in the record layer header that gives
> > the recipient additional information for selecting the appropriate
> > security association.  In "classical" DTLS, selecting a security
> > association of an incoming DTLS record is accomplished with the help
> > of the 5-tuple.  If the source IP address and/or source port changes
> > during the lifetime of an ongoing DTLS session then the receiver will
> > be unable to locate the correct security context.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > ___
> > IETF-Announce mailing list
> > ietf-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential 

Re: [TLS] last call: draft-ietf-kitten-tls-channel-bindings-for-tls13-02

[Jonathan Hoyland]

Hi Watson,

Exporters are a form of channel binding (in the protocol theory sense, not
in the RFC 5056 sense).
Two protocols that use the defined binding on a single TLS connection will
derive the same Exporter.
This is clearly intended to be generic, the input string is
"EXPORTER-Channel-Binding" not something specific to a single protocol, so
presumably more than one thing will use it.

Ideally this wouldn't be defined and anything that would have used this
would just use the Exporter interface directly because, as you say, using
the Exporter interface with different context strings will yield different
values.
However, if this "Channel binding" exporter is defined as described, and is
used by more than one thing, as the name suggests, then it will have all
the same issues as those found by Karthik.

Yes, other things that use the Exporter interface will be unaffected, but
if two things use this binding then they could be vulnerable.

Regards,

Jonathan

On Thu, 11 Mar 2021 at 21:56, Watson Ladd  wrote:

> On Wed, Mar 10, 2021 at 3:57 PM Jonathan Hoyland
>  wrote:
> >
> > IIUC a channel binding (in this context) provides a unique "name" for a
> channel.
> > In the case where two distinct protocols running over the top of TLS use
> this definition, they will both get the same channel binding.
>
> This draft is using exporter instead since channel bindings died an
> ignominious death at the hands of Karthikeyan Bhargavan and his
> students. Because it uses exporters and registers a use in the
> registry, the other exporter values will be distinct.
>
> Exporters are stronger, so I think this is less relevant.
>
> Sincerely,
> Watson Ladd
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Jonathan Hoyland]

I don't believe so, but that would seem like a configuration issue.

I guess if you really wanted you could define an extension that goes in the
Certificate Request message (which the AR is based on), assuming there
isn't one already, that requests a specific serial number.
Although that of course makes the system completely brittle if that
certificate gets revoked, expires, or even just becomes unavailable because
of disk failure.
It would be great to see all the potential use cases broken down so the
best solutions can be considered.

Regards,

Jonathan



On Fri, 12 Mar 2021 at 11:00, Fries, Steffen 
wrote:

> Hi Jonathan,
>
> Maybe a further question to the draft you referenced (exported
> authenticators). Is there a way to request a distinct certificate in the
> AuthenticatorRequest? Can I ask for the certificates used in the initial
> handshake from both sides? I saw in the extension that in the
> ClientCertificateRequest that the server_name may be provided as extension
> but this may not be sufficient.
>
> Best regards
> Steffen
>
> > -Original Message-
> > From: TLS  On Behalf Of Fries, Steffen (T RDA CST)
> > Sent: Donnerstag, 11. März 2021 13:31
> > > One option that I haven't seen mentioned in the thread is
> > https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14.
> > Thank you for the pointer to the draft.
> >
> > > EAs let you send a certificate from either side of the connection at
> any point
> > after the handshake is complete.
> > > I'm not sure what the behaviour is if the certificate itself is
> expired at the time
> > the EA was sent, but valid at the time the connection was established,
> but I'm
> > sure that could be nailed down.
> > > Would something like the client (and equivalently the server)
> requesting an EA
> > every 24 hours and hard failing if it didn't get one meet your needs?
> > It may help here. From an integration standpoint it is important that
> the same
> > certificate would be used with EA as used in the handshake to ensure the
> one
> > used to authenticate in the first place would be verified. That may mean
> that
> > one would have to store the initially used certificate or at least the
> fingerprint or
> > serial number and issuer to be able to request the right one in the
> authenticator
> > request.
> > This would be handled on application layer if I understood it right. As
> the goal
> > would be to have a trigger to verify the certificate against a (new)
> CRL, the
> > approach of having a timer or a trigger by the newly arrived CRL may be
> more
> > suitable. But I will have a closer look.
> >
> > Best regards
> > Steffen
> >
> > > Regards,
> >
> > > Jonathan
> >
> > On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni  ietf-d...@dukhovni.org>
> > wrote:
> > On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote:
> >
> > > > My take is such measures are much too complicated.  Just keep the
> > connection
> > > > lifetime short, and make a new one from time to time.  Also keep
> certificate
> > > > lifetimes short.  Where DNSSEC is an option on both ends, you can
> also use
> > > > DANE TLSA records instead of CRLs, just publish a
> > > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates
> the server's
> > > > public key, and give it a short-enough TTL that it can be replaced
> quickly.
> > > > Presto-magic, no need for OCSP, CRLs, ...
> > >
> > > While this may be a solution in general, it may not fit for power
> systems (like a
> > substation).
> > > The application of DNSSEC or DANE is not very common and may not be
> used.
> > Also due to
> > > Existing deployments, which do not feature these services (yet).
> >
> > I am not trying to suggest that DANE is currently a mainstream option
> > outside of SMTP (primarily in Northern and Central Europe for now, with
> > some signs of life in the USA, Canada and Brazil).  The above was more
> > of an aside for the record.  DANE may be a more realistic choice a few
> > years from now.  DNSSEC adoption is starting to grow faster, and if this
> > continues and accelerates, DANE may become more common, time will tell.
> >
> > Early adopters can of course choose to use it now, but it is far from
> > mainstream today.
> >
> > --
> > Viktor.
> >
> > ___
> > TLS mailing list
> > mailto: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] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Fries, Steffen]

Hi Jonathan,

Maybe a further question to the draft you referenced (exported authenticators). 
Is there a way to request a distinct certificate in the AuthenticatorRequest? 
Can I ask for the certificates used in the initial handshake from both sides? I 
saw in the extension that in the ClientCertificateRequest that the server_name 
may be provided as extension but this may not be sufficient.

Best regards
Steffen

> -Original Message-
> From: TLS  On Behalf Of Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 11. März 2021 13:31
> > One option that I haven't seen mentioned in the thread is
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14.
> Thank you for the pointer to the draft.
> 
> > EAs let you send a certificate from either side of the connection at any 
> > point
> after the handshake is complete.
> > I'm not sure what the behaviour is if the certificate itself is expired at 
> > the time
> the EA was sent, but valid at the time the connection was established, but I'm
> sure that could be nailed down.
> > Would something like the client (and equivalently the server) requesting an 
> > EA
> every 24 hours and hard failing if it didn't get one meet your needs?
> It may help here. From an integration standpoint it is important that the same
> certificate would be used with EA as used in the handshake to ensure the one
> used to authenticate in the first place would be verified. That may mean that
> one would have to store the initially used certificate or at least the 
> fingerprint or
> serial number and issuer to be able to request the right one in the 
> authenticator
> request.
> This would be handled on application layer if I understood it right. As the 
> goal
> would be to have a trigger to verify the certificate against a (new) CRL, the
> approach of having a timer or a trigger by the newly arrived CRL may be more
> suitable. But I will have a closer look.
> 
> Best regards
> Steffen
> 
> > Regards,
> 
> > Jonathan
> 
> On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni 
> wrote:
> On Tue, Mar 09, 2021 at 07:28:26AM +, Fries, Steffen wrote:
> 
> > > My take is such measures are much too complicated.  Just keep the
> connection
> > > lifetime short, and make a new one from time to time.  Also keep 
> > > certificate
> > > lifetimes short.  Where DNSSEC is an option on both ends, you can also use
> > > DANE TLSA records instead of CRLs, just publish a
> > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the 
> > > server's
> > > public key, and give it a short-enough TTL that it can be replaced 
> > > quickly.
> > > Presto-magic, no need for OCSP, CRLs, ...
> >
> > While this may be a solution in general, it may not fit for power systems 
> > (like a
> substation).
> > The application of DNSSEC or DANE is not very common and may not be used.
> Also due to
> > Existing deployments, which do not feature these services (yet).
> 
> I am not trying to suggest that DANE is currently a mainstream option
> outside of SMTP (primarily in Northern and Central Europe for now, with
> some signs of life in the USA, Canada and Brazil).  The above was more
> of an aside for the record.  DANE may be a more realistic choice a few
> years from now.  DNSSEC adoption is starting to grow faster, and if this
> continues and accelerates, DANE may become more common, time will tell.
> 
> Early adopters can of course choose to use it now, but it is far from
> mainstream today.
> 
> --
>     Viktor.
> 
> ___
> TLS mailing list
> mailto: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] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Thomas Fossati]

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:
>
> Some editorial quirks
>
> s.2
> lacks the boiler plate of RFC8174

https://github.com/tlswg/dtls-conn-id/issues/88

> s.3
> I found this unclear until I had understood it all (or perhaps I do not
> understand it)
>
> "...or again, alternately, to use a zero-length CID)."
> This suggests that a zero length CID is valid in Application Data which
> later text seems to contradict; otherwise I cannot see what this is saying.
>
> "  If DTLS peers have negotiated the use of a CIDs using the ClientHello
> and the ServerHello messages "
> arguably sending a zero CID and receiving a zero CID is a successful
> Hello negotiation perhaps
> " If DTLS peers have negotiated the use of a non-zero CID in at least
> one direction, using the ClientHello and the ServerHello messages"
>
> "The DTLS peers determine whether incoming and outgoing messages need.."
> seems not to cater for unidirectional CIDs; perhaps
> "The DTLS peers determine whether incoming or outgoing, or both,
> messages need.. "

https://github.com/tlswg/dtls-conn-id/issues/89

> s.4
> /always recieve CIDs/always receive CIDs/
>
>
> s.5.1
> "the with Encrypt-then-MAC processing described in [RFC7366]."
> I do not understand why 'with' is needed
>
> s.5.2
> ditto
>
> s.8
> /this aspects SHOULD refuse/these aspects SHOULD refuse/

https://github.com/tlswg/dtls-conn-id/issues/90

> s.10
> I would find this clearer as three sections for the three IANA actions
> 10.1 new column for ExtensionType
> 10.2 new value for ExtensionType
> 10.3 new value for ContentType
>
> "   IANA is requested to allocate an entry to the existing TLS
> "ExtensionType Values" registry, defined in [RFC5246],.."
> well no; whatever you think of RFC8447 the name has changed
> "   IANA is requested to allocate an entry to the existing "TLS
> ExtensionType Values" registry, defined in [RFC5246],.."
> or, if you are picky (which I am not),
> IANA is requested to allocate an entry to the existing "TLS
> "ExtensionType Values" registry, defined in [RFC5246], and
> renamed by RFC8447
>
> An extra column is added but I cannot see what value should be placed in
> that column for existing entries.
>
> "The tls12_cid ContentType is only applicable to DTLS 1.2."
> Good information but I struggle to see what IANA will do with it; I see
> nowhere for it to go.

https://github.com/tlswg/dtls-conn-id/issues/91


cheers, t

> Tom Petch
>
>
> On 08/03/2021 11:19, The IESG wrote:
>
>
> >
> > The IESG has received a request from the Transport Layer Security WG (tls) 
> > to
> > consider the following document: - 'Connection Identifiers for DTLS 1.2'
> > as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may
> > be sent to i...@ietf.org instead. In either case, please retain the 
> > beginning
> > of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > This document specifies the Connection ID (CID) construct for the
> > Datagram Transport Layer Security (DTLS) protocol version 1.2.
> >
> > A CID is an identifier carried in the record layer header that gives
> > the recipient additional information for selecting the appropriate
> > security association.  In "classical" DTLS, selecting a security
> > association of an incoming DTLS record is accomplished with the help
> > of the 5-tuple.  If the source IP address and/or source port changes
> > during the lifetime of an ongoing DTLS session then the receiver will
> > be unable to locate the correct security context.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > ___
> > IETF-Announce mailing list
> > ietf-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >
>

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] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[tom petch]

Some editorial quirks

s.2
lacks the boiler plate of RFC8174

s.3
I found this unclear until I had understood it all (or perhaps I do not 
understand it)


"...or again, alternately, to use a zero-length CID)."
This suggests that a zero length CID is valid in Application Data which 
later text seems to contradict; otherwise I cannot see what this is saying.


"  If DTLS peers have negotiated the use of a CIDs using the ClientHello 
and the ServerHello messages "
arguably sending a zero CID and receiving a zero CID is a successful 
Hello negotiation perhaps
" If DTLS peers have negotiated the use of a non-zero CID in at least 
one direction, using the ClientHello and the ServerHello messages"


"The DTLS peers determine whether incoming and outgoing messages need.."
seems not to cater for unidirectional CIDs; perhaps
"The DTLS peers determine whether incoming or outgoing, or both, 
messages need.. "


s.4
/always recieve CIDs/always receive CIDs/


s.5.1
"the with Encrypt-then-MAC processing described in [RFC7366]."
I do not understand why 'with' is needed

s.5.2
ditto

s.8
/this aspects SHOULD refuse/these aspects SHOULD refuse/

s.10
I would find this clearer as three sections for the three IANA actions
10.1 new column for ExtensionType
10.2 new value for ExtensionType
10.3 new value for ContentType

"   IANA is requested to allocate an entry to the existing TLS
   "ExtensionType Values" registry, defined in [RFC5246],.."
well no; whatever you think of RFC8447 the name has changed
"   IANA is requested to allocate an entry to the existing "TLS
   ExtensionType Values" registry, defined in [RFC5246],.."
or, if you are picky (which I am not),
   IANA is requested to allocate an entry to the existing "TLS
   "ExtensionType Values" registry, defined in [RFC5246], and
   renamed by RFC8447

An extra column is added but I cannot see what value should be placed in 
that column for existing entries.


"The tls12_cid ContentType is only applicable to DTLS 1.2."
Good information but I struggle to see what IANA will do with it; I see 
nowhere for it to go.


Tom Petch


On 08/03/2021 11:19, The IESG wrote:




The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Connection Identifiers for DTLS 1.2'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


This document specifies the Connection ID (CID) construct for the
Datagram Transport Layer Security (DTLS) protocol version 1.2.

A CID is an identifier carried in the record layer header that gives
the recipient additional information for selecting the appropriate
security association.  In "classical" DTLS, selecting a security
association of an incoming DTLS record is accomplished with the help
of the 5-tuple.  If the source IP address and/or source port changes
during the lifetime of an ongoing DTLS session then the receiver will
be unable to locate the correct security context.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



No IPR declarations have been submitted directly on this I-D.





___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
.



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