Re: [TLS] DTLS RRC and heartbeat

[Thomas Fossati]

Rich, Hanno, Mohit,

Thanks a lot for your excellent input.  We are going to follow your
advice and avoid overloading heartbeat then.

Scope-wise, RRC will focus on path validation and liveliness use cases,
leaving PMTU discovery out, at least for the moment.

cheers,

On Thu, Oct 21, 2021 at 4:45 PM Salz, Rich  wrote:

> >And we are not sure, if considering mainly implementation issues, will
> justify to allocate a new code-point.
>
> As one of the three TLS registry experts, let me tell you not to be
> worried about requesting a new codepoint.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


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

[TLS] I-D Action: draft-ietf-tls-dtls-rrc-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Return Routability Check for DTLS 1.2 and DTLS 1.3
Authors : Hannes Tschofenig
  Thomas Fossati
Filename: draft-ietf-tls-dtls-rrc-01.txt
Pages   : 10
Date: 2021-10-25

Abstract:
   This document specifies a return routability check for use in context
   of the Connection ID (CID) construct for the Datagram Transport Layer
   Security (DTLS) protocol versions 1.2 and 1.3.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Transport Layer
   Security Working Group mailing list (tls@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/tls/.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/dtls-rrc.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-rrc-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[TLS] I-D Action: draft-ietf-tls-ctls-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Compact TLS 1.3
Authors : Eric Rescorla
  Richard Barnes
  Hannes Tschofenig
Filename: draft-ietf-tls-ctls-04.txt
Pages   : 17
Date: 2021-10-25

Abstract:
   This document specifies a "compact" version of TLS 1.3.  It is
   isomorphic to TLS 1.3 but saves space by trimming obsolete material,
   tighter encoding, a template-based specialization technique, and
   alternative cryptographic techniques. cTLS is not directly
   interoperable with TLS 1.3, but it should eventually be possible for
   a cTLS/TLS 1.3 server to exist and successfully interoperate.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-ctls-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ctls-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

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] TLS Flags and IANA registration policy

[Hannes Tschofenig]

Hi Ilari,

> "If an item is not marked as 'Recommended', it does not necessarily mean that 
> it is flawed; rather, it indicates that the item either has not been through 
> the IETF consensus process, has limited applicability, or is intended only 
> for specific use cases."

I think the flags draft should state that (if that's how it should be 
interpreted).

FWIW I looked through the current list of extensions and their Y/N assignment 
for "recommended". The assignment appears random. This is not surprising that 
extensions are, by their nature, related to specific use cases and therefore 
have a certain applicability only.

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] TLS Flags and IANA registration policy

[Ilari Liusvaara]

On Mon, Oct 25, 2021 at 05:13:07PM +, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> > "If an item is not marked as 'Recommended', it does not necessarily
> > mean that it is flawed; rather, it indicates that the item either
> > has not been through the IETF consensus process, has limited
> > applicability, or is intended only for specific use cases."
> 
> I think the flags draft should state that (if that's how it should be 
> interpreted).
> 
> FWIW I looked through the current list of extensions and their Y/N
> assignment for "recommended". The assignment appears random. This is
> not surprising that extensions are, by their nature, related to
> specific use cases and therefore have a certain applicability only.

Yeah, the assignments are pretty strange, here are some recommended
ones I think are odd:

- trusted_ca_keys: Wasn't that supposed to be deprecated?
- client_certificate_url: No replacment in TLS 1.3, security issues.
- user_mapping: No replacement in TLS 1.3, who uses this?
- ec_point_formats: No replacement in TLS 1.3, who uses this?
- heartbeat: The most infamous extension of them all.
- token_binding: No replacement in TLS 1.3.
- status_request_v2: Who uses this (at least TLS 1.3 has a replacement)?
- session_ticket: Nasty security issues (destroys forward secrecy of
  any connection it is used on).
- transparency_info: Similar to signed_certificate_timestamp, which is
  not recommended.

On the reverse side, not recommended extensions, there does not seem
to be any really strange ones (I presume some are due to procedural
matters, and will be changed to recommended later).

I dinged extensions for not working and not having replacment in TLS 1.3,
as one would think that all the common stuff would have replacements.


Then on stuff other than extensions, there are some other odd ones:

- ciphers TLS_DHE_RSA_WITH_*: Negotiation is flawed.
- ciphers TLS_DHE_PSK_WITH_*: Who uses this?
- exporter label "client finished": Actually reserved.
- exporter label "server finished": Actually reserved.
- exporter label "master secret": Actually reserved.
- exporter label "key expansion": Actually reserved.
- exporter labels: Why is there recommended column at all?


-Ilari

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

Re: [TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review

[Nick Sullivan]

The text in the PR has been updated to incorporate Sean and Rich's
suggestions. If there are no more comments I'll merge and close at the end
of the week.

Nick

On Fri, Oct 22, 2021 at 10:05 AM Salz, Rich  wrote:

> Made an editorial suggestion at
> https://github.com/tlswg/tls-exported-authenticator/pull/74#discussion_r734572153
> but either way this seems like a good plan.
>
>
> ___
> 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] I-D Action: draft-ietf-tls-tlsflags-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : A Flags Extension for TLS 1.3
Author  : Yoav Nir
Filename: draft-ietf-tls-tlsflags-07.txt
Pages   : 9
Date: 2021-10-25

Abstract:
   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tlsflags-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[TLS] Spec issue with RFC 7627 (EMS) and resumption

[David Benjamin]

Hi all,

In diagnosing an interop issue, I noticed RFC 7627 did not describe the
correct server behavior for EMS very well. Seemingly as a result, some
server implementation has gotten this wrong. I'd like to fix this in the
spec so this doesn't happen again. I think, at minimum, we need to replace
the last paragraph of section 5.4.

The issue is a server that *doesn't* implement EMS, when presented a
ClientHello containing a ticket or session ID by a server that *did* implement
EMS, must ignore the session and continue with a full handshake. Failing to
do so will trip the client check in Section 5.3, "If a client receives a
ServerHello that accepts an abbreviated handshake, [...]". This is
important to meet these three properties:

- If the client and server both support EMS, the connection must negotiate
it.
- On resumption, the EMS status of the connection must match the EMS status
of the session
- In order for EMS to be safely deployable, it must be possible to roll EMS
out gradually, or roll it back, without breaking connections. This means a
mixed pre-EMS and post-EMS server deployment must work.

Note that, although this behavior is only visible at the pre-EMS server
(not directly in scope for this document), it is actually a requirement on
the post-EMS server. When the post-EMS server issues a session, it must
arrange for the pre-EMS server to ignore it. For example, if the pre-EMS
server rejects sessions with unparsable fields (the safest option), the
post-EMS server can add a new field to the session state serialization.
Failing that, it can bump some internal version number. Another strategy is
to rotate session ticket keys alongside the version, but this can be tricky
the way deployments and software updates are often split.

There's an analogous, though less likely, client scenario that a pre-EMS
client must not offer a post-EMS session. Otherwise it will run afoul of a
server requirement. This can be relevant for clients that serialize their
session cache.

As far as I can tell, RFC 7627 does not specify any of this. The first
paragraph of section 5.4 talks about adding a flag, but doesn't talk about
how pre-EMS servers interact with that flag. The last paragraph discusses
this scenario, but says something very strange, if not plain wrong:

   If the original session uses an extended master secret but the
   ClientHello or ServerHello in the abbreviated handshake does not
   include the extension, it MAY be safe to continue the abbreviated
   handshake since it is protected by the extended master secret of the
   original session.  This scenario may occur, for example, when a
   server that implements this extension establishes a session but the
   session is subsequently resumed at a different server that does not
   support the extension.  Since such situations are unusual and likely
   to be the result of transient or inadvertent misconfigurations, this
   document recommends that the client and server MUST abort such
   handshakes.

https://datatracker.ietf.org/doc/html/rfc7627#section-5.4

First, the "MAY" is immediately contradicted by the following "MUST", and
by section 5.3. It seems it should have been an English lowercase "may",
not a normative RFC 2119 "MAY". It is also wrong in calling this situation
"unusual and likely to be the result of transient or inadvertent
misconfigurations". Rather, it is the natural transition state of any large
server rollout. I think we need to delete that entire paragraph and replace
it with text that describes the rules above. If we were doing a whole new
version of the document, I think the text could do with reorganization. But
that may not be worth doing, given folks should be using TLS 1.3 now.

Thoughts? I can put together some replacement text if folks agree. What
would be the best way to do this? Just an erratum?

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

[TLS] I-D Action: draft-ietf-tls-rfc8446bis-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : The Transport Layer Security (TLS) Protocol Version 
1.3
Author  : Eric Rescorla
Filename: draft-ietf-tls-rfc8446bis-03.txt
Pages   : 154
Date: 2021-10-25

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

   This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077,
   5246, and 6961.  This document also specifies new requirements for
   TLS 1.2 implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8446bis-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[David Benjamin]

Here's some possible replacement text for that paragraph:

"""
In some deployments, a legacy client or server may be exposed to a session
using extended master secret. For example, a group of servers sharing a
ticket encryption key may be in the process of enabling this extension. If
such a session is used in an abbreviated handshake without the extension, a
newer peer will fail the connection, as described in Section 5.3. To avoid
this, legacy servers SHOULD ignore such sessions and continue with a full
handshake, and legacy clients SHOULD NOT offer such sessions in the
ClientHello.

This can be implemented by ensuring legacy implementations do not recognize
sessions using extended master secret. For example, the sessions may have a
higher internal version number or, if the older implementation rejects
unrecognized fields, include a new field. If this is not possible,
deployments may deploy a new session cache or ticket encryption key
alongside the new version.
"""

Unfortunately, "session using extended master secret" is a bit of a
mouthful, but section 5.4 didn't define a more concise term.

On Mon, Oct 25, 2021 at 4:01 PM David Benjamin 
wrote:

> Hi all,
>
> In diagnosing an interop issue, I noticed RFC 7627 did not describe the
> correct server behavior for EMS very well. Seemingly as a result, some
> server implementation has gotten this wrong. I'd like to fix this in the
> spec so this doesn't happen again. I think, at minimum, we need to replace
> the last paragraph of section 5.4.
>
> The issue is a server that *doesn't* implement EMS, when presented a
> ClientHello containing a ticket or session ID by a server that *did* implement
> EMS, must ignore the session and continue with a full handshake. Failing to
> do so will trip the client check in Section 5.3, "If a client receives a
> ServerHello that accepts an abbreviated handshake, [...]". This is
> important to meet these three properties:
>
> - If the client and server both support EMS, the connection must negotiate
> it.
> - On resumption, the EMS status of the connection must match the EMS
> status of the session
> - In order for EMS to be safely deployable, it must be possible to roll
> EMS out gradually, or roll it back, without breaking connections. This
> means a mixed pre-EMS and post-EMS server deployment must work.
>
> Note that, although this behavior is only visible at the pre-EMS server
> (not directly in scope for this document), it is actually a requirement on
> the post-EMS server. When the post-EMS server issues a session, it must
> arrange for the pre-EMS server to ignore it. For example, if the pre-EMS
> server rejects sessions with unparsable fields (the safest option), the
> post-EMS server can add a new field to the session state serialization.
> Failing that, it can bump some internal version number. Another strategy is
> to rotate session ticket keys alongside the version, but this can be tricky
> the way deployments and software updates are often split.
>
> There's an analogous, though less likely, client scenario that a pre-EMS
> client must not offer a post-EMS session. Otherwise it will run afoul of a
> server requirement. This can be relevant for clients that serialize their
> session cache.
>
> As far as I can tell, RFC 7627 does not specify any of this. The first
> paragraph of section 5.4 talks about adding a flag, but doesn't talk about
> how pre-EMS servers interact with that flag. The last paragraph discusses
> this scenario, but says something very strange, if not plain wrong:
>
>If the original session uses an extended master secret but the
>ClientHello or ServerHello in the abbreviated handshake does not
>include the extension, it MAY be safe to continue the abbreviated
>handshake since it is protected by the extended master secret of the
>original session.  This scenario may occur, for example, when a
>server that implements this extension establishes a session but the
>session is subsequently resumed at a different server that does not
>support the extension.  Since such situations are unusual and likely
>to be the result of transient or inadvertent misconfigurations, this
>document recommends that the client and server MUST abort such
>handshakes.
>
> https://datatracker.ietf.org/doc/html/rfc7627#section-5.4
>
> First, the "MAY" is immediately contradicted by the following "MUST", and
> by section 5.3. It seems it should have been an English lowercase "may",
> not a normative RFC 2119 "MAY". It is also wrong in calling this situation
> "unusual and likely to be the result of transient or inadvertent
> misconfigurations". Rather, it is the natural transition state of any large
> server rollout. I think we need to delete that entire paragraph and replace
> it with text that describes the rules above. If we were doing a whole new
> version of the document, I think the text could do with reorganization. But
> that may not be worth doing, given folks should be usin

Re: [TLS] Point Compression

[Carl Mehner]

I uploaded a draft for the IANA assignments for compressed code points for
the NIST curves:
https://datatracker.ietf.org/doc/draft-cem-compressed-curves/
In it, I elected to not pursue the format to encode the types of keys
specified in draft-jivsov-ecc-compact
, mostly
because the support for 'regular' (SEC1) compressed curves is more
widespread. However, I'm not against using the method described by Andrey
if we want to shave off one more byte and require software updates to
handle the different format required.

ekr, (seeking advice for next steps): do you think this would fit better as
a footnote in the cTLS update presentation at ietf112 or do you think it
would need extra discussion?

-carl
On Fri, Jul 30, 2021 at 3:00 PM Andrey Jivsov  wrote:

> I propose a method to compress NIST curves as defined in
> https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html
>
> Its main benefit is that the compressed point fits into field size / group
> order size. There is no additional byte needed.
> 
> On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner  wrote:
>
>> As requested during ekr's presentation
>> , I will volunteer to write up a
>> draft for defining new "supported groups" for compressed NIST curves. I
>> didn't see/hear any objections during the tls-wg meeting, but thought
>> I should probably confirm on the list before I got too far along in writing
>> it...
>>
>> -carl
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[Achim Kraus]

Hi David,

if you're on it, maybe it's worth to consider my question from January
2021 as well.

> If the client follows this guide, it falls-back to use a full handshake.
> If the client doesn't follow this (maybe, the client is not aware of RFC
7627), the server SHOULD aborts.

> Why SHOULD the server not (also) just fall-back to use a full handshake?

For more details see:

https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/

best regards
Achim Kraus

Am 26.10.21 um 00:51 schrieb David Benjamin:

Here's some possible replacement text for that paragraph:

"""
In some deployments, a legacy client or server may be exposed to a
session using extended master secret. For example, a group of servers
sharing a ticket encryption key may be in the process of enabling this
extension. If such a session is used in an abbreviated handshake without
the extension, a newer peer will fail the connection, as described in
Section 5.3. To avoid this, legacy servers SHOULD ignore such sessions
and continue with a full handshake, and legacy clients SHOULD NOT offer
such sessions in the ClientHello.

This can be implemented by ensuring legacy implementations do not
recognize sessions using extended master secret. For example, the
sessions may have a higher internal version number or, if the older
implementation rejects unrecognized fields, include a new field. If this
is not possible, deployments may deploy a new session cache or ticket
encryption key alongside the new version.
"""

Unfortunately, "session using extended master secret" is a bit of a
mouthful, but section 5.4 didn't define a more concise term.

On Mon, Oct 25, 2021 at 4:01 PM David Benjamin mailto:david...@chromium.org>> wrote:

Hi all,

In diagnosing an interop issue, I noticed RFC 7627 did not describe
the correct server behavior for EMS very well. Seemingly as a
result, some server implementation has gotten this wrong. I'd like
to fix this in the spec so this doesn't happen again. I think, at
minimum, we need to replace the last paragraph of section 5.4.

The issue is a server that /doesn't/ implement EMS, when presented a
ClientHello containing a ticket or session ID by a server that
/did/ implement EMS, must ignore the session and continue with a
full handshake. Failing to do so will trip the client check in
Section 5.3, "If a client receives a ServerHello that accepts an
abbreviated handshake, [...]". This is important to meet these three
properties:

- If the client and server both support EMS, the connection must
negotiate it.
- On resumption, the EMS status of the connection must match the EMS
status of the session
- In order for EMS to be safely deployable, it must be possible to
roll EMS out gradually, or roll it back, without breaking
connections. This means a mixed pre-EMS and post-EMS server
deployment must work.

Note that, although this behavior is only visible at the pre-EMS
server (not directly in scope for this document), it is actually a
requirement on the post-EMS server. When the post-EMS server issues
a session, it must arrange for the pre-EMS server to ignore it. For
example, if the pre-EMS server rejects sessions with unparsable
fields (the safest option), the post-EMS server can add a new field
to the session state serialization. Failing that, it can bump some
internal version number. Another strategy is to rotate session
ticket keys alongside the version, but this can be tricky the way
deployments and software updates are often split.

There's an analogous, though less likely, client scenario that a
pre-EMS client must not offer a post-EMS session. Otherwise it will
run afoul of a server requirement. This can be relevant for clients
that serialize their session cache.

As far as I can tell, RFC 7627 does not specify any of this. The
first paragraph of section 5.4 talks about adding a flag, but
doesn't talk about how pre-EMS servers interact with that flag. The
last paragraph discusses this scenario, but says something very
strange, if not plain wrong:

    If the original session uses an extended master secret but the
    ClientHello or ServerHello in the abbreviated handshake does not
    include the extension, it MAY be safe to continue the abbreviated
    handshake since it is protected by the extended master secret of the
    original session.  This scenario may occur, for example, when a
    server that implements this extension establishes a session but the
    session is subsequently resumed at a different server that does not
    support the extension.  Since such situations are unusual and likely
    to be the result of transient or inadvertent misconfigurations, this
    document recommends that the client and server MUST abort such
    handshakes.

https://datatracker.ietf.org/doc/html/rfc7627#sectio

Re: [TLS] Point Compression

[Andrey Jivsov]

Do we have evidence that "02 " or "03 " is more widespread than 
for NIST curves? I haven't seen "02 " or "03 " in deployed products
in TLS / X.509 at all. So, I feel that for TLS space the slate is clean
regarding compression. X25519 uses one coordinate, which is simiiar to
doing  for NIST curves...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls