Re: [TLS] ML-KEM key agreement for TLS 1.3

[Loganaden Velvindron]

On Wed, Mar 6, 2024, 06:16 Deirdre Connolly 
wrote:

> I have uploaded a preliminary version of ML-KEM for TLS 1.3
> 
> and have a more fleshed out
>  version to
> be uploaded when datatracker opens. It is a straightforward new
> `NamedGroup` to support key agreement via ML-KEM-768 or ML-KEM-1024, in a
> very similar style to -hybrid-design
> .
>
> It will be nice to have pure-PQ options (that are FIPS / CNSA 2.0
> compatible) ready to go when users are ready to use them.
>

Are those people ready to fork chrome or Firefox for internal use ?



> Cheers,
> Deirdre
> ___
> 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-cert-abridge-01.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-cert-abridge-01.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   Abridged Compression for WebPKI Certificates
   Author:  Dennis Jackson
   Name:draft-ietf-tls-cert-abridge-01.txt
   Pages:   21
   Dates:   2024-03-16

Abstract:

   This draft defines a new TLS Certificate Compression scheme which
   uses a shared dictionary of root and intermediate WebPKI
   certificates.  The scheme smooths the transition to post-quantum
   certificates by eliminating the root and intermediate certificates
   from the TLS certificate chain without impacting trust negotiation.
   It also delivers better compression than alternative proposals whilst
   ensuring fair treatment for both CAs and website operators.  It may
   also be useful in other applications which store certificate chains,
   e.g.  Certificate Transparency logs.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-cert-abridge-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-01.txt

[Dennis Jackson]

Just tagging editorial changes which where shared on the list a couple 
of weeks ago [1] to avoid document expiry.


No discussion is planned at IETF 119.

Best,
Dennis

On 16/03/2024 14:09, internet-dra...@ietf.org wrote:

Internet-Draft draft-ietf-tls-cert-abridge-01.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

Title:   Abridged Compression for WebPKI Certificates
Author:  Dennis Jackson
Name:draft-ietf-tls-cert-abridge-01.txt
Pages:   21
Dates:   2024-03-16

Abstract:

This draft defines a new TLS Certificate Compression scheme which
uses a shared dictionary of root and intermediate WebPKI
certificates.  The scheme smooths the transition to post-quantum
certificates by eliminating the root and intermediate certificates
from the TLS certificate chain without impacting trust negotiation.
It also delivers better compression than alternative proposals whilst
ensuring fair treatment for both CAs and website operators.  It may
also be useful in other applications which store certificate chains,
e.g.  Certificate Transparency logs.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-cert-abridge-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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-13.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-tlsflags-13.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   A Flags Extension for TLS 1.3
   Author:  Yoav Nir
   Name:draft-ietf-tls-tlsflags-13.txt
   Pages:   9
   Dates:   2024-03-16

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 Internet-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-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tlsflags-13

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [TLS] TLSFlags ambiguity

[David Benjamin]

Did this ever get resolved? I noticed that there was a draft-13 cut, but
the issue Jonathan pointed out was still there.

Looking at Section 2 again, it's actually even goofier than the original
email suggests. Section 2 first says:

> The FlagExtensions field contains 8 flags in each octet. The length of
the extension is the minimal length that allows it to encode all of the
present flags. Within each octet, the bits are packed such that the first
bit is the least significant bit and the eighth bit is the most significant.

This is LSB first. Then there's an example, which is also LSB first:

> For example, if we want to encode only flag number zero, the
FlagExtension field will be 1 octet long, that is encoded as follows:
>
>0001

So that's all consistent. But then the last paragraph of section 2 says:

> Note that this document does not define any particular bits for this
string. That is left to the protocol documents such as the ones in the
examples from the previous section. Such documents will have to define
which bit to set to show support, and the order of the bits within the bit
string shall be enumerated in network order: bit zero is the high-order bit
of the first octet as the flags field is transmitted.

This says it's MSB first for some reason. But this is not only
inconsistent, but also redundant with the text at the start of section 2.
It seems to me we could simply delete the redundant text and move on:

> Note that this document does not define any particular bits for this
string. That is left to the protocol documents such as the ones in the
examples from the previous section. Such documents will have to define
which bit to set to show support.

David

On Wed, Sep 27, 2023, 17:50 David Benjamin  wrote:

> Nice catch! I agree those don't match. I think bit zero should be the
> least-significant bit. That is, we should leave the examples as-is and then
> fix the specification text.
>
> Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no
> inherent order to bits in memory, so the most natural order is the power of
> two represented by the bit. Put another way, everyone accesses bit N by
> ANDing with 1 << N and that's least-significant bits first. I can think of
> a couple systems (DER, GCM) that chose to order bits most-significant first
> and both have caused endless confusion and problems. (It's particularly bad
> for GCM which is actually representing a polynomial, but then messed up the
> order. Let's not repeat this blunder.)
>
> On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland <
> jonathan.hoyl...@gmail.com> wrote:
>
>> Hi TLSWG,
>>
>> I'm working on implementing the TLS Flags extension
>> , and
>> I just wanted to clarify a potential ambiguity in the spec.
>>
>> In Section 2 the spec says:
>> Such documents will have to define which bit to set to show support, and
>> the order of the bits within the bit string shall be enumerated in network
>> order: bit zero is the high-order bit of the first octet as the flags field
>> is transmitted.
>>
>> And also gives the example for encoding bit zero:
>> For example, if we want to encode only flag number zero, the
>> FlagExtension field will be 1 octet long, that is encoded as follows:
>>
>>0001
>>
>> In which it seems that the low-order bit of the first octet represents zero.
>>
>> I have no preference either way, but when transmitted on the wire, should 
>> flag 0 be transmitted as
>>
>> 0x01 or 0x80?
>>
>> Regards,
>>
>> Jonathan
>>
>> ___
>> 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