Re: [TLS] IANA Recommendations for Obsolete Key Exchange

[Martin Thomson]

With David's clarifications, this is good.

On Tue, Apr 16, 2024, at 04:46, David Benjamin wrote:
> From the meeting, I remember there being some confusion around a table 
> that split things up between TLS 1.2 and TLS 1.3, and differences in 
> how they negotiate things, which makes this listing a bit ambiguous. In 
> particular, there aren't any *cipher suites* with FFDH or FFDHE in 
> their name in TLS 1.2. Also some of these constructions have analogs in 
> TLS 1.3 and some don't, but none as cipher suites.
>
> Agreed with the proposal, but specifically, this is what I understand 
> the proposal to mean:
>
> TLS 1.2 RSA cipher suites (TLS_RSA_WITH_*) should be marked with a "D"
> -- These lack forward secrecy and use a broken encryption scheme.
> -- There is no analog to RSA key exchange in TLS 1.3, so leave it alone.
>
> TLS 1.2 static DH cipher suites (TLS_DH_*_WITH_*) should be marked with 
> a "D"
> -- These lack forward secrecy and the DH(E) construction in TLS 1.2 is 
> broken. It lacks parameter negotiation, and uses a variable-length 
> secret that is vulnerable to the Raccoon attack, particularly in this 
> context with a static DH key.
> -- There is no analog to static DH in TLS 1.3, so leave it alone.
>
> TLS 1.2 DHE cipher suites (TLS_DHE_*_WITH_*) should be marked with a "D"
> -- While these do provide forward secrecy, the DH(E) construction in 
> TLS 1.2 is broken. It lacks parameter negotiation, and uses a 
> variable-length secret that is vulnerable to the Raccoon attack. In 
> this context, the Racoon attack is less fatal, but it is still a side 
> channel leakage that the protocol should have avoided.
> -- In theory RFC 7919 addressed the lack of parameter negotiation, but 
> by reusing the old construction's cipher suites, it is undeployable. It 
> also does not fix the side channel.
> -- There *is* an analog in TLS 1.3 (the ffdhe* named groups). However, 
> they do not share the TLS 1.2 construction's problems, so we can leave 
> them alone. They're just slow and kinda pointless given ECC exists.
>
> TLS 1.2 static ECDH cipher suites (TLS_ECDH_*_WITH_*) should be marked 
> with a "D"
> -- These lack forward secrecy
> -- There is no analog to static ECDH in TLS 1.3, so leave it alone.
>
>
>
> On Mon, Apr 15, 2024 at 1:30 PM Joseph Salowey  wrote:
>> At IETF 119 we had discussion on how to mark the ciphersuites deprecated by 
>> draft-ietf-tls-deprecate-obsolete-kex in the IANA Registry. At the meeting 
>> there was support for ('D' means discouraged):
>> 
>> RSA ciphersuites should be marked with a "D"
>> FFDH ciphersuites should be marked with a "D"
>> FFDHE ciphersuites should be marked with a "D"
>> ECDH ciphersuites should be marked with a "D"
>> 
>> This aligns with the deprecation intent of the draft. The draft states ECDH 
>> are a SHOULD NOT instead of a MUST NOT, but the sentiment was they should be 
>> generally discouraged.
>> 
>> Please respond with any comments on this proposal by April 30,2024.
>> 
>> Thanks,
>> 
>> Sean, Deirdre and Joe
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document

[Martin Thomson]

On Tue, Apr 16, 2024, at 04:14, Joseph Salowey wrote:
> Should the draft deprecate these ClientCertificateTypes and mark the 
> entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) 
> as 'D' discouraged?

Yes.

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

Re: [TLS] Genart last call review of draft-ietf-tls-keylogfile-01

[Martin Thomson]

Thanks  Russ,

https://github.com/tlswg/sslkeylogfile/pull/11 and 
https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/ 
should address those issues.

Cheers,
Martin

On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> .
>
> Document: draft-ietf-tls-keylogfile-01
> Reviewer: Russ Housley
> Review Date: 2024-04-12
> IETF LC End Date: 2024-04-18
> IESG Telechat date: unknown
>
> Summary: Ready
>
>
> Major Concerns:
>
> None
>
>
> Minor Concerns:
>
> Section 3: The text says: "Access to the content of a file in
> SSLKEYLOGFILE format allows an attacker to break the
> confidentiality protection on any TLS connections that are
> included in the file."  This is clearly true.  However, the
> attacker this access to the keys can also break the integrity
> protections.
>
> Section 4: The registration of the new application/sslkeylogfile
> media-type for all IETF registrations in the standards tree
> requires a posting to the media-ty...@iana.org mail list.  A search
> of the mail archive id not uncover "sslkeylogfile".  To avoid delay,
> that mail list discussion should probably get started now.
>
>
> Nits:
>
> Section 1: s/file format that logging/file format for logging/

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

[TLS] Transfer of change control for SSLKEYLOGFILE format

[Martin Thomson]

Hey,

I'm writing this in my capacity as owner for NSS[1], not as a draft author.

The chairs asked that I formally indicate that Mozilla and the NSS project
are willing to transfer ownership of the SSLKEYLOGFILE format[2].  Though
it might be obvious to some of us that submitting an Internet-Draft implies
that willingness, we might as well make it formal.

Mozilla and the NSS project are happy to transfer ownership of the
SSLKEYLOGFILE format to the IETF.

Thanks,
Martin

[1] https://firefox-source-docs.mozilla.org/mots/index.html#core-security
[2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-keylogfile
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Artart early review of draft-ietf-tls-wkech-04

[Martin Thomson]

Short inline comments.

On Tue, Apr 2, 2024, at 23:24, Stephen Farrell wrote:
> [...]
> I'm not really sure how to interpret the above tbh. Was that intended
> as a summary of the draft or as a synopsis of the problem space?

That's my sketch of what I think the draft should be doing.  I don't know if it 
truly does that, for the reasons stated elsewhere.

> Happy to document the validation more, but the basic idea is that the
> ZF checks ECH works, and if it does, then the ZF is ok to re-publish.
> If anyone has ideas on other kinds of checks that'd be sensible, be
> happy to consider incorporating those.

>From my perspective, I'm looking to understand first what the ZK is expected 
>to be responsible for, at the layer you describe here.  Then I would also like 
>to see a description of how it might achieve that more concretely.  You get 
>most of the way there, I think, but it needs to be a bit more thorough.


>> Titles are not sentences.  Lose the period.
>
> Where? (Sorry, not sure, but the RFC editor will fix anyway
> so no worries.)

The title of the document.

> Given all the above, it's probably fine if you wait 'till there's a
> -05 done before we chat more, (assuming you have time), but happy to
> discuss via email in the meantime too of course.

I look forward to it.

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

[TLS] Artart early review of draft-ietf-tls-wkech-04

[Martin Thomson via Datatracker]

Reviewer: Martin Thomson
Review result: Not Ready

This document describes how an HTTP origin can publish information about its
ECH configuration so that other nodes can aid it in setting up the DNS records
necessary to run DNS.

Issues:

Most of the document talks about having the back-end servers produce content
for the well-known resource, but there is mention of other servers being
involved as well.  ECH depends on having shared configuration at the
client-facing side for servers, so any configuration process should probably
involve something different.  That is, having each server produce information
about its own (perceived) configuration, with the zone factory being
responsible for synthesizing the information from each into a coherent whole.

In that design, a back-end server would indicate that they are using a shared
client-facing server, and point to it.  The client-facing server would supply
its ECH configuration (which might be different for different back-end
servers).  There are cases where a client-facing server might be able to
produce the content for a back-end server, so that a single resource could make
sense. That might lead to the design we see, but that is not obviously correct
for all aspects of the design.

The current design involves publishing information for a multitude of
ECHConfigList values and multiple target names (and ports).  It is not obvious
that it is safe to have one origin speak for multiple others in this way or
what conditions might be necessary to have that happen safely.  If there is a
validation process involved, that might work.  The process in S6 is too loose
for me to be confident in that being sufficient.

The design for publishing alias records is something I cannot decipher at all. 
There's a description of the field, but no real supporting material for that.

The different deployment options need to be more clearly articulated in support
of different modes of use, along with any validation that is needed.

It might be the case that the design is fundamentally sound, but it isn't clear
to me that this is true.

Nits:

Titles are not sentences.  Lose the period.

S1, typo: ECHConflgList

Use of the term "front-end" and "back-end" is likely confusing for some
consumers of this specification.  Front-end overwhelmingly refers to the
development of web-facing content, whereas back-end refers to the development
of servers and services.  Why not use client-facing as the ECH specification
does?

S3, please avoid using things like "cronjob".  Periodic is fine and doesn't
presume the use of a particular tool.

S3, typo: regularaly

S4:

> The well-known URI defined here MUST be an https URL and therefore the ZF
verifies the correct BE is being accessed. If no new ECH value resulting
"works," then the zone factory SHOULD NOT modify the zone.

This is two very different concepts in the one paragraph.  The first is about
authenticating the content at the .w-k resource.  The second is about
validating it.  There is no segue between the two.  Maybe you could say "The ZF
MUST validate any ECHConfig that it obtains before publishing information to
the DNS zone."

Also, avoid "scare quotes" and say what you mean by "works".

> Note that a consequence of the URL above is that back-ends that wish to use
different ECH settings are very likely to have to use different "DocRoot"
settings.

What is DocRoot?  (Really. I don't know what this means.)

More generally, I would prefer a use case or goal-motivated structure to the
document than a format-based one.  That is, consider answering some questions:
what information would a back-end server produce?  what would a front-end
produce?  what would you include (and validate) if you wanted to have aliases?


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

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

[Martin Thomson]

Dennis beat me to making the key point about identity :)

There are cases where identity misbinding is possible in similar systems.  RFC 
8844 describes one such case.  However, this is not an inherent failing in TLS, 
but in the usage context.  That weakness was not the result of using raw public 
keys though.

What TLS *says* about this risk is really what we should be considering.  It 
might be enough to say that where TLS does not carry all of the relevant 
identification information, there is a risk of identity misbinding attacks.  
This can be mitigated by including additional information about identity in the 
transcript and checking it for consistency (as RFC 8844 does).

On Fri, Mar 29, 2024, at 05:27, Dennis Jackson wrote:
> Hi John, 
>
> It depends what you mean by an identity. TLS1.3 ensures the peers agree 
> on the used RPKs and it doesn't rely on any external proof of 
> possession to achieve that property.
>
> How the peers come to trust the RPKs or their corresponding identity is 
> of necessity left to the application - not dissimilar to how the 
> application has to decide which root certificates to trust and whether 
> the leaf certificate is appropriate for the intended connection (e.g. 
> browsers extract the valid identities from the SAN). 
>
> Best,
> Dennis
>
> On 28/03/2024 15:22, John Mattsson wrote:
>> Hi,
>>  
>> I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly 
>> stated in RFC 8446, TLS 1.3 with signatures and certificates is an 
>> implementation of SIGMA-I: 
>>  
>> SIGMA does however require that the identities of the endpoints (called A 
>> and B in [SIGMA]) are included in the messages. This is not true for TLS 1.3 
>> with RPKs and TLS 1.3 with RPKs is therefore not SIGMA. TLS 1.3 with RPKs is 
>> vulnerable to what Krawczyk’s SIGMA paper calls misbinding attacks:
>>  
>> “This attack, to which we refer as an “identity misbinding attack”, applies 
>> to many seemingly natural and intuitive protocols. Avoiding this form of 
>> attack and guaranteeing a consistent binding between a session key and the 
>> peers to the session is a central element in the design of SIGMA.”
>>  
>> “Even more significantly we show here that the misbinding attack applies to 
>> this protocol in any scenario where parties can register public keys without 
>> proving knowledge of the corresponding signature key.”
>>  
>> As stated in Appendix E.1, at the completion of the handshake, each side 
>> outputs its view of the identities of the communicating parties. On of the 
>> TLS 1.3 security properties are “Peer Authentication”, which says that the 
>> client’s and server’s view of the identities match. TLS 1.3 with PRKs does 
>> not fulfill this unless the out-of-band mechanism to register public keys 
>> proved knowledge of the private key. RFC 7250 does not say anything about 
>> this either. 
>>  
>> I think this needs to be clarified in RFC8446bis. The only reason to ever 
>> use an RPK is in constrained IoT environments. Otherwise a self-signed 
>> certificate is a much better choice. TLS 1.3 with self-signed certificates 
>> is SIGMA-I.
>>  
>> It is worrying to find comments like this:
>>  
>> “I'd like to be able to use wireguard/ssh-style authentication for my app. 
>> This is possible currently with self-signed certificates, but the proper 
>> solution is RFC 7250, which is also part of TLS 1.3.”
>> https://github.com/openssl/openssl/issues/6929
>>  
>> RPKs are not the proper solution.
>>  
>> (Talking about misbinding, does RFC 8446 say anything about how to avoid 
>> selfie attacks where an entity using PSK authentication ends up talking to 
>> itself?)
>>  
>> Cheers,
>> John Preuß Mattsson
>>  
>> [SIGMA] https://link.springer.com/chapter/10.1007/978-3-540-45146-4_24
>>  
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Next steps for Large Record Sizes for TLS and DTLS

[Martin Thomson]

In offline discussion l was convinced that a bigger change might be needed.  
The shifting is cute, but we might be able to do better.

This won't be wire compatible with the existing protocol, so maybe just embrace 
that and change the record header.  This would happen when switching from 
handshake protection to application data protection.  We can drop the version 
and content type and reclaim some of the savings for a longer length field.

On Wed, Mar 20, 2024, at 13:42, John Mattsson wrote:
> Hi,
> 
> My summary from the TLS WG session yesterday:
> 
> - Let’s adopt and figure out the final details later.
> - Show performance data.
> - Should be new extension, i.e., not used together with "record size 
> limit".
> - The new extension should redefine the meaning of the uint16 length 
> field in the TLSCiphertext to allow records larger than 2^16 bytes.
> 
> Simple suggestion:
> 
> In the new extension the client and server negotiate an uint8 value n. 
> Client suggest a value n_max. Server selects n where 0 <= n <= n_max or 
> rejects the extension. Agreeing on a value n means:
> 
> - The length field in the record means 2^n * length bytes instead of 
> length bytes. I.e., left shifted similar to the TCP window scale option.
> - The client and server are willing to receive records of size 2^n * 
> (2^16 - 1) bytes.
> - Up to 2^n - 1 bytes of padding might be required.
> - AEAD limits are reduced with a factor 2^(n+2).
> 
> Thought?
> 
> Cheers,
> John Preuß Mattsson
> 
> *From: *internet-dra...@ietf.org 
> *Date: *Tuesday, 5 March 2024 at 06:16
> *To: *John Mattsson , Michael Tüxen 
> , Hannes Tschofenig , 
> Hannes Tschofenig , John Mattsson 
> , Michael Tuexen 
> *Subject: *New Version Notification for 
> draft-mattsson-tls-super-jumbo-record-limit-02.txt
> A new version of Internet-Draft
> draft-mattsson-tls-super-jumbo-record-limit-02.txt has been successfully
> submitted by John Preuß Mattsson and posted to the
> IETF repository.
>
> Name: draft-mattsson-tls-super-jumbo-record-limit
> Revision: 02
> Title:Large Record Sizes for TLS and DTLS
> Date: 2024-03-04
> Group:Individual Submission
> Pages:6
> URL:  
> https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
> HTML: 
> https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-02.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-02
>
> Abstract:
>
>RFC 8449 defines a record size limit extension for TLS and DTLS
>allowing endpoints to negotiate a record size limit smaller than the
>protocol-defined maximum record size, which is around 2^14 bytes.
>This document specifies a TLS flag extension to be used in
>combination with the record size limit extension allowing endpoints
>to use a record size limit larger than the protocol-defined maximum
>record size, but not more than about 2^16 bytes.
>
>
>
> The IETF Secretariat
> ___
> 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] Working Group Last Call for SSLKEYLOG File

[Martin Thomson]

Reasonable statement.  It's a variation on what we already have, but the focus 
on forward secrecy is worth a small paragraph:

How about this: https://github.com/tlswg/sslkeylogfile/pull/7/files

On Thu, Mar 14, 2024, at 22:51, Dennis Jackson wrote:
> I have a suggestion which keeps things technical but hopefully 
> addresses Stephen's concern:
>
> In Security Considerations: 
>
> "TLS1.3 requires the use of forward secret key exchanges (RFC 8446, 
> 1.2, E.1). Using SSLKEYLOGFILE breaks this security property as it 
> records the used session key and so invalidates many of the security 
> claims made in RFC 8446. If SSLKEYLOGFILE is in use, the transferred 
> data does not benefit from the security protections offered by RFC 8446 
> and systems using SSLKEYLOGFILE cannot be considered compliant with RFC 
> 8446 or offering similar security to the protocol outlined in that 
> draft." 
>
> I don't think the wording there is quite right, but I do think the 
> Security Considerations should clearly call out the impact on forward 
> secrecy and RFC 8446 in general and so dissuade use. 
>
> Best,
> Dennis
>
> On 12/03/2024 23:07, Eric Rescorla wrote:
>> 
>> 
>> On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell  
>> wrote:
>>> 
>>> I'll argue just a little more then shut up...
>>> 
>>> On 12/03/2024 22:55, Martin Thomson wrote:
>>> > 
>>> >> Sorry also for a late suggestion, but how'd we feel about adding 
>>> >> some text like this to 1.1?
>>> >> 
>>> >> "An implementation, esp. a server, emitting a log file such as this
>>> >> in a production environment where the TLS clients are unaware that
>>> >> logging is happening, could fall afoul of regulatory requirements
>>> >> to protect client data using state-of-the-art mechanisms."
>>> 
>>> > I agree with Ekr.  That risk is not appreciably changed by the
>>> > existence of a definition for a file format.
>>> I totally do consider our documenting this format increases
>>> the risk that production systems have such logging enabled,
>>> despite our saying "MUST NOT." So if there's a way to further
>>> disincentivise doing that, by even obliquely referring to
>>> potential negative consequences of doing so, then I'd be for
>>> doing that. 
>> 
>> Aside from this particular case, I don't think technical specifications
>> should "obliquely" refer to things. Technical specifications should be
>> clear.
>> 
>> -Ekr
>> 
>>> Hence my suggestion.
>>> 
>>> S.
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Martin Thomson]

On Wed, Mar 13, 2024, at 08:39, Stephen Farrell wrote:
> (Apologies to Martin for the grudging acceptance of
> his worthy effort;-)

No apology needed.  Nose-holding is expected :)

> Sorry also for a late suggestion, but how'd we feel about adding
> some text like this to 1.1?
>
> "An implementation, esp. a server, emitting a log file such
>  as this in a production environment where the TLS clients are
>  unaware that logging is happening, could fall afoul of regulatory
>  requirements to protect client data using state-of-the-art
>  mechanisms."

I agree with Ekr.  That risk is not appreciably changed by the existence of a 
definition for a file format.  And we do better keeping to the technical 
implications of choices.

> Another thought occurred to me that I don't recall being mentioned
> before: given we're defining a mime type, that suggests sending
> these files by mail or in an HTTP response. Doing that could
> be leaky, [...]

I see equal opportunity for good things (detecting keylogfiles, deleting them, 
generating a warning), than bad as a result of writing this down.  See also RFC 
8959 (which the IETF did not publish, which I concede undermines my position 
somewhat...)

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

Re: [TLS] Working Group Last Call for ECH

[Martin Thomson]

 Ship it.

On Tue, Mar 12, 2024, at 09:00, Joseph Salowey wrote:
> This is the working group last call for TLS Encrypted Client Hello [1]. 
>  Please indicate if you think the draft is ready to progress to the 
> IESG and send any comments to the list by 31 March 2024.  The comments 
> sent by Watson Ladd to the list [2] on 17 February 2024 will be 
> considered last call comments.
>
> Thanks,
>
> Joe, Deirdre, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>
>
> ___
> 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] Time to first byte vs time to last byte

[Martin Thomson]

Hi Panos,

I realize that TTLB might correlate well for some types of web content, but 
it's important to recognize that lots of web content is badly bloated (if you 
can tolerate the invective, this is a pretty good look at the situation, with 
numbers: https://infrequently.org/series/performance-inequality/).

I don't want to call out your employer's properties in particular, but at over 
3M and with relatively few connections, handshakes really don't play much into 
page load performance.  That might be typical, but just being typical doesn't 
mean that it's a case we should be optimizing for.

The 72K page I linked above looks very different.  There, your paper shows a 
20-25% hit on TTLB.  TTFB is likely more affected due to the way congestion 
controllers work and the fact that you never leave slow start.

Cheers,
Martin

On Fri, Mar 8, 2024, at 13:56, Kampanakis, Panos wrote:
> Thx Deirdre for bringing it up. 
> 
> David,
> 
> ACK. I think the overall point of our paper is that application 
> performance is more closely related to PQ TTLB than PQ TTFB/handshake. 
> 
> Snippet from the paper
> 
> *> Google’s PageSpeed Insights [12] uses a set of metrics to measure 
> the user experience and webpage performance. The First Contentful Paint 
> (FCP), Largest Contentful Paint (LCP), First Input Delay (FID), 
> Interaction to Next Paint (INP), Total Blocking Time (TBT), and 
> Cumulative Layout Shift (CLS) metrics include this work’s TTLB along 
> with other client-side, browser application-specific execution delays. 
> The PageSpeed Insights TTFB metric measures the total time up to the 
> point the first byte of data makes it to the client. So, PageSpeed 
> Insights TTFB is like this work’s TTFB/TLS handshake time with 
> additional network delays like DNS lookup, redirect, service worker 
> startup, and request time.*
> 
> Specifically about the Web, TTLB (as defined in the paper) is directly 
> related to FCP, LCP, FID, INP, TBT, CLS, which are 6 of the 7 metrics 
> in Google’s PageSpeed Insights. We don’t want to declare that TTLB is 
> the ultimate metric, but intuitively, I think it is a better indicator 
> when it comes to application performance than TTFB. 
> 
> That does not intend to underestimate the importance of the studies on 
> handshake performance which was crucial to identify the best performing 
> new KEMs and signatures. It also does not intend to underestimate the 
> importance of slimming down PQ TLS 1.3 handshakes as much as possible.
> 
> Side note about Rob’s point: 
> We have not collected QUIC TTLB data yet, but I want to say that the 
> paper’s TTLB experimental results could more or less be extended to 
> QUIC be subtracting one RTT. OK, I don’t have experimental measurements 
> to prove it yet. So I will only make this claim and stop until I have 
> more data.
> 
> 
> 
> *From:* TLS  *On Behalf Of * David Benjamin
> *Sent:* Thursday, March 7, 2024 3:41 PM
> *To:* Deirdre Connolly 
> *Cc:* TLS@ietf.org
> *Subject:* RE: [EXTERNAL] [TLS] Time to first byte vs time to last byte
> 
> *CAUTION*: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender 
> and know the content is safe.
>
> 
> This is good work, but we need to be wary of getting too excited about 
> TTLB, and then declaring performance solved. Ultimately, TTLB simply 
> dampens the impact of postquantum by mixing in the 
> (handshake-independent) time to do the bulk transfer. The question is 
> whether that reflects our goals. 
> 
> Ultimately, the thing that matters is overall application performance, 
> which can be complex to measure because you actually have to try that 
> application. Metrics like TTLB, TTFB, etc., are isolated to one 
> connection and thus easier to measure, and without checking each 
> application one by one. But they're only as valuable as they are 
> predictors of overall application performance. For TTLB, both the 
> magnitude and desirability of dampening effect are application-specific:
> 
> If your goal is transferring a large file on the backend, such that you 
> really only care when the operation is complete, then yes, TTLB is a 
> good proxy for application system performance. You just care about 
> throughput in that case. Moreover, in such applications, if you are 
> transferring a lot of data, the dampening effect not only reflects 
> reality but is larger.
> 
> However, interactive, user-facing applications are different. There, 
> TTLB is a poor proxy for application performance. For example, on the 
> web, performance is determined more by how long it takes to display a 
> meaningful webpage to the user. (We often call this the time to "first 
> contentful paint".) Now, that is a very high-level metric that is 
> impacted by all sorts of things, such as whether this is a repeat 
> visit, page structure, etc. So it is hard to immediately translate that 
> back down to TLS. But it is frequently much 

Re: [TLS] Status of draft-ietf-tls-rfc8446bis

[Martin Thomson]

On Mon, Feb 19, 2024, at 04:44, Eric Rescorla wrote:
> I wouldn't object to more analysis, but given the relatively narrow 
> remit of this
> document and that changing the key schedule would obviously create wire
> format incompatibilities, I wouldn't want to do that absent some 
> evidence
> that the change was insecure as opposed to unnecessary.

If the concern is that the protocol has some unnecessary steps, that's not 
something that we should fix unless there was a credible concern about security 
raised.  At that point, we'd definitely want more analysis.

As it stands, there is an assertion that this extra Derive-Secret call is 
wasteful.  That might be true, but for a protocol that secures billions of 
connections each day, I would say that the standard required to make a change 
is a bit higher than "might be wasteful".  Yes, the cost of any waste is 
amplified by a very large factor, but the cost of a change -- any change -- is 
significantly higher, at least in my reckoning.

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

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

[Martin Thomson]

On Wed, Jan 31, 2024, at 07:16, Salz, Rich wrote:
>> This version incorporates all known issues. The authors believe this version 
>> is ready for WGLC.
>
> Yes, pretty much.  Two nits than can be fixed during AUTH48
>
> This sentence in Sec 15 confuses me:
>   For this reason, designated experts should decline code point 
> registrations for documents which have already been adopted or are 
> being proposed for adoption by IETF working groups or IRTF research 
> groups.
>
> Presumably, you want the RG/WG chair to make the request?   Or do you 
> mean "other than the TLS WG" ?

Requests to experts for published documents tends to come from IANA directly.  
But I think that your remedy is fine.

If the WG/RG has consensus to ask for a codepoint, then it is reasonable to 
allow the codepoint to be assigned.  So maybe add "Experts can approve 
registrations if the working or research group reaches consensus about the need 
for code point assignment and the chairs of a group request assignment."

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

Re: [TLS] I-D Action: draft-ietf-tls-keylogfile-00.txt

[Martin Thomson]

On Fri, Jan 26, 2024, at 02:36, Salz, Rich wrote:
>> Internet-Draft draft-ietf-tls-keylogfile-00.txt is now available. It is a 
>> work
>> item of the Transport Layer Security (TLS) WG of the IETF.
>
> I assume this just documents the current format and that therefore 
> existing implementations (OpenSSL and Wireshark come to mind) just work.

That's exactly right.  I'm not looking to add features.

> If that assumption is true, this seems ready for WGLC.

I agree.

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

Re: [TLS] [Errata Held for Document Update] RFC8446 (6205)

[Martin Thomson]

Yeah, we talked about this one and came to a reasonable conclusion that was 
based on what I wrote at the time, but better because RFC 8773 exists.

The added text:

> In the absence of some other specification to the contrary, servers which are 
> authenticating with an external PSK MUST NOT send the CertificateRequest 
> message either in the main handshake or request post-handshake 
> authentication. [RFC8773] provides an extension to permit this, but has not 
> received the level of analysis as this specification.

You could improve further, slightly, on an editorial basis:  s/the level of 
analysis/the same level of analysis/

On Wed, Jan 17, 2024, at 13:12, Eric Rescorla wrote:
> I believe that the current 8446-bis text addresses this. Martin?
>
> On Tue, Jan 16, 2024 at 4:59 PM RFC Errata System 
>  wrote:
>> The following errata report has been held for document update 
>> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 
>> 
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6205
>> 
>> ------
>> Status: Held for Document Update
>> Type: Editorial
>> 
>> Reported by: Martin Thomson 
>> Date Reported: 2020-06-04
>> Held by: Paul Wouters (IESG)
>> 
>> Section: 4.3.2
>> 
>> Original Text
>> -
>>Servers which are authenticating with a PSK MUST NOT send the
>>CertificateRequest message in the main handshake, though they MAY
>>send it in post-handshake authentication (see Section 4.6.2) provided
>>that the client has sent the "post_handshake_auth" extension (see
>>Section 4.2.6).
>> 
>> Corrected Text
>> --
>>Servers which are authenticating with a resumption PSK MUST NOT send the
>>CertificateRequest message in the main handshake, though they MAY
>>send it in post-handshake authentication (see Section 4.6.2) provided
>>that the client has sent the "post_handshake_auth" extension (see
>>Section 4.2.6).  Servers which are authenticating with an external PSK
>>MUST NOT send the CertificateRequest message either in the main handshake
>>or request post-handshake authentication. Future specifications MAY
>>provide an extension to permit this. 
>> 
>> Notes
>> -
>> The lack of qualification on "authenticating with a PSK" implies that the 
>> statement applies equally to both external and resumption PSKs.  However, 
>> there are two conditions being governed: whether a certificate can be 
>> requested during the handshake, and whether a certificate can be requested 
>> post-handshake.  The latter of these requires different rules depending on 
>> the type of PSK.
>> 
>> We know from the analysis of resumption (see 
>> https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that 
>> combining a PSK handshake of either type with a client certificate is not 
>> safe.  Thus, the prohibition on CertificateRequest during the handshake 
>> applies equally to both resumption and external PSKs.
>> 
>> For post-handshake, Appendix E.1 already discusses the risks of combining 
>> PSKs with certificates, citing the same analysis as above.
>> 
>>[...]  It is unsafe to use certificate-based client
>>authentication when the client might potentially share the same
>>PSK/key-id pair with two different endpoints.
>> 
>> For this reason an external PSK is not safe to use with post-handshake 
>> authentication.  A resumption PSK does not have this property, so the same 
>> prohibition doesn't apply.
>> 
>> Splitting the requirements as proposed makes this split clearer.
>> 
>> --
>> RFC8446 (draft-ietf-tls-tls13-28)
>> --
>> Title   : The Transport Layer Security (TLS) Protocol Version 1.3
>> Publication Date: August 2018
>> Author(s)   : E. Rescorla
>> Category: PROPOSED STANDARD
>> Source  : Transport Layer Security
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG

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

Re: [TLS] X-Wing: the go-to PQ/T hybrid KEM?

[Martin Thomson]

On Thu, Jan 11, 2024, at 07:13, Bas Westerbaan wrote:
> X-Wing aims for 128-bit security, and for that combines the time-tested 
> X25519 with ML-KEM-768 [8]. X-Wing uses the combiner
>
>   SHA3-256( xwing-label || ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 )

At least for TLS, I'm not convinced that any combiner is necessary, in line 
with the analysis done for draft-ietf-tls-hybrid-design.

TLS hashes the entire transcript.  Would you poke holes in it to make the 
savings real?  That seems inadvisable, not only because it would be a pain to 
implement.  The existing draft-tls-westerbaan-xyber768d00 seems adequate in 
that regard.

I'm of the view that draft-westerbaan-cfrg-hpke-xyber768d00 is also fine for 
HPKE (modulo an update to the latest ML-KEM).  If the analysis shows that you 
can avoid the ML-KEM ciphertext, then I'm not opposed to cost savings for HPKE.

In other words, though I can see the value in modularity of analysis that 
something like this brings, if that modularity comes at the cost of efficiency 
or complexity in real applications, I don't see the point.

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

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

[Martin Thomson]

On Thu, Jan 11, 2024, at 18:38, Christian Huitema wrote:
> If an implementation does not want to deal with the extra complexity, 
> then having a way to plug in some extra code for a specific scenario 
> makes sense...

My point was that the handling does not need to be complex, only the tolerance 
for time variation needs to be.  Tolerance is driven by two things: RTT and 
clock variations.  But - critically - that tolerance needs to be uniformly 
managed across the entire set of clients.  If you have clients that have very 
tight variance on timing, you can use a narrow window, but you risk excluding 
those with high variance.  If you want to allow for high variance, you spend 
more in doing so, largely by having to track more 0-RTT attempts over a wider 
window of time.

You can't selectively change that tolerance.  Otherwise, an attacker looking to 
exploit replay can choose whichever per-client reaction suits them best.

I'm assuming this is a DoS attack, I can't see how you would exploit this to 
mount a replay, though you might choose an option with false negatives on 
replay detection ... you shouldn't.  All of the distributed systems challenges 
that apply shouldn't be affected by long RTT unless you start increasing the 
distance between nodes that share 0-RTT state in ways that could be exploitable 
(note: do not do this, sharing state between collocated nodes is already risky 
enough).

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

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

[Martin Thomson]

On Thu, Jan 11, 2024, at 15:45, Christian Huitema wrote:
> Good for you. Not all implementations do that. It is hard for me to 
> blame them, because the 10 seconds recommendation is justified by for 
> "clients on the Internet", and delays larger than 1 or maybe 2 seconds 
> are quite rare on the "Earthian" Internet that we have today. Given that 
> complexity is the enemy of security, I certainly understand why some 
> implementations keep it simple.

I consider it necessary for reliability purposes.  If you don't at least try to 
account for RTT, you are skewing any window anti-replay window you have.

> Yes, but the relation between delays and variance is rather complex. On 
> the current Internet, a good bit of delay variance comes from congestion 
> control protocols pushing ever more data until queues overflow -- but 
> better congestion control or using modern AQM in front of the bottleneck 
> can take care of that. 

Keep in mind that a lot of these exchanges won't have had much data exchanged 
on the connection at the time.  So a lot of the variance from self-induced 
congestion won't come into play.  That's not to say that you won't be affected 
by what others are doing or other active connections though.  And of course, 
your space networks have other more interesting factors pushing delays in all 
directions.

> Plus, how exactly does one test this kind of "variable delay" code?

Time is just another input to your program, right?

> The more I think of it, the more I believe the solution may be some kind 
> of plug-in in the TLS implementation. Let the application that requires 
> the extra complexity deal with it, develop and test the adequate plug-in.

I don't think that there is much need for active code, just configuration.  
Maybe I'm missing something though.

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

Re: [TLS] 0RTT freshness test does not work well when delays are in minutes

[Martin Thomson]

On Thu, Jan 11, 2024, at 11:07, Christian Huitema wrote:
> One first problem with this code is that implementations may or may not 
> have an estimate of the RTT when they are issuing the ticket. In theory 
> the server could measure the RTT by comparing the send time of the 
> server first flight and the arrival time of the client's second flight, 
> but that's extra complexity and implementations may well skip that test.

This seems like a pretty easy thing to measure.  It's what I implemented for 
NSS.  I don't think that you should assume that people won't do that.

> In theory, the client could compensate the clients_ticket_age to include 
> the RTT, but that's risky. If the client is connecting to a server 
> implementation that does adjust the ticket creation time, the adjusted 
> client time will be found larger than the current time at the server. 
> Servers may well test for that, reject the ticket and fall back to 1RTT.

Compensating for the RTT estimate is possible (again, I can attest to this 
being easy to implement), but the problem is that you also need to account for 
a larger RTT variance when RTT increases.  For that, it is not so easy as the 
more obvious mechanisms for tracking anti-replay need to be globally 
configured, not driven by per-connection parameters.  If you have clients with 
1s RTTs coexisting with those that have RTTs measured in minutes, the 
configuration needs to be different.

See 
https://searchfox.org/mozilla-central/rev/b1a029fadaaabb333d8139f9ec3924a20c0c941f/security/nss/lib/ssl/sslexp.h#187-194
 (which doesn't talk about RTT variance, but it should).

If you know about a population of clients with high variance, you can build 
allowances in, but I don't have a general solution.  However, allowing for that 
variance comes with a cost in terms of state space, especially if you have to 
allow for high connection rates.

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Martin Thomson]

On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote:
> In the interest of clarity,  I favor the WG declining to work on 
> extending TLS 1.2, so these cipher suites should be marked as 
> Recommended=No. I'm just concerned that closing the registries entirely 
> will not have the best results.

This is also my view.  It would be a shame to embark on another attempt to use 
registry policies to control implementations, in defiance of everything we've 
learned about that not working.

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Martin Thomson]

On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote:
> That is not what the just-adopted draft says.  It says that except for 
> ALPN and exporters that no new registrations will be accepted for TLS 
> 1.2 and that new entries should have a Note comment that says “for TLS 
> 1.3 or later”. This is a change in the current policy.  It has always 
> said this; see page 3 of [1].

I should learn to read the IANA considerations.  This current says:

> IANA will stop accepting registrations for any TLS parameters [TLS13REG] 
> except for the following

Aside from the fact that the wording also says that IANA will stop accepting 
TLS 1.3 registrations too, I think that this is a very bad idea.

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Martin Thomson]

On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote:
> Of course.  We’re not the protocol police and nobody from the IETF will 
> come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But 
> with this document, they will not be able to register such an algorithm 
> for 1.2

I don’t think we can go that far. Our registry policies would allow someone 
else to define something PQC-ish we are only saying that we .intend. to not 
define something with “official” standing.

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

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Martin Thomson]

One thing that I observed when we were doing QUIC was that the canonical 
reference for how to do this sort of anti-replay is a section that is buried 
deep in an IPsec RFC.  Perhaps that short RFC is an opportunity to also 
document the process in a way that can be a reference to other documents.  
(That's a slightly longer RFC, but still fairly short; Section 3.4.3 of RFC 
4303 is just two pages in the old measure.)

On Wed, Nov 29, 2023, at 11:21, Eric Rescorla wrote:
> I agree that it would be good to require replay protection at this 
> time. Perhaps we should just publish a short RFC requiring it.
>
> -Ekr
>
>
> On Tue, Nov 28, 2023 at 3:00 PM John Mattsson 
>  wrote:
>> Hi,
>> __ __
>> Lack of replay also enables tracking of client and server. If the client or 
>> server is a device moving together with a person this enables tracking of 
>> the person.
>> __ __
>> An attacker can store a message from one location and then replay it to the 
>> client or server in another location. If the client or server accept the 
>> replayed message, the attacker knows that the device in the two locations 
>> are one and the same. It is best practice to assume that an attacker can 
>> always detect if a message was accepted. If the client or server send a 
>> response to the replayed message (like a replayed client authentication 
>> request) this is trivial.
>> __ __
>> This is different from the attack described in Section C.4 “Client and 
>> Server Tracking Prevention” of RFC8446bis, which describes the client 
>> reusing a ticket. A network attacker mounting a replay attack are described 
>> in Section 8 of RFC8446bis. I think a sentence or two should be added to 
>> Section C.4 to describe that a network attacker mounting a replay attack can 
>> be used for server tracking and that the mitigations in Section 8 help.
>> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/
>> __ __
>> Cheers,
>> John Preuß Mattsson
>> __ __
>> *From: *TLS  on behalf of John Mattsson 
>> 
>> *Date: *Tuesday, 28 November 2023 at 09:30
>> *To: *TLS@ietf.org 
>> *Subject: *Re: [TLS] DTLS 1.3 replay protection of post-handshake 
>> messages?
>> Hi,
>>  
>> Reading RFC 9147 (DTLS 1.3) I cannot find any other interpretation than that 
>> replay protection may be disabled for all records. This is not a problem for 
>> the initial lock-step handshake, alerts, KeyUpdate, and ACKs. It seems to be 
>> a major problem for NewSessionTicket, NewConnectionId, RequestConnectionId, 
>> and Post-handshake client authentication as the lack of replay protection 
>> might significantly affect availability. It seems to me that DTLS 1.3 forgot 
>> to update replay protection based on the new post-handshake messages. Let me 
>> know if I miss something.
>>  
>> It is a bit surprising that DTLS 1.3 published in 2022 allows the 
>> application to turn off replay protection at all. This very far from current 
>> best practice for security protocols. There are very good reasons why 
>> Datagram QUIC mandates replay protection and why TLS 1.3 has several pages 
>> discussing security considerations for 0-RTT data, which lacks replay 
>> protection. In general, turning off replay protection (even just for 
>> application data) might lead to loss of confidentiality, integrity, and 
>> availability, i.e., the whole CIA triad.
>>  
>> Applications cannot be expected to understand the severe consequences of not 
>> having replay protection or understand how to fix it on the application 
>> layer. I also don't see any need for turning off replay protection except 
>> RFC 6083 which is a bit of a special case, and which turned out to have 
>> replay issues.
>> https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00
>>  
>> I would strongly recommend all DTLS 1.3 libraries to completely remove the 
>> option to disable replay protection.
>>  
>> An easy fix for the post-handshake messages is to "clarify" that replay 
>> protection must not be turned off for anything else than application data. I 
>> you agree I can submit an “erratum” for RFC 9147. But this does not solve 
>> the general issue that turning off replay protection would be a major 
>> security problem in almost all applications. 
>>  
>> Cheers,
>> John Preuß Mattsson
>>  
>> *From: *TLS  on behalf of John Mattsson 
>> 
>> *Date: *Friday, 24 November 2023 at 14:50
>> *To: *TLS@ietf.org 
>> *Subject: *[TLS] DTLS 1.3 replay protection of post-handshake messages?
>> Hi,
>>  
>> How does replay protection of Post-handshake messages work in DTLS 1.3 if 
>> the per-record replay-protection mechanism is turned off?
>>  
>> 1. Is the post-handshake messages replay protected in some other way, which 
>> I miss?
>>  
>> 2. Should RFC 9147 state that the per-record replay-protection mechanism can 
>> only be turned off for application data? 

Re: [TLS] DTLS 1.3 replay protection of post-handshake messages?

[Martin Thomson]

On Tue, Nov 28, 2023, at 19:29, John Mattsson wrote:
> I would strongly recommend all DTLS 1.3 libraries to completely remove 
> the option to disable replay protection.

I believe that the reason this exists is that some higher-layer protocols have 
their own replay protection, such that as long as the datagram is authentic, it 
is safe.  However, I agree that if we are sending handshake messages that 
affect DTLS state, it is probably not good to have the DTLS layer fail to 
provide that protection.  I believe that you can operate DTLS 1.3 without 
post-handshake handshake/control messages, in which case you might manage to 
avoid exposure.

NSS has no means to disable replay protection and I see no reason to add that 
means.

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

Re: [TLS] ECH: Changes to IANA consideration section

[Martin Thomson]

On Tue, Nov 28, 2023, at 05:03, Watson Ladd wrote:
>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>> indicate a value; remember, this column indicates the messages in which the 
>> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
>> makes sense to me considering this extension never directly appears in CH, 
>> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
>> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
>> unassigned and reserved values.  The following PR change “” to “N/A”: 
>> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>
> The only alternative I can think of is to introduce CHI, standing for
> client hello inner, as a possible value for that field. Then we need
> to update all the other values in the registry as well. I understand
> why we got to N/A, but the subtlety of N/A vs - vs the empty string
> irks me a bit, especially as this is used in TLS 1.3, hence the list
> is applicable, it's just empty!

"CH" seems fine to me.

That it can only appear in the inner CH is a very important detail, but one 
that is addressed in the specification.  Many other extensions have conditions 
on when they can be included in a message.  This might be a new level of 
conditionality, but it seems like implementing the specification will clear up 
any confusion.

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

Re: [TLS] New Internet Draft: The qpack_static_table_version TLS extension

[Martin Thomson]

On Wed, Sep 27, 2023, at 01:32, Hewitt, Rory wrote:
> Apologies if I should respond directly to the mailing list - my old W3C 
> profile has disappeared and I'm trying to get it back...

Just on this point.  Watson added the HTTP working group, which I think is the 
right thing to do here.  The maintenance of HTTP/3 now formally belongs in that 
group.  The work of defining a TLS extension for that purpose would occur there 
(if indeed a TLS extension is the right choice, as Watson asks).

As for the W3C involvement, the HTTP working group is an IETF activity that - 
for historical reasons - uses a W3C-hosted mailing list.  You don't need to be 
a W3C member to sign up for that list.  The process is just a little different 
than for other IETF lists.  See 
https://lists.w3.org/Archives/Public/ietf-http-wg/ for details.

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

Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Martin Thomson]

This is good work and looks to be ready.

(I could quibble about the extensibility model or the inclusion of the basic 
check mode, but both are well specified.)

On Tue, Sep 19, 2023, at 07:03, Sean Turner wrote:
> This email starts the 2nd working group last call for "Return 
> Routability Check for DTLS 1.2 and DTLS 1.3” I-D, located here:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
>
> The WG Last Call will end 3 October 2023 @ 2359 UTC.
>
> Please review the I-D and submit issues and pull requests via the 
> GitHub repository that can be found at:
>
> https://github.com/tlswg/dtls-rrc
>
> Alternatively, you can also send your comments to tls@ietf.org.
>
> Thanks,
> Chris, Joe, & Sean
> ___
> 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] Adoption call for draft-jackson-tls-cert-abridge

[Martin Thomson]

I support adoption.  There are enough short-term performance gains to justify 
this, even without the possibility that it helps with PQ certs.

On Wed, Aug 2, 2023, at 07:17, Stephen Farrell wrote:
> Hiya,
>
> I saw the presentation and scanned the draft and support
> adoption on the basis that this could be useful before
> any certificates using PQC algorithms are in play so the
> target of an experimental RFC is fine, even moreso as I
> could imagine details/codepoints changing over time as
> new better compressions are found.
>
> I could see this also being a valuable input to work that
> aims to evolve PKI in the face of a potential CRQC but I
> think it'd be premature to adopt on that basis alone as
> that overall topic needs broader consideration (best done
> IMO in a year or two and not now). In any case, I guess
> the CCADB doesn't and won't have entries using PQC algs
> for some time, and they might decide to handle things in
> some other way themselves so I'm not sure adopting this
> as a PQ scheme now actually makes sense.
>
> IIUC it's also a bit of a pity that this'd be formally
> limited to the WebPKI, being based on the CCADB. I guess
> handling the pretense that nobody uses letsencrypt for
> smtp/tls is probably better handled as part of another
> discussion elsewhere. (One worth having though.)
>
> Cheers,
> S.
>
>
> On 01/08/2023 20:35, Christopher Wood wrote:
>> Hi all,
>> 
>> Based on positive feedback received during IETF 117, this email begins an 
>> adoption call for "Abridged Compression for WebPKI Certificates" 
>> (draft-jackson-tls-cert-abridge).
>> 
>> The datatracker page for this document can be found here:
>> https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
>> 
>> And the GitHub repository can be found here:
>> https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
>> 
>> Please indicate whether or not your support adoption of this document in its 
>> current state. Procedure questions raised during the WG meeting last week 
>> can be ironed out in the event of this item being adopted.
>> 
>> This call for adoption will conclude on August 16.
>> 
>> Thanks,
>> Chris, for the chairs
>> ___
>> 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
>
> Attachments:
> * OpenPGP_0xE4D8E9F997A833DD.asc
> * OpenPGP_signature

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

Re: [TLS] tls@ietf117

[Martin Thomson]

I wonder whether there are any new insights regarding sslkeylogfile 
standardization.  I know we didn't make much progress last time we asked, but 
it seems like the discussion moved on a little in the time since then.

On Mon, Jul 17, 2023, at 09:22, Sean Turner wrote:
> And another gentle reminder.
>
> Cheers,
> spt
>
>> On Jul 11, 2023, at 10:42, Sean Turner  wrote:
>> 
>> Now that the submission deadline has passed … here’s a gentle reminder!
>> 
>> Cheers,
>> spt
>> 
>>> On Jun 18, 2023, at 19:25, Sean Turner  wrote:
>>> 
>>> The TLS WG is planning to meet at IETF 117. A 2 hour slot has been 
>>> requested, but not yet scheduled. The chairs would like to solicit input 
>>> from the WG for agenda topics. Please send your agenda topics request and 
>>> an estimate for how much time you will need to tls-cha...@ietf.org. Please 
>>> note that we will prioritize existing WG items. Please also review the 
>>> guidance for TLS WG presenters that can be found at [1].
>>> 
>>> Cheers,
>>> Chris, Joe, and Sean
>>> 
>>> [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md
>> 
>
> ___
> 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] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Martin Thomson]

Thanks!  These results are pretty much in line with expectations.

It looks like you don't model packet loss and the effect of that. One concern I 
have is that increases in the number of packets will significantly increase 
exposure to loss. 1-(1-p)^n tends to increase quite a bit as n increases.  p of 
0.02 is a lot more common than people like to think, for which a full 10 packet 
CWND would need retransmissions almost 19% of the time.

Also, RSA is probably OK here, even with the wildly asymmetric CPU costs, but 
the size comparisons would look better with P-256.  Your claim that KDDD is 
faster than errr (errr) might not look as favourable for  (though the 
client cost should increase, I'm not sure if  would be slower).

On Tue, Jun 27, 2023, at 17:49, Thom Wiggers wrote:
> Hi Martin,
>
> As Sofía correctly saw, this is just plain TLS with the 
> "straightforward" DH->KEM and Sig->PQ-Sig substitutions.
>
> I, of course, do have another 50 pages on how KEMTLS performs and 
> compare it to these results, but I will save those for another day ;-)
>
> Cheers,
>
> Thom
> PQShield
>
> Op di 27 jun 2023 om 05:19 schreef Sofia Celi :
>> Hi Martin,
>> 
>> I’m not the author of the note but, as far as I understand, it is not at all 
>> about KEMTLS. The experiments use NIST submitted PQC KEM algorithms for the 
>> key exchange and NIST submitted Signature algorithms for authentication. Not 
>> sure if I would call this a “simpler integration” (as digital signatures are 
>> as complex as KEMs) but, as far as I know, that is not KEMTLS ;)
>> 
>> Thanks,
>> 
>> Sent from the phone
>> 
>> 
>> > On 27 Jun 2023, at 00:56, Martin Thomson  wrote:
>> > 
>> > Hi Thom,
>> > 
>> > I infer - though it is not explicit - that this experiment is based on the 
>> > assumption that KEM-TLS is used, rather than a simpler integration.  Can 
>> > you comment on what you see as the relative impact of that difference?
>> > 
>> >> On Mon, Jun 26, 2023, at 21:48, Thom Wiggers wrote:
>> >> Hi TLS-wg and PQUIP-rg,
>> >> 
>> >> Recently, I have computed the sizes and measured the performance of 
>> >> post-quantum TLS (both PQ key exchange and post-quantum 
>> >> authentication). In these experiments, I have examined combinations of 
>> >> Kyber, Dilithium, Falcon, SPHINCS+-(sf), HQC, and XMSS. The experiments 
>> >> include measuring their performance over two network settings, one 
>> >> high-bandwidth, low-latency and one low-bandwidth, high-latency 
>> >> connection.
>> >> 
>> >> I have examined the instances at NIST PQC security levels I, III and V, 
>> >> and for both unilaterally authenticated and mutually authenticated TLS.
>> >> 
>> >> The report on these experiments (which is basically an excerpt of my 
>> >> PhD thesis manuscript) can be found in the attached document. It's a 
>> >> fairly dense document, so refer to the reading suggestions to easily 
>> >> find what you are looking for.
>> >> 
>> >> It can be found at https://wggrs.nl/post/tls-measurements/handout-tls.pdf.
>> >> 
>> >> I hope this document can be useful to:
>> >> 
>> >> * get a feeling for how we can combine (signature) algorithms to fit 
>> >> their differing roles in the handshake
>> >> * to see how this affects the handshake sizes, and 
>> >> * have some indication of how the performance of these combinations of 
>> >> algorithms is in a TLS stack on a network. 
>> >> * Additionally, I believe my results are useful to compare the cost of 
>> >> different NIST security levels. 
>> >> 
>> >> The experiments do not include SCTs or OSCP staples, but I think that 
>> >> their effect can mostly be extrapolated from the reported results. Also 
>> >> note that I am simulating the network environment, so the effect of the 
>> >> initial congestion window is much less gradual than observed in 
>> >> practice.
>> >> 
>> >> As I write in the document, I want to examine the NIST on-ramp 
>> >> candidates' suitability for use in TLS as soon as the list of 
>> >> algorithms is formally out; for my PhD thesis they unfortunately came 
>> >> into the picture too late.
>> >> 
>> >> Cheers,
>> >> 
>> >> Thom Wiggers
>> >> PQShield
>> >> 
>> >> ___
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> > 
>> > ___
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Post-Quantum TLS instantiations and synthetic benchmarks

[Martin Thomson]

Hi Thom,

I infer - though it is not explicit - that this experiment is based on the 
assumption that KEM-TLS is used, rather than a simpler integration.  Can you 
comment on what you see as the relative impact of that difference?

On Mon, Jun 26, 2023, at 21:48, Thom Wiggers wrote:
> Hi TLS-wg and PQUIP-rg,
>
> Recently, I have computed the sizes and measured the performance of 
> post-quantum TLS (both PQ key exchange and post-quantum 
> authentication). In these experiments, I have examined combinations of 
> Kyber, Dilithium, Falcon, SPHINCS+-(sf), HQC, and XMSS. The experiments 
> include measuring their performance over two network settings, one 
> high-bandwidth, low-latency and one low-bandwidth, high-latency 
> connection.
>
> I have examined the instances at NIST PQC security levels I, III and V, 
> and for both unilaterally authenticated and mutually authenticated TLS.
>
> The report on these experiments (which is basically an excerpt of my 
> PhD thesis manuscript) can be found in the attached document. It's a 
> fairly dense document, so refer to the reading suggestions to easily 
> find what you are looking for.
>
> It can be found at https://wggrs.nl/post/tls-measurements/handout-tls.pdf.
>
> I hope this document can be useful to:
>
> * get a feeling for how we can combine (signature) algorithms to fit 
> their differing roles in the handshake
> * to see how this affects the handshake sizes, and 
> * have some indication of how the performance of these combinations of 
> algorithms is in a TLS stack on a network. 
> * Additionally, I believe my results are useful to compare the cost of 
> different NIST security levels. 
>
> The experiments do not include SCTs or OSCP staples, but I think that 
> their effect can mostly be extrapolated from the reported results. Also 
> note that I am simulating the network environment, so the effect of the 
> initial congestion window is much less gradual than observed in 
> practice.
>
> As I write in the document, I want to examine the NIST on-ramp 
> candidates' suitability for use in TLS as soon as the list of 
> algorithms is formally out; for my PhD thesis they unfortunately came 
> into the picture too late.
>
> Cheers,
>
> Thom Wiggers
> PQShield
>
> ___
> 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] SSL cert - CA issuer question - WIndows Event Reporting CA

[Martin Thomson]

On Wed, May 10, 2023, at 10:36, M K Saravanan wrote:
> When I first access that website, for e.g. https://www.cloudflare.com  
> the issuer CA is shown as “Windows Event Reporting CA”.  

What you have there is known as interception.  Something on your machine 
(Windows Event Reporting maybe) has installed a CA and is intercepting 
connections.

Some people call this bad, or a MitM attack.

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

[TLS] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)

[Martin Thomson]

I like the idea that we might have a more efficient cipher in this particular 
way.  I've been a fan of OCB for that reason for some time.

However, I don't think that QUIC or TLS integration is necessarily a good idea 
for this cipher.  SRTP is one thing, but QUIC and TLS have an entirely 
different structure that might make short tags more risky than otherwise.

DTLS-SRTP has a split structure, with the important key agreement piece being 
done with a full (D)TLS handshake.  The handshake is typically protected with 
ciphers that have strong protections against forgery.  In a context where you 
have signaling or data transfer (like WebRTC data channels), that data is also 
protected by the stronger cipher.  Individual media streams are then protected 
with a different cipher, in SRTP.  For instance, you might protect audio with 
one of the truncated HMAC modes.

Now, setting aside the bit where it is ridiculous to insist on shaving a few 
bytes off packets when you have a multi-megabit video flow alongside, weaker 
protections can be useful.  Authentication is a non-trivial proportion of the 
overall cost of sending audio, especially when you want to keep packet rates 
high to reduce latency.  More so when you consider the potential to have 
multiple layers of protection (SFrame), potentially with different tolerance to 
forgery on each.

Choosing a weak cipher (and we should not pretend that this is anything but 
that) means that any weakness affects everything on a connection.  That isn't 
good for QUIC or TLS.

It might be possible to build a QUIC extension that allowed some data to be 
protected differently than other (perhaps using connection IDs; a popular 
technique).  For me, I'd need something like that for this cipher to find a 
role in QUIC.  To that end, I have no interest in negotiating this cipher for 
use in TLS proper.

Cheers,
Martin

On Tue, May 9, 2023, at 06:53, John Mattsson wrote:
> Hi Christian,
> 
> Yes, sending to the quic list is a good idea. I think QUIC is likely to 
> be used in a huge number of future use cases. Secure short tags might 
> be interesting for more use cases than Media over QUIC.
> 
> Christian Huitema wrote:
>>If the "short tags" can save per packet overhead while maintaining security 
>>properties
>
> The short tags do increase the forgery probability. The security is only
> ideal with respect to the tag length. For general applications like HTTP/3
> I think you would like to keep the forgery probability per packet close to
> the current level.
> 
> In QUIC my understanding is that the maximum plaintext is 2^12 128-bit 
> blocks and the length of the associated data is negligible. The 
> security level of the 128-bit AES-GCM tags is therefore t – log2(n + m 
> + 1) ≈ 128 - 12 = 116 bits.
> 
> With AES-GCM-SST in QUIC you would get ideal forgery probability ≈ 2^-t 
> for tags of length t <= 14 bytes. 
> 
> Cheers,
> John
> 
> *From: *CFRG  on behalf of Christian Huitema 
> 
> *Date: *Sunday, 7 May 2023 at 20:07
> *To: *John Mattsson , IRTF 
> CFRG , sfr...@ietf.org , m...@ietf.org 
> 
> *Subject: *Re: [CFRG] [Moq] FW: New Version Notification for 
> draft-mattsson-cfrg-aes-gcm-sst-00.txt
> John,
>
> You should probably send this to the QUIC list as well. Media over QUIC 
> is just one application of QUIC. If the "short tags" can save per packet 
> overhead while maintaining security properties, then they are 
> interesting for many QUIC applications.
>
> -- Christian Huitema
>
> On 5/5/2023 7:45 AM, John Mattsson wrote:
>> Hi,
>> 
>> We just submitted draft-mattsson-cfrg-aes-gcm-sst-00. Advanced Encryption 
>> Standard (AES) with Galois Counter Mode with Secure Short Tags (AES-GCM-SST) 
>> is very similar to AES-GCM but have short tags with forgery probabilities 
>> close to ideal. The changes to AES-GCM were suggested by Nyberg et al. in 
>> 2005 as a comment to NIST and are based on proven theoretical constructions.
>> 
>> AES-GCM performance with secure short tags have many applications, one of 
>> them is media encryption. Audio packets are small, numerous, and ephemeral, 
>> so on the one hand, they are very sensitive in percentage terms to crypto 
>> overhead, and on the other hand, forgery of individual packets is not a big 
>> concern.
>> 
>> Cheers,
>> John
>> 
>> From: internet-dra...@ietf.org 
>> Date: Friday, 5 May 2023 at 16:33
>> To: John Mattsson , Alexander Maximov 
>> , John Mattsson 
>> , Matt Campagna , Matthew 
>> Campagna 
>> Subject: New Version Notification for draft-mattsson-cfrg-aes-gcm-sst-00.txt
>> 
>> A new version of I-D, draft-mattsson-cfrg-aes-gcm-sst-00.txt
>> has been successfully submitted by John Preuß Mattsson and posted to the
>> IETF repository.
>> 
>> Name:   draft-mattsson-cfrg-aes-gcm-sst
>> Revision:   00
>> Title:  Galois Counter Mode with Secure Short Tags (GCM-SST)
>> Document date:  2023-05-05
>> Group:  Individual Submission
>> Pages:  16
>> URL:
>> 

Re: [TLS] [EXTERNAL] Re: Servers sending CA names

[Martin Thomson]

I think that is also true for NSS, though my experience of this is not 
thorough.  As David notes, client certificates are something of a mess once you 
step outside a context where the client already knows what it should be sending.

On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote:
> Windows TLS stack uses them (when available) for certificate selection. 
> Schannel-based TLS servers don’t send CA names by default, but can be 
> configured to do so.
>
> 
> Cheers,
> 
> Andrei
> 
> *From:* TLS  *On Behalf Of * David Benjamin
> *Sent:* Wednesday, April 12, 2023 2:16 PM
> *To:* tls@ietf.org
> *Subject:* [EXTERNAL] Re: [TLS] Servers sending CA names
> 
> Chrome also uses this to filter the set of client certificates when 
> asking the user to pick one. We also sometimes use this to figure out 
> what intermediates to send, in cases where the server does not already 
> have all its intermediates available. (Though this is not very reliable 
> and OS-dependent. Client certificate deployments are a bit of a mess.)
> 
> Omitting it may be fine in contexts where you expect clients to only 
> have one possible certificate chain and that they have a priori 
> knowledge to only send that one. That can make sense in 
> machine-to-machine communication, and makes less sense when the client 
> is a human that needs to make decisions about identities to use.
> 
> I agree with Viktor that this isn't any more optional in TLS 1.2 than 
> TLS 1.3. Optional and non-empty if present vs. mandatory but may be 
> empty express the same set of states. It's just an encoding difference, 
> motivated by extensibility and client/server symmetry, not changing 
> client certificate expectations.
> 
> On Wed, Apr 12, 2023 at 4:59 PM Viktor Dukhovni  
> wrote:
>> On Wed, Apr 12, 2023 at 08:41:31PM +, Salz, Rich wrote:
>> 
>> > Is this generally used?  Would things go badly if we stopped sending them?
>> 
>> I take you mean sending CA names as part of a certificate request.
>> 
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4
>> 
>> Yes, many servers send a non-empty list of CA names as part of
>> certificate request, and some clients (notably some Java-based clients)
>> fail to complete the handshake if the request does not list an issuer
>> associated with any of the client's available certificates.
>> 
>> So servers historically have been able to get away with an empty list,
>> hoping that the client will then send the only/default certificate it
>> typically has on hand (or not send any, but still continue the
>> handshake).
>> 
>> It looks perhaps like CA name lists are "more optional" in TLS 1.3 than
>> they were in TLS 1.2, but this impression may be just an artefact of the
>> separation of the CA names to a separate extension, rather than an
>> actual change of expected client behaviour.
>> 
>> -- 
>> Viktor.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Martin Thomson]

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:
> https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07
>  
> might be helpful to others.
>
> I opened a few issues, but the TLS 1.3 revision is very much ready to 
> be published.
>
> For the 8447 revision, I found that our decision to remove the 
> definition of the fields for each registry to be difficult.  The draft 
> lists changes, so now this document is no longer an easy reference for 
> how to register TLS extension bits.  Not a big deal and I don't want to 
> ask the authors to flip flop here, but I wanted to flag it.
>
> On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:
>> As mentioned during yesterday's meeting, this email starts the working 
>> group last call for "The Transport Layer Security (TLS) Protocol 
>> Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located 
>> here:
>>
>> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
>> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
>>
>> The WG Last Call will end on April 18, 2023.
>>
>> Please review the documents and submit issues or pull requests via the 
>> GitHub repositories, which can be found at:
>>
>> - https://github.com/tlswg/tls13-spec
>> - https://github.com/tlswg/rfc8447bis
>>
>> Alternatively, you can also send your comments to tls@ietf.org.
>>
>> Thanks,
>> Chris
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] TLS 1.2 deprecation and RFC 7627

[Martin Thomson]

On Sat, Apr 1, 2023, at 20:28, Dmitry Belyavsky wrote:
> Are the things like national-wide standards considered as new features
> (until they don't pretend to be Internet-wide standards)?

I would not expect the IETF to be specifying national standards (that's an 
obvious contradiction anyway).

It is also unnecessary.  The registration policies for TLS registries allow 
people to register extensions without IETF involvement (unless you consider 
IETF-appointed experts), so they should feel free to extend in any way that 
makes them happy.

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

[TLS] TLS 1.2 deprecation and RFC 7627

[Martin Thomson]

Just a thought, but in the discussion of TLS 1.2, we might start to consider 
the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated 
sooner.  RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so 
maybe requiring it (or not supporting TLS 1.2 if that cannot be negotiated) 
offers a short term step toward eventual deprecation, while allowing those who 
find themselves stuck on TLS 1.2 more time to adjust.

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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Martin Thomson]

https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07
 might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to be 
published.

For the 8447 revision, I found that our decision to remove the definition of 
the fields for each registry to be difficult.  The draft lists changes, so now 
this document is no longer an easy reference for how to register TLS extension 
bits.  Not a big deal and I don't want to ask the authors to flip flop here, 
but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:
> As mentioned during yesterday's meeting, this email starts the working 
> group last call for "The Transport Layer Security (TLS) Protocol 
> Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located 
> here:
>
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
>
> The WG Last Call will end on April 18, 2023.
>
> Please review the documents and submit issues or pull requests via the 
> GitHub repositories, which can be found at:
>
> - https://github.com/tlswg/tls13-spec
> - https://github.com/tlswg/rfc8447bis
>
> Alternatively, you can also send your comments to tls@ietf.org.
>
> Thanks,
> Chris
> ___
> 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] WG Adoption call for draft-sbn-tls-svcb-ech

[Martin Thomson]

Adopt.  But please include an example, even if the public key is 
0x010203040506...

On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote:
> At TLS@IETF116, the sense of the room was that there was WG support to 
> adopt draft-sbn-tls-svcb-ech [1].  This message is to confirm the 
> consensus in the room. Please indicate whether you do or do not support 
> adoption of this I-D by 2359UTC on 18 April 2023. If do not support 
> adoption, please indicate why.
>
> Cheers,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/
> ___
> 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] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

[Martin Thomson]

On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the 
> recommended column is reflected in the following statement:
>
> Setting a value to "Y" or "D" in the "Recommended" column requires IETF 
> Standards Action [RFC8126 
> ]. 
> Any state transition to or from a "Y" or "D" value requires IESG 
> Approval."

This is my position, so don't change it :)  John wants to mark a ton of things 
with "D".  I think that a good number of the things he asks for should be 
marked "D", but I wouldn't want an expert to be put in that position.  "Y" and 
"D" are both effective statements because they come with the "authority" of the 
IETF (for what that is worth). To require any lesser process than consensus 
would undermine the value of the label.

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

Re: [TLS] Identify and mitigate tracking and fingerprinting vectors - How to progress

[Martin Thomson]

On Fri, Jan 13, 2023, at 22:56, John Mattsson wrote:
> There are a lot of additional tracking and fingerprinting vectors in 
> the Client Hello and Server Hello.
> 
> - Tracking is also an issue for servers. IoT devices are often servers 
> and by tracking the device you can often track the person owning the 
> device.

This isn't an item in your list, but an expansion of the scope.

> - Ticket reuse is just one example of psk identifier reuse, all psk 
> identifier reuse has the same client and server tracking considerations.
> - Client reuse of key shares can be used to track the client. Server 
> reuse of key shares can be used to track the server or to reveal the 
> server name.


Just to be clearer about your implicit threat model, I assume that you are 
assuming that this is a scenario where the same client and server are 
establishing a connection, but that addressing and timing don't reveal any 
information about their identity.  In that context, repetition of identifiers 
from a previous connection might allow an observer to correlate the two 
sessions.

Tickets and key shares are easy: don't do that.  We already say that though, so 
nothing to do, except perhaps to point out where implementations ignore that 
advice.

> - SNI can be used to track a server and most SNI (except very common 
> ones) can be used to track a client.

This is what ECH is intended to address.

> - Non-common values of max_fragment_length, supported_groups, 
> signature_algorithms, application_layer_protocol_negotiation, etc. can 
> be used to track a client with high probability.
> - The set of extentions in CH or SH might be used to track client or 
> server with high probability. The fingerprinting vector does not need 
> to be globally unique. An attacker often looks in a specific location, 
> in a specific network, and at a specific time. Can also be correlated 
> with fingerprints at other layers.

This is a harder question.  Some of these are protected by ECH, some are not.  

(Threat model question: Are we now protecting against tracking by the other 
endpoint?)

FWIW, there seems to be another implicit assumption in this list that needs to 
be expanded.  The values that a client or server offers here is governed by 
some combination of the code it executes, the configuration of that endpoint, 
and the inputs it receives.

Differences in code is something I have personally given up on.  There are 
reasons that you might prefer to eliminate apparent differences between 
implementations, but this is likely somewhere between hard and impossible.  If 
you consider the fingerprinting risk profile as a product of the entire 
networking stack, you need to eliminate differences across the entire stack, 
from the hardware up to the application.

There are a finite number of implementations, so the entropy provided by 
implementation variations should be small.  Furthermore, synchronizing 
fingerprints with another implementation is possible only up until the point 
that both implementations remain the same.  It only takes a new feature 
addition in one implementation to undo this.

That doesn't mean that eliminating any gratuitous differences might not 
eventually help by reducing the number of discrete fingerprints.  That's 
specification work though.  For instance, we could all agree that padding is no 
longer needed, so that we can all remove that extension from ClientHello.  But 
consider the fingerprinting risk inherent in your choice of congestion 
controller.  Do you really expect people agree on all of those details such 
that you might eliminate any differences - and potential competitive advantage 
- between products?

Configuration and other live inputs tend to produce variation that is 
observable.  The best choice for configuration is to not allow it.  That's a 
general trend now, but see above regarding eliminating choice and control.

Live input is harder.  If the input is provided by a peer, then the attitude 
we've taking in browsers is to only apply any corresponding change when 
communicating with that peer; otherwise, you are exposed to tracking by that 
entity.  But that leads to leaking this change in peer identity toward the 
network.

The best reaction I have here is to say that for ClientHello, any change in 
configuration/behaviour should be in the part protected by ECH; in comparison, 
for ServerHello, don't; move it to EncryptedExtensions instead. If this is not 
possible, reconsider the feature.  The only things that can't be protected by 
ECH are those things that relate to key configuration, which are effectively a 
lower layer of the protocol. Those lower-layer functions require more care.

For instance, if we were to move key share configuration to DNS, so that 
clients can guess the right key share to provide, then that might work, but 
we'd need to be careful to ensure that the configuration is consistent on the 
same level as the ECH configuration.  Otherwise, it partitions the 

Re: [TLS] Profile ID in CTLSServerPlaintext

[Martin Thomson]

On Fri, Jan 6, 2023, at 01:46, Ben Schwartz wrote:
> In Datagram cTLS (as of -07), this is not possible.  The parsing of 
> handshake messages depends on prior knowledge of who is the client and 
> who is the server.  This is because CTLSServerPlaintext and 
> CTLSClientPlaintext are different structs, but they use the same 
> ContentType.

This text is probably worth adding to the draft then.  That's a fairly clear 
explanation and the information is somewhat valuable.

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Martin Thomson]

On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote:
> use of FFDHE with large key sizes is the best protection against
> store-and-decrypt-later attacks 

This doesn't deprecate use of FFDHE in TLS 1.3, for which we have some 
ludicrously large named groups.  Is that not enough?

> If anything, RSA key exchange should be deprecated first.
> RFC 8446 deprecated only the DSA ciphersuites, not RSA.

This is an odd statement.  TLS 1.3 ciphersuites no longer include the concept 
of key exchange or signing.

If you are talking about the signing part, both were sort of deprecated.  
RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only usable within the 
certificate chain, not in the protocol.  PSS was added back.

However, for key exchange, which is more relevant to this conversation, RSA was 
indeed removed.  And the draft we're discussing does indeed say that RSA key 
exchange in TLS 1.2 is deprecated.

Can you help me better understand the scope of your objection?

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Martin Thomson]

On Tue, Dec 20, 2022, at 09:34, Carrick Bartle wrote:
>> You might need to clarify that TLS 1.1 and earlier are wholly deprecated 
>> though, just to be sure.
>
> We do mention that in the body of the document. Are you suggesting that 
> we also add that to the abstract and intro?

Oh yeah, three times even.  I was looking for it in the introduction.  Though 
that intro is getting a little lengthy.  I'll leave it to your judgment.

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Martin Thomson]

On Sun, Dec 18, 2022, at 04:33, Yaron Sheffer wrote:
> Yes, this is clear to people on this thread. My comment was just about 
> the document, which IMO should define its scope more clearly and early 
> on. 

The title and abstract and introduction could say "TLS 1.2" and the document 
would be fine.  You might need to clarify that TLS 1.1 and earlier are wholly 
deprecated though, just to be sure.

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

Re: [TLS] [EXTERNAL] Re: Call for adoption of draft-thomson-tls-keylogfile

[Martin Thomson]

I personally have no intention of making this PS (or to otherwise water down 
recommendations against it).

I do have some interest in doing what can be done to make this less of a 
hazard.  You will see that I took John's suggest to more directly proscribe its 
use: https://github.com/martinthomson/sslkeylogfile/pull/1

One benefit of moving this under IETF change control is that we can have those 
conversations about how to manage this better.  To Stephen's point, the idea 
that you might negotiate an extension when this is enabled is an interesting 
one.  I don't think that it needs to be large in order to have the intended 
effect (if the intended effect is punitive in nature, then that creates certain 
disincentives around compliance).  There are many cases where I think it would 
be beneficial to have the presence of this known to both entities.  The 
challenge of course is that this is primarily of benefit to the client only - 
the server cannot unilaterally signal that it has this machinery engaged.

(Another thing to note is that the qlog work in the QUIC working group has 
lesser, but broadly similar properties.  It would be good to share what we 
learn from this exercise.)

On Tue, Nov 29, 2022, at 03:22, Andrei Popov wrote:
> Does an Informational draft require WG adoption? If the goal isn't to 
> switch to the Standards track, I have no concerns.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: TLS  On Behalf Of Ilari Liusvaara
> Sent: Monday, November 28, 2022 11:11 AM
> To: TLS List 
> Subject: [EXTERNAL] Re: [TLS] Call for adoption of 
> draft-thomson-tls-keylogfile
>
> On Mon, Nov 28, 2022 at 07:02:20PM +, Andrei Popov wrote:
>> 
>> I oppose adoption of draft-thomson-tls-keylogfile. The stated goal was 
>> to find a permanent, discoverable location for this document, other 
>> than NSS project's repository. Perhaps it's fine to create an RFC for 
>> this purpose, but then I'd argue that it should be an Informational 
>> RFC.
>
> The I-D has: "Intended status: Informational" (for some reason the 
> datatracker is unable to determine this).
>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7C4d4695c5433c4186eed608dad17465a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052595136932049%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0WqfX2eGL7cXMwCbYEOegEEnpRNXtdyFcDC3QBjMOe8%3D=0
>
> ___
> 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] sslkeylogfile

[Martin Thomson]

Thanks for the input John,

I agree on both points, the minor one and the substantive one.

https://github.com/martinthomson/sslkeylogfile/pull/1  is my attempt to put 
something stronger about usage/applicability up front.  Do you think that is 
sufficient?

On Thu, Nov 24, 2022, at 21:37, John Mattsson wrote:
> Hi,
> 
> Two high level comments:
>
>
> - OLD: "though use of earlier versions is strongly discouraged [RFC8996]"
> 
> That is not what RFC 8996 says. RFC 8996 says
> 
> - "TLS 1.1 MUST NOT be used."
> - "TLS 1.1 MUST NOT be used."
> 
> Please change to something that aligns with RFC 8996 such as
> 
> NEW: "though use of earlier versions is forbidden [RFC8996]"
> 
> 
> -  "Access to the content of a file in SSLKEYLOGFILE allows an attacker
>to break the confidentiality protection on any TLS connections that
>are included in the file."
> 
> This is true but does not at all reflect the implications of the 
> existence of a file for long-term storage of keys like this. Storing 
> any of the keying material like this completely breaks the stated 
> forward secrecy property of TLS 1.3 as it creates new long-term keys. 
> It does not matter how well the file is protected i.e.,
> 
>"Ensuring adequate access control on these files therefore becomes
>very important."
> 
> is not enough. The theoretical security properties are still broken 
> badly. I think this draft is problematic, but I can understand the need 
> to standardize this existing format. I think the fact that 
> SSLKEYLOGFILE breaks the security properties of TLS 1.3 needs to very 
> clearly described. As a consequence, I think the only allowed use case 
> standardized by TLS WG should be limited to non-production debugging. 
> If governments and companies wanting visibility do other things, that 
> would be outside of IETFs control.

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

Re: [TLS] DTLS 1.3 Sequence number reconstruction?

[Martin Thomson]

QUIC uses approximately the same basic approach as DTLS does, with the same 
ambiguity.  The example [1] makes a choice, but in practice it doesn't matter.  
This only happens for two numbers that are very far from the expected sequence 
number.  50% odds of making a wrong choice probably doesn't matter for packet 
numbers well outside the anti-replay window (which will be treated as a replay 
anyway).

[1] https://quicwg.org/base-drafts/rfc9000.html#sample-packet-number-decoding 

On Fri, Oct 28, 2022, at 12:22, Andy Cunningham wrote:
> Hi, 
>
> I've a query on the reconstruction of the sequence number from the DTLS 
> 1.3 specification:
> https://www.rfc-editor.org/rfc/rfc9147.html#name-reconstructing-the-sequence
> 
> "If the epoch bits match those of the current epoch, then 
> implementations SHOULD reconstruct the sequence number by computing the 
> full sequence number which is numerically closest to one plus the 
> sequence number of the highest successfully deprotected record in the 
> current epoch."
> 
>
> Using the text above with the following example.
> Current Highest deprotected record = Top of Window (ToW) = 0x_01B2, 
> Adding one we get 0x_01B3
> If the "expected" Seq num transmitted was 0x_0133 and S=0, we will 
> just observe 0x33 in the DTLS header.
>
> There are three potential candidates for 0x33 which we can predict 
> based on the specification above:
> A)  0x_0233
> B)  0x_0133
> C)  0x_0033
>
> The absolute delta between the candidates and the highest successfully 
> deprotected record plus one is:
> A)  0x_01B3 - 0x_0233 = ABS(-0x80) = 128 decimal  candidate?>
> B)  0x_01B3 - 0x_0133 = ABS(0x80) = 128 decimal < potential 
> candidate?>
> C)  0x_01B3 - 0x_0033 = ABS(0x180) = 384 decimal  candidate>
>
> As you can see from above, we have two predictions which are 
> numerically closest to the ToW plus one. 
> I don't think it's possible to select the correct value when using the 
> approach recommended in the RFC. 8(
>
> Should the standard be amended to use something like the IPSEC 
> reconstruction scheme which takes the bottom of the window into account?
> https://www.rfc-editor.org/rfc/rfc4303#page-40
>
> Regards
> Andrew
>
>
>
> -- 
> "The large print giveth, and the small print taketh away"
> ___
> 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] HRR delenda est (was Re: Published RFC 8446bis -05)

[Martin Thomson]

On Thu, Oct 27, 2022, at 09:23, Martin Thomson wrote:
> On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote:
>> Idea
>
> We're not short on ideas (your idea is not new).  We're short on the 
> willingness to implement and deploy them.

I should apologize here.  Ilari's idea is - I think - a relatively good one.  
However, I don't think that a lack of ideas is the issue here.  It might have 
been Stephen that first mentioned this idea, which got some traction.  At the 
time, and since then, the problem continues - such as it is - without much 
engagement on what I think is the harder part: getting people interested in 
deploying a fix.

>From my view, HRR is awkward, but it is used enough for me to be confident 
>that it isn't broken in practice.  Proofs of TLS 1.3 also make me confident 
>that it is secure (with the usual caveats).  So it's a case of "ain't broke".

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

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Martin Thomson]

On Thu, Oct 27, 2022, at 00:01, Ilari Liusvaara wrote:
> Idea

We're not short on ideas (your idea is not new).  We're short on the 
willingness to implement and deploy them.

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

Re: [TLS] sslkeylogfile

[Martin Thomson]

On Tue, Oct 25, 2022, at 16:48, Peter Gutmann wrote:
> But it's not the same thing, it only seems to cover some TLS 1.3 extensions.
> Thus my suggestion to call it "Extensions to the SSLKEYLOGFILE Format for TLS
> 1.3".

That's not the intent.  Section 3.2 covers all you need for TLS 1.2.

I did not describe the (deprecated) "RSA" key, is that in common usage?  Or, 
are there things that I have missed?  I got everything from 
https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html
 but maybe that is no longer the best reference.

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

Re: [TLS] sslkeylogfile

[Martin Thomson]

On Tue, Oct 25, 2022, at 16:09, Peter Gutmann wrote:
> Well at the moment the web page defines what's used in practice and the spec
> defines... something?  A hope for the future?  An extension to the current
> usage?

The exact same thing, just using different words and style.

The intent is to provide a better, more stable reference.  For instance, the 
NSS page has moved a few times recently.  I'm not sure that all links have been 
updated, nor can I guarantee that firefox source docs will remain stable.  And 
citing firefox source docs is awkward for some.

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

[TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Martin Thomson]

On Tue, Oct 25, 2022, at 13:57, Stephen Farrell wrote:
> Is there any public info as to how often HRR happens?
> (Sorry if that's well known, but it's not well known to
> me:-)
>
> Were that rare enough, I'd hope it'd be a thing where we
> could reach consensus for deprecation. If it's not yet
> sufficiently rare, it might be worth considering if we
> could change something to make HRR less likely.

I don't think that it is that simple.  Right now, we're at an equilibrium 
point, where most clients and servers have moved toward a common set of 
algorithms for key exchange.  In future, I expect that we'll see increased use 
of HRR as we move to new equilibria.  One of these is likely coming with a move 
to a PQ KEM.

Removing HRR might be possible if we look at putting more stuff in DNS or 
something along those lines, but that would require a bunch of care and 
preparation.  That's effort that - at least to me - might be better spent 
elsewhere.

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

Re: [TLS] sslkeylogfile

[Martin Thomson]

On Tue, Oct 25, 2022, at 13:19, Peter Gutmann wrote:
> Martin Thomson  writes:
>
>>I just posted https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
>
> This looks like some variant of
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format
> but I'm not sure what it is or what form it takes.  Is it an extension of that
> for TLS 1.3?  If it is then the form looks quite different from the existing
> one.

In form, this differs a fair bit, but the content should be the same.  I didn't 
copy over the long-deprecated "RSA" key, but otherwise it should be the same 
format.

Maybe the web page is easier to consume, but a spec needs to be a little more 
precise in definition.

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

[TLS] sslkeylogfile

[Martin Thomson]

I just posted https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
Latest HTML: 
https://martinthomson.github.io/sslkeylogfile/draft-thomson-tls-keylogfile.html

It's annoyed me for some time that the NSS team has been responsible for 
maintaining this fairly important piece of documentation.  It seems like this 
group might be a good place to document that.  So I spent an hour.

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

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

[Martin Thomson]

The integrity of TLS doesn't depend on the key holder presenting proof of 
possession toward the issuing CA.  Perhaps we could define an extension that 
produced an empty signature, so that it could be used for any algorithm without 
these complications...

On Wed, Oct 5, 2022, at 03:05, Russ Housley wrote:
> Uri:
>
> You cannot do it with PKCS#10.  That is why CRMF (RFC 4211) was 
> created.  RFC 2875 and RFC 6955 talk about the proof-of-possession 
> (PoP) of 2875 Diffie-Hellman keys.  A similar PoP specification will be 
> needed for Kyber, and some folks agreed to write the -00 version before 
> IETF 115 (nudge).
>
> Russ
>
>
>> On Oct 4, 2022, at 11:05 AM, Blumenthal, Uri - 0553 - MITLL 
>>  wrote:
>> 
>> TL;DR
>> Need to create a CSR for a key pair whose algorithm does not allow signing 
>> (either because it’s something like Kyber, or because restriction enforced 
>> by HSM). How to do it?
>> 
>> Longer version:
>> 
>> There are several use cases that require certifying long-term asymmetric 
>> keys that are only capable of encryption/decryption – but not 
>> signing/verification. That could be either because the algorithm itself does 
>> not do signing, or because the private key is generated and kept in a secure 
>> hardware that enforces usage restriction. 
>> 
>> One example of a protocol that needs this is KEMTLS - which I hope is 
>> accepted, either as-is, or with simplification.
>> 
>> CSR is supposed to be signed by the corresponding private key to prove 
>> possession. Obviously, it cannot be done with a key such as described above. 
>> How is this problem addressed in the real world?  With AuthKEM and KEMTLS, 
>> how would these protocols get their certificates?
>> 
>> A short discussion of this issue on the OpenSSL mailing list brought up 
>> Certificate Management Protocol (CMP) and CRMF format. Is that where we're 
>> heading? Are the "big CAs" on board with it?
>> 
>> Thanks!
>> -- 
>> V/R,
>> Uri
>
> ___
> 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] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
> As X25519 is not FIPS-approved, the lab won't be able to test it, 

OK, hypothetical question, but maybe an important one.

Why would a certification lab care?  We compose secrets with non-secrets all 
the time, so even if X25519 were replaced with a public value, as long as Kyber 
is approved, can they not proceed to certify on the basis of the strength of 
the Kyber algorithm and its implementation?

Or, more realistically, maybe the composition method can be approved, just as 
composing a secret with "chickenchickenchicken" can be rendered safe.  That 
way, composing with an arbitrary primitive might be considered safe if the 
composition method is approved.

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

On Thu, Aug 18, 2022, at 22:39, Scott Fluhrer (sfluhrer) wrote:
> Actually, that was our original intention with this draft - to specify 
> the framework, and to have other documents specify the actual pairs.  
> However, I believe that the sense of the working group is that they 
> want this draft to start with a limited number of options (and people, 
> please correct me if I'm wrong).

I'm saying that that is not a good idea.  Drafts are cheap, and this one is 
done.  If that is counter to the sentiment of the working group, then so be it.

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

On Sat, Aug 13, 2022, at 04:13, Scott Fluhrer (sfluhrer) wrote:
> Well, if we were to discuss some suggested hybrids (and we now know the 
> NIST selection), I would suggest these possibilities:
>
> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768

Any specific pairs of primitives should be specified in a different document to 
this one.

Ultimately, I want fewer choices, but the direction the discussion is headed 
seems about right.  At least in the short term, I think we need to eschew 
compression and only include one offer.  Partly because I think that there 
might be better options available to us than compression, partly because 
compression will be annoying to implement correctly, and partly because we're 
still in the phase where this is being trialed.

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

Re: [TLS] What is "completed handshake"?

[Martin Thomson]

On Tue, Aug 9, 2022, at 17:49, Ben Smyth wrote:
> A handshake partially completes on sending/receiving a server's Finished 
> message

I don't see this as "partially complete", the way I frame this is that a server 
can send prior to the completion of the handshake under some conditions.  The 
same applies to early data where a client can send prior to the completion of 
the handshake under some other conditions.  In the first case, the conditions 
are largely self-imposed, whereas the latter has some protocol-level 
constraints.

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

Re: [TLS] What is "completed handshake"?

[Martin Thomson]

On Tue, Aug 9, 2022, at 16:36, Ben Smyth wrote:
> On Mon, 8 Aug 2022 at 15:21, Töma Gavrichenkov wrote:
>> "Upon receiving the server's messages, the client responds with its 
>> Authentication messages, namely Certificate and CertificateVerify (if 
>> requested), and Finished. At this point, the handshake is complete"
>
> I stumbled with this. 

That seems clear enough to me.  At least from the client's perspective.  
Presumably the server has to receive the client's Finished to consider the 
handshake complete.

> OpenJDK reports handshake completion twice.

My first reaction there was "yikes!".  But on a second read, that's not so bad. 
 The (sometimes) second signal to the client on receiving NewSessionTicket is a 
bit weird, but aside from being a bit odd, it's documented, so that's on them.  
It's weird, but as long as clients are aware of the strangeness, it seems like 
the risks are contained.  Even when clients aren't, the risk is that the client 
does something two times, but then the prevalence of NewSessionTicket means 
that clients are highly likely to encounter the second signal and notice any 
problems it causes.

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

Re: [TLS] [Technical Errata Reported] RFC8446 (7073)

[Martin Thomson]

This is correct, though I would have extended this to say ", except for 
post-handshake authentication, which uses keys derived from the current 
[sender]_application_traffic_secret_N." or similar.

On Sat, Aug 6, 2022, at 23:03, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7073
>
> --
> Type: Technical
> Reported by: Ben Smyth 
>
> Section: 4.4
>
> Original Text
> -
> These messages are encrypted under keys derived from the 
> [sender]_handshake_traffic_secret.
>
> Corrected Text
> --
> These messages are encrypted under keys derived from the 
> [sender]_handshake_traffic_secret, except for post-handshake 
> authentication
>
> Notes
> -
> There's an exception
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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] Representing IP addresses in SNI -- proposed draft

[Martin Thomson]

Please don't define an "extended SNI".  A new extension to signal the target IP 
address would be fine.  Keep it narrowly focused.

Having a separate extension might allow the DDR client to express both the SNI 
and the IP it is seeking.

A separate expected certificate extension is another, separate, separable idea 
that can have its own extension.

However...Both of these need ECH protection.  Which means new ECH parameters.  
I'm not sure that I like that idea very much.


On Fri, Jul 29, 2022, at 09:50, Erik Nygren wrote:
> I was thinking about the new extension idea more.  It has the downside 
> of potentially being an API change in client/server TLS stacks,
> but opening this up might generally be worth considering.  If we added 
> an "Extended SNI" extension to support IPAddress,
> we might also want to consider if there are other things worth adding.
>
> Also including an Extended SNI option for "Certificate Fingerprint" 
> would solve a bunch of issues
> that have come up from time-to-time.  For example, it might help with 
> DANE.
>
> We've also talked in the past about being able to include a certificate 
> fingerprint 
> in URIs, and being able to signal that in Extended SNI would likely 
> make that work better.
> (A use-case for this is for using TLS in local/private network 
> environments such as to 
> home network devices or even localhost processes where being able to 
> have a URI
> with an {IP,cert_fingerprint(s)} pairing would have better security 
> properties than trying
> to use some global PKIX framework.)
>
> Is this something worth considering or that others in the WG might be 
> interested in?
>
> Erik
>
> 
>
>
>
> On Wed, Jul 27, 2022 at 4:16 PM David Benjamin  wrote:
>> I agree this is quite a compatibility risk. In addition to messing with SNI 
>> lookup, there are servers that try to correlate TLS SNI and HTTP Host. 
>> Indeed, when we accidentally sent IP literals in SNI, we broke a server that 
>> tried to do that but got very confused by the colons in an IPv6 literal. 
>> That server would likely also be confused by this draft, less by syntax and 
>> more by SNI/Host mismatch. I would be surprised if this option were viable.
>> 
>> Another option, which doesn't require redefining existing fields, is to 
>> simply allocate a new extension. Though I agree with Martin that one would 
>> expect the server to know its own IP. If you implicitly interpret a missing 
>> server_name extension as "I want the IP cert for this connection's IP", it's 
>> already unambiguous. Granted, there may be edge cases because missing 
>> server_name can also mean "I want the default cert" and perhaps your 
>> "default" cert and IP cert are different.
>> 
>> On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson  wrote:
>>> Hi Erik,
>>> 
>>> As far as it goes, this might work.  However, I'm not sure about the effect 
>>> of this on compatibility.  I'm concerned that maybe this would end up 
>>> causing some servers to choke.  Servers that receive SNI can sometimes use 
>>> that SNI value to lookup the correct certificate.  Your design could have 
>>> those servers searching for a certificate that doesn't exist.
>>> 
>>> Anything along these lines would need to be tested for compatibility - 
>>> extensively - before it could even be trialed.
>>> 
>>> (I never saw the DDR as having deployment problems along these lines.  It 
>>> isn't THAT hard to know your own IP address for that purpose.)
>>> 
>>> On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
>>> > Following discussions in ADD around the DDR draft (as well as in UTA
>>> > around Martin Thomson's PR to add IP address SANs to 6125-bis),
>>> > I wrote up a draft on how IP addresses might be represented in SNI:
>>> >
>>> >   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>>> >
>>> > There are at least three different ways we could do it, but this draft
>>> > proposes what seems to be the least bad while also talking about the 
>>> > other alternatives.  (I suspect we'd want to move the alternatives 
>>> > to an appendix or remove entirely from a final version.)
>>> >
>>> > Is this interesting to the working group?
>>> > While IP address SANs have a bunch of corner cases and gaps,
>>> > they do seem to be picking up new uses.  
>>> >
>>> > What motivated me to realize we need to solve this is that 
>>> > draft-ietf-add-ddr uses IP SANs in a

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Martin Thomson]

Hi Erik,

As far as it goes, this might work.  However, I'm not sure about the effect of 
this on compatibility.  I'm concerned that maybe this would end up causing some 
servers to choke.  Servers that receive SNI can sometimes use that SNI value to 
lookup the correct certificate.  Your design could have those servers searching 
for a certificate that doesn't exist.

Anything along these lines would need to be tested for compatibility - 
extensively - before it could even be trialed.

(I never saw the DDR as having deployment problems along these lines.  It isn't 
THAT hard to know your own IP address for that purpose.)

On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
> Following discussions in ADD around the DDR draft (as well as in UTA
> around Martin Thomson's PR to add IP address SANs to 6125-bis),
> I wrote up a draft on how IP addresses might be represented in SNI:
>
>   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>
> There are at least three different ways we could do it, but this draft
> proposes what seems to be the least bad while also talking about the 
> other alternatives.  (I suspect we'd want to move the alternatives 
> to an appendix or remove entirely from a final version.)
>
> Is this interesting to the working group?
> While IP address SANs have a bunch of corner cases and gaps,
> they do seem to be picking up new uses.  
>
> What motivated me to realize we need to solve this is that 
> draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the 
> client connecting to an IP address and expecting to see a SAN
> (where returning a cert associated with the IP address containing
> a SAN that the client connected to is straight-forward),
> DDR has clients connecting to a different IP and then
> expects to find an original IP also in the SAN list.  
> This means that for an ISP with a large number of IPs
> (or using a services who operates DoH service on-behalf
> of many entities), you'd need to quickly/wastefully burn through IPv4 
> addresses to enable a unique cert per original IP.
>
> Erik
>
>
> -- Forwarded message -
> From: 
> Date: Wed, Jul 27, 2022 at 2:20 PM
> Subject: New Version Notification for draft-nygren-tls-ip-in-sni-00.txt
> To: Erik Nygren mailto:erik%2bi...@nygren.org>>, 
> Rich Salz 
>
>
>
> A new version of I-D, draft-nygren-tls-ip-in-sni-00.txt
> has been successfully submitted by Erik Nygren and posted to the
> IETF repository.
>
> Name:   draft-nygren-tls-ip-in-sni
> Revision:   00
> Title:  Representing IP addresses in TLS Server Name Indication 
> (SNI)
> Document date:  2022-07-27
> Group:  Individual Submission
> Pages:  7
> URL:
> https://www.ietf.org/archive/id/draft-nygren-tls-ip-in-sni-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-nygren-tls-ip-in-sni
>
>
> Abstract:
>This specification provides a mechanism for clients to send IP
>addresses in a TLS Server Name Indication (SNI) extension as part of
>TLS handshakes, allowing servers to return a certificate containing
>that subjectAltName.  This is done by converting the IP address to a
>special-use domain name.
>
>
>
>
> The IETF Secretariat
>
>
> ___
> 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] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 22:21, Kampanakis, Panos wrote:
> Why are 2-3 packet CHs unworkable?

Loss probability is a contributing factor for sure, but the thing that really 
hurts is the extra round trip that many servers will induce when they cannot 
process the TLS ClientHello in one go.

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

Re: [TLS] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 11:42, Blumenthal, Uri - 0553 - MITLL wrote:
> What are the implications for environments that require NIST Sec Level 3 or 5?

Poor performance.  By which I mean increased exposure to packet loss and 
additional round trips.  For instance, in QUIC servers might be forced to use 
Retry, which adds a round trip.

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

Re: [TLS] PQC key exchange sizes

[Martin Thomson]

On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote:
> Be interested in how that'd change the CH if ECH is used too.
> I guess the answer mightn't make us happy;-)

PQ HPKE would not fit, but the Kyber-512 numbers mean that we should be OK for 
ECH if we stuck with classical security.  For obvious reasons, that might not 
be OK though.

If we wanted a PQ HPKE (or a Hybrid KEM) then ECH would blow out the size so 
that we would end up with multiple packets for the CH.  That would be basically 
unworkable from a performance perspective.

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

[TLS] Extensibility in SCVP draft

[Martin Thomson]

Take this:

struct {
 PathValidationType path_validation_type;
 select (path_validation_type) {
  case scvp: SCVPValidationRequest;
 } request;
} PathValidationRequest;
enum { scvp(1), (255) } PathValidationType;

This adds a layer of extensibility that doesn't do a lot.  Please consider 
making this less generic.  If we want a different validation design, then 
another extension can be defined.  We have a poor track record of being able to 
use these nested extension points and it will be more efficient to just put the 
SCVP pieces in their own extension.

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

On Sat, Apr 30, 2022, at 00:24, Douglas Stebila wrote:
> Thanks for the feedback Martin.  I see what you're getting at regarding 
> phrasing it in terms of KeyGen[i], Encaps[i], etc.  This is a good 
> point:
>
>>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the 
>>> concatenation of the key_exchange field for each of the constituent 
>>> algorithms. 
>> 
>> I think that this text is a mistake as it implies that the component key 
>> exchange algorithm has a defined key_exchange format.  What you want is a 
>> definition in the form above, or as HPKE has it.
>
> Indeed it makes sense to be able to define a hybrid key exchange method 
> independent of whether the all of the component algorithms are already 
> defined standalone key exchange methods in TLS 1.3.  I do however want 
> to tie back somehow to the idea that, *if* one of the algorithms is 
> already defined as a key exchange method in TLS 1.3, then the value 
> that should be put in the key share concatenation is just the key share 
> that was used when it was a standalone method.  Is that okay?

Definitely.  It's just that - for now at least - it seems very likely that some 
of the component algorithms will not be standalone key exchange methods (or 
groups).

>> With something like this, I'd like to see the implication that the TLS key 
>> schedule is changed by this draft can be removed (in Section 3.3 
>> specifically).
>
> I don't read Section 3.3 as implying that the TLS key schedule is 
> changed.  It says how one of the inputs to the key schedule is 
> computed, but otherwise I think it's just saying: put this concatenated 
> value into the obvious place in the existing key schedule.  Can you 
> point me to where you read it as implying more changes to the TLS key 
> schedule?

The diagram of the key schedule (which really needs a figure number) is quite 
obviously a diff.  Apart from that piece, it's probably OK.

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Martin Thomson]

I found the introduction of KeyGen, Encaps, and Decaps to be underutilized.  It 
would require a little work, but I think that it would be better to describe a 
method whereby you produce each of these functions by taking an ordered 
collection of these functions (KeyGen[i], Encaps[i], and Decaps[i]) and 
constants (Npk[i], Nek[i], etc...).

With something like this, I'd like to see the implication that the TLS key 
schedule is changed by this draft can be removed (in Section 3.3 specifically).

In essence, you are describing a known-good process for composing key exchange 
methods.  (Not existing TLS 1.3 key exchange methods, as implied by this:

> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the 
> concatenation of the key_exchange field for each of the constituent 
> algorithms. 

I think that this text is a mistake as it implies that the component key 
exchange algorithm has a defined key_exchange format.  What you want is a 
definition in the form above, or as HPKE has it.

I'd prefer to see this work done before publication, but as I'm not able to 
volunteer to do it, I can't really insist on it.  This is useful work and the 
document, despite these niggles, is pretty clear and well-reasoned.

On Thu, Apr 28, 2022, at 01:27, Christopher Wood wrote:
> This email commences a two week WGLC for draft-ietf-tls-hybrid-design, 
> located here:
>
>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> We do not intend to allocate any code points at this time and will park 
> the document after the call is complete. Once CFRG produces suitable 
> algorithms for consideration, we will then add them to the NamedGroup 
> registry through the normal process [1] and move the document forward.
>
> Please review the draft and send your comments to the list. This WGLC 
> will conclude on May 13.
>
> Best,
> Chris, for the chairs
>
> [1] 
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> ___
> 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] Adoption call for draft-salowey-tls-rfc8447bis

[Martin Thomson]

One additional bug I noticed:

Exporter Value  | Recommended |
|-|
client finished | Y |
server finished | Y |
master secret   | Y |
key expansion   | Y |

These should probably be 'D', based on the note in RFC 5705 (which oddly, 
references itself in the equivalent of third person here):

   Note: (1) These entries are reserved and MUST NOT be used for the
   purpose described in RFC 5705, in order to avoid confusion with
   similar, but distinct, use in RFC 5246.

On Thu, Feb 24, 2022, at 08:41, Martin Thomson wrote:
> Adopt.
>
> I found the changes from 8447 hard to find without a diff:
>
> https://www.ietf.org/rfcdiff?url1=rfc8447=draft-salowey-tls-rfc8447bis-01
>
> Some comments on the content:
>
> * Recommended = D requires standards action.  I think that you might 
> want IETF consensus instead.
>
> * A lot of the "changes" here have already been carried out.  Perhaps 
> this document can be a lot shorter.  I still think that the generic 
> text is useful to keep, but there are sections that concentrate only on 
> stuff that has already been done by IANA.  Maybe those sections can go.
>
> * This cites a specific draft version of TLS 1.3 rather than RFC 8446 
> and I can't see why.
>
> On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
>> Hi folks,
>>
>> Following up on the TLS WG meeting in IETF 112 and draft update in 
>> December, this email begins an adoption call for 
>> draft-salowey-tls-rfc8447bis, located here:
>>
>>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>>   
>> This adoption call will last for two weeks. Please reply to this email 
>> by March 4 indicating whether you think this document should be adopted 
>> and worked on by the WG.
>>
>> Thanks,
>> Chris
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

[Martin Thomson]

Adopt.

I found the changes from 8447 hard to find without a diff:

https://www.ietf.org/rfcdiff?url1=rfc8447=draft-salowey-tls-rfc8447bis-01

Some comments on the content:

* Recommended = D requires standards action.  I think that you might want IETF 
consensus instead.

* A lot of the "changes" here have already been carried out.  Perhaps this 
document can be a lot shorter.  I still think that the generic text is useful 
to keep, but there are sections that concentrate only on stuff that has already 
been done by IANA.  Maybe those sections can go.

* This cites a specific draft version of TLS 1.3 rather than RFC 8446 and I 
can't see why.

On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
> Hi folks,
>
> Following up on the TLS WG meeting in IETF 112 and draft update in 
> December, this email begins an adoption call for 
> draft-salowey-tls-rfc8447bis, located here:
>
>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>   
> This adoption call will last for two weeks. Please reply to this email 
> by March 4 indicating whether you think this document should be adopted 
> and worked on by the WG.
>
> Thanks,
> Chris
>
>
> ___
> 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] I-D Action: draft-ietf-tls-snip-01.txt

[Martin Thomson]

On Wed, Feb 23, 2022, at 09:31, Ben Schwartz wrote:
> In TLS, I think "MUST" means "recipients should validate this if 
> possible and fail the handshake if there is a mismatch".  Consider a 
> client implementation.  Upon receipt of a SNIP response, is it supposed 
> to cross-check the SNIP answer vs. the ALPN offer, and fail if there is 
> intersection?  This seems needlessly complicated.

So this "MUST/SHOULD omit compatible protocols" is really only there to do as 
David suggests: reduce variation.  I don't think that we need it for 
correctness.  I'm inclined to loosen this to a SHOULD.

It's a little awkward in the sense that clients and servers might disagree 
about what protocols are compatible.  That is - for QUIC at least - we allow 
for compatibility to be defined separately from the protocol, which means that 
some implementations might believe that a protocol is compatible when it is 
not.  This leads to clients including things in ALPN that the server might also 
include in SNIP.

https://github.com/tlswg/snip/pull/9

Ben's point about ALPN is well-taken though.  This very much does assume that 
ALPN is in use.  Indeed, it makes very little sense without it.  So I'm going 
to suggest that we mandate it directly:

https://github.com/tlswg/snip/pull/8

As for the appendix, I wonder if it is better left out entirely.  I almost cut 
it last time, and this discussion makes me think that might be the easiest way 
out.  There are some philosophical differences here that we should probably 
continue to discuss, but we don't need to resolve them if we agree about the 
conclusion (which is to do this validation in TLS and not rely on DNSSEC).

https://github.com/tlswg/snip/pull/10

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

Re: [TLS] tlsflags and "responses"

[Martin Thomson]

On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote:
> I think (but don't have a solid recollection) that this may have 
> stemmed from a desire for the sender to know if the recipient supports 
> flags at all.  But thinking about it now (and as Ekr's response 
> suggests), so long as we don't allocate flags for existing extensions, 
> there is not much useful to do with that information in cases where the 
> extension semantics of the flag(s) in question don't require a response.

Wouldn't it be possible to send the extension with an empty set of flags?  We 
don't permit trailing zero bytes, but a zero-length sequence indicates support 
without signaling for any specific flag.

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

[TLS] tlsflags and "responses"

[Martin Thomson]

I missed this text in draft-ietf-tls-tlsflags:

   A server that supports this extension and also supports at least one
   of the flag-type features that use this extension and that were
   declared by the ClientHello extension SHALL send this extension with
   the intersection of the flags it supports with the flags declared by
   the client.  

While sloppy on my part [1], I want to make it clear that this is a 
show-stopper for me. Requiring an echo prevents a flag extension from attaching 
semantics to a "response".

I agree with Ilari's earlier point that these should work just like extensions. 
 If the server has no need to echo a flag, it should not be required to do 
that.  That allows the flag value in a "response" to carry semantics.

Cheers,
Martin

[1] I missed this in the second WGLC, though in my defense, I don't think the 
resolution and changes resulting from the first WGLC were very clearly 
communicated.

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

Re: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

[Martin Thomson]

On Thu, Feb 17, 2022, at 07:25, Sean Turner wrote:
> Right now the I-D exclusively mentions TLS. The fix might be as easy as 
> a global replace of TLS with (D)TLS. Can anybody think of a reason to 
> preclude DTLS?

I just checked and our implementation (thanks again Chris P) works and is 
tested with DTLS.

I don't think that there is *much* reason to use this in WebRTC, but that 
shouldn't stop someone from doing that[1].

Cheers,
Martin

[1] If someone does want to use this in WebRTC, let me know and I'll make sure 
we offer the extension there; we're still not on a final version of DTLS 1.3 
there, which is only available in Nightly builds, so you won't get much use out 
of it for a while.

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Martin Thomson]

On Wed, Feb 16, 2022, at 22:26, Ilari Liusvaara wrote:
> I think the language in tlsflags about acknowledging extensions is
> confusing. Tlsflags behavior should be similar to extensions, which do
> not have acknowledgment requirement in base TLS (any acknowledgement
> requirement is per extension). So I think any acknowledgement
> requirement should be explicitly stated normatively.

I agree with Ilari here.  We shouldn't need to acknowledge this extension.  
And, as far as I can tell, the flags draft doesn't require it (though I admit 
that the text there on binary AND is confusing).

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

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

[Martin Thomson]

Hey everyone,

This is a keep-alive update for the most part.

I spent an hour or so trying to do improve the readability of the draft.  So it 
will look like a lot has changed as I rewrote large chunks, removed a fair bit, 
and moved whole sections.  All of that is with a goal of making the content 
more accessible.  Happy to hear how people feel that went and how it might be 
improved further.

Cheers,
Martin


On Wed, Feb 16, 2022, at 16:30, internet-dra...@ietf.org wrote:
> 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   : Secure Negotiation of Incompatible Protocols in TLS
> Author      : Martin Thomson
>   Filename: draft-ietf-tls-snip-01.txt
>   Pages   : 12
>   Date: 2022-02-15
>
> Abstract:
>An extension is defined for TLS that allows a client and server to
>detect an attempt to force the use of less-preferred application
>protocol even where protocol options are incompatible.  This
>supplements application-layer protocol negotiation (ALPN), which
>allows choices between compatible protocols to be authenticated.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-snip/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-snip-01.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-snip-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

Re: [TLS] Revised hybrid key exchange draft

[Martin Thomson]

I am not convinced that the extra effort is justified.

However, I am convinced that the proposed construction is complex.

combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
data=1||F(k1)))
H1(k) = H('derive1' || k)
H2(k) = H('derive2' || k)
F(m) = 
H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)
for m = m1||m2||...||mn and j =~ 3

It's nice that this is a dual PRF; that's something I think we've wanted for a 
number of other reasons in TLS.  I might have preferred a more efficient option 
though.

Comparing that to k1 || k2 means - for me - this needs much stronger 
justification.  

Perhaps if the CFRG were to standardize a dual (or multi) PRF that were more 
efficient I would be more favourably inclined toward its inclusion - in a 
revision of the core specification.

The nice thing about the hybrid draft is that it isn't a firm commitment to any 
particular combination method.  Each new key exchange "group" can define its 
own combination method.  It only suggests a method.  So I don't agree that 
"[m]issing this opportunity would effectively further embed the problem" (or 
maybe "effectively" is doing a little too much work there).

On Wed, Jan 19, 2022, at 22:21, Nimrod Aviram wrote:
> Hi Everyone,
>
>
> As Douglas wrote, we have discussed the issues together at length, and 
> we thank him for the productive (and friendly :-)) conversation.
>
>
> Our paper, which describes our concerns, can be found here: 
> https://eprint.iacr.org/2022/065
>
> And a reference implementation of our proposed KDF: 
> https://github.com/nimia/kdf_reference_implementation/blob/main/kdf_reference_implementation.py#L60
>
>
> A few points from our side:
>
> Firstly, our proposed construction is simple to implement (see the 
> Python code above), and adds a modest overhead of a few microseconds 
> (see the paper).
>
>
> Re: point a) from Douglas’ first mail: Admittedly, our concerns are 
> broader than Hybrid Key Exchange in TLS. However, we view the 
> standardization of Hybrid Key Exchange as an opportunity to add defense 
> in depth. Missing this opportunity would effectively further embed the 
> problem. We don’t see another such opportunity on the horizon: If we 
> standardize a TLS extension in a few years, getting everyone to deploy 
> the extension would be hard. Whereas here everyone has to deploy the 
> new thing anyway, so we might as well make it as robust as we can.
>
>
> Consider the following: SHA-1 weaknesses to collisions were first 
> really highlighted in 2005. TLS version 1.0 was standardised in 2006 
> and hardcoded the use of SHA-1, and MD5 (admittedly, for use in HMAC). 
> TLS 1.2 was standardised in 2008, and formal deprecation of SHA-1 
> occurred in 2011 by NIST. The standard deprecating the use of SHA-1 in 
> TLS 1.2 digital signatures occurred in 2021. In 2016, TLS support 
> (according to Qualys SSL Labs SSL survey) was over 90%. In 2020, TLS 
> 1.0 support was still above 50%, despite practical chosen-prefix 
> collision attacks against SHA-1 being possible. Being robust against 
> future threats when given the option is something that we should 
> seriously take time to consider.
>
>
> As to ekr’s response that the standard already states we need a 
> collision-resistant hash function: Brendel et al. [1] proved that the 
> TLS 1.3 ECDHE handshake survives losing the collision resistance of the 
> hash function, as long as HKDF retains its pseudorandomness property. 
> However, HKDF does not provably possess this property to begin with, 
> with respect to the (EC)DH shared secret input, since this input is fed 
> as the message input to HMAC, and HMAC/HKDF is not a dual PRF.
>
>
> To summarize, we recommend using our new proposed construction. It’s 
> fast, easy to implement, and provides provable security. We see no 
> reason to entrench a problem if we’re already changing the protocol in 
> this area, and requiring implementation changes anyway.
>
>
> Best,
>
> Nimrod, Ben, Ilan, Kenny, Eyal, and Eylon
>
>
> [1] https://www.felixguenther.info/publications/ESORICS_BreFisGun19.pdf
>
>
>
>
> On Tue, 11 Jan 2022 at 21:08, Douglas Stebila  wrote:
>> Hello TLS working group,
>> 
>> We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1].  
>> Based on revision requests from the last draft, the main change is removing 
>> the unnecessary appendix of the past design considerations, and a few 
>> wording changes.
>> 
>> Last September, Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny 
>> Paterson, Eyal Ronen, and Eylon Yogev posted a note [2,3] with some concerns 
>> about whether the approach for constructing the hybrid shared secret in this 
>> document -- direct concatenation -- was risky in a scenario where the hash 
>> function used in TLS key derivation and transcript hashing is not collision 
>> resistant.  Nimrod and his colleagues exchanged many emails with us over the 
>> past few months 

Re: [TLS] Revised hybrid key exchange draft

[Martin Thomson]

I was operating under the assumption that inputs to concatenation were fixed 
length.  It seems that the attack mentioned did not.  It seems like that is a 
far simpler way of achieving that goal.  

That is, it seems to be sufficient to state that assumption as a requirement.

Constructing a length-prefixed encoding would work if we thought that 
supporting variable length secrets was a good idea.  We could even do that on a 
per-secret basis, adding a length only when needed.  However, I can't think of 
any way in which a variable length input would be advisable. So I'm going to 
recommend that we stick to fixed lengths.  As Douglas notes, there aren't any 
primitives under consideration that want a variable-length secret once the 
parameters are decided.

That TLS is vulnerable in the event of a collision will remain, even if we fix 
this, so while I'm not happy that our defense is that thin, the four conditions 
here on the second attack are each layers in that defense.  Short timeouts mean 
that the massive computation involved in even SHA-1 collisions seems unlikely.  
Ephemeral key reuse is already advised against fairly strongly.  We try to 
choose strong key agreement methods.  And inputs are fixed length (or 
unambiguously encoded if deemed to be necessary).

Cheers,
Martin

On Wed, Jan 12, 2022, at 08:01, Eric Rescorla wrote:
> Hi Douglas,
>
> 8446 already says:
>
>Note that HKDF-Expand implements a pseudorandom function (PRF) with
>both inputs and outputs of variable length.  In some of the uses of
>HKDF in this document (e.g., for generating exporters and the
>resumption_master_secret), it is necessary that the application of
>HKDF-Expand be collision resistant; namely, it should be infeasible
>to find two different inputs to HKDF-Expand that output the same
>value.  This requires the underlying hash function to be collision
>resistant and the output length from HKDF-Expand to be of size at
>least 256 bits (or as much as needed for the hash function to prevent
>finding collisions).
>
> With that said, defense in depth is good. Does it help to have just a 
> structured input, e.g.,
>
> opaque KeyInput<0..2^16-1>;
>
> struct {
>KeyInput inputs<2..2^16-1>;
> } KeyScheduleInput;
>
>
>
> -Ekr
>
>
> On Tue, Jan 11, 2022 at 11:08 AM Douglas Stebila  wrote:
>> Hello TLS working group,
>> 
>> We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1].  
>> Based on revision requests from the last draft, the main change is removing 
>> the unnecessary appendix of the past design considerations, and a few 
>> wording changes.
>> 
>> Last September, Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny 
>> Paterson, Eyal Ronen, and Eylon Yogev posted a note [2,3] with some concerns 
>> about whether the approach for constructing the hybrid shared secret in this 
>> document -- direct concatenation -- was risky in a scenario where the hash 
>> function used in TLS key derivation and transcript hashing is not collision 
>> resistant.  Nimrod and his colleagues exchanged many emails with us over the 
>> past few months to help us understand their concerns.  In the end we think 
>> the concerns are low and we have not made any changes in this draft, 
>> although if we receive different guidance from the working group, we'll do 
>> so.
>> 
>> There were two types of concerns that Nimrod and his colleagues identified 
>> [2,3]:
>> 
>> a) An attacker who can find collisions in the hash function can cause 
>> different sessions to arrive at the same session key.  This concern is 
>> largely independent of this hybrid key exchange draft, as it focuses on 
>> collisions in the transcript hash, and affects existing TLS 1.3 even without 
>> this draft being adopted.  If the TLS working group thinks this is a concern 
>> that should be addressed, it seems like it should be addressed at the 
>> overall level of TLS 1.3, rather than for this specific hybrid key exchange 
>> draft.
>> 
>> b) An attacker who can find collisions in the hash function and has a 
>> certain level of control over the first of the two shared secrets in the 
>> hybrid shared secret concatenation may be able to carry out an iterative 
>> attack to recover bytes of the second shared secret.  The iterative is 
>> similar to the APOP attacks [4,5] and also somewhat similar to the CRIME 
>> attack [6].  After discussing further with Nimrod and his colleagues, we 
>> identified that the following conditions need to be satisfied for this 
>> attack:
>> i) Chosen-prefix collisions can be found in the hash function within 
>> the lifetime of the TLS handshake timeout of the victim.
>> ii) The victim reuses ephemeral keying material several hundred 
>> times and for a time lasting at least as long as the time for part (i) of 
>> the attack.
>> iii) The attacker can learn or control the value of the first shared 
>> secret in the hybrid shared secret concatenation.
>>   

Re: [TLS] Two final DTLS 1.3 issues

[Martin Thomson]

These are both disruptive changes, but I agree that they are OK in principle.

I have a few questions on #257.  Those are on the PR, but I'll repeat them here:

Many implementations of DTLS use a 16-bit integer to hold epoch. Sometimes, 
that leaks into places that mean that it is hard to change.

Those of us with this problem can probably pull the same trick as here and only 
expose the low 16 bits, but would it be possible to implement this without 
allowing key updates that take epoch to 2^16?

If the epoch can have 64 bit values, then why not allow for the full range of 
values to be used? Is there an analysis that suggests that rekeying too often 
leads to this problem?  (Similarly, the 2^48 limit on the sequence number makes 
little sense in this context.)

It would be good to highlight the fact that #262 can result in transcript 
collisions between DTLS and TLS (with the exception of maybe supported_versions 
because we're now using the inverted encoding ...for no good reason?  or for 
this specific reason?).

However, even though the transcript that is input to HKDF might be the same, 
true problems arising from a collision are avoided because all key derivations 
use a different label with HKDF.  That means that we depend on using 
HKDF-Expand-Label for key diversity between DTLS and TLS, so any use of keys in 
either protocol has to pass through at least one invocation of that function.  
Only the early secret doesn't meet this condition, so I'm not worried, but it 
needs to be noted (and it isn't).

On Thu, Jan 6, 2022, at 13:34, Christopher Wood wrote:
> Hi folks,
>
> As discussed during IETF 112, there are two outstanding DTLS 1.3 issues 
> with proposed resolutions:
>
> - https://github.com/tlswg/dtls13-spec/pull/257: This resolves the 
> epoch limit issue. It received external review from cryptographers and 
> the authors have confidence in the change.
> - https://github.com/tlswg/dtls13-spec/pull/262: This aligns the DTLS 
> 1.3 transcript with that of TLS 1.3. 
>
> We'd like to run a brief consensus call on these proposed resolutions. 
> Please chime in if you'd like to see changes of any kind. Absent 
> objections, we'll merge them and proceed with the remaining RPC edits. 
>
> This call will close on Friday, January 14.
>
> Best,
> Chris, for the chairs
>
> ___
> 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] IANA Registry for TLS-Flags

[Martin Thomson]

On Tue, Dec 14, 2021, at 01:47, Salz, Rich wrote:
>>How about we split the difference and go with the first 0-15 flags for 
>> standards action? We can keep the initial value of 8 for 
>> cross-sni-resumption since that document is going through the process. (We 
>> could also make it 7 or lower so we're not wasting an empty octet for this 
>> flag, should folks want to go that route.)
>
> Works for me.

Two bytes it is.  PR updated.

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

Re: [TLS] IANA Registry for TLS-Flags

[Martin Thomson]

On Wed, Dec 8, 2021, at 08:32, Salz, Rich wrote:
> As one of the current designated experts, I’d rather there were almost 
> no room for judgement or subjectivity in assignments.

This is part of why I think that Rich is an excellent choice of designated 
expert :)  Judgment is what we have the working group for.

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

Re: [TLS] ECH - handling retry config with different public name?

[Martin Thomson]

I assume that you might add "just once" there.  Or at least a limited number of 
times.  Infinite regress seems like something worth avoiding.  outer1 -> outer2 
-> outer1 is likely not a great outcome.

On Sat, Nov 6, 2021, at 02:20, David Benjamin wrote:
> That's my inclination as well. It's an odd thing for a server to do, 
> but it seems fine to just retry with the new config without much fuss?
>
> On Fri, Nov 5, 2021 at 10:18 AM Stephen Farrell 
>  wrote:
>> 
>> Hiya,
>> 
>> Bit of a corner case I'm not sure about. Apologies
>> if this has come up before.
>> 
>> The scenario:
>> 
>> - inner SNI is inner.example
>> - ECHConfig from inner.example's DNS has outer.example
>>as public_name
>> - client authenticates with ClientHelloOuter and the
>>ServerHello contains retry_configs with one ECHConfig
>>that has a public_name of another.example
>> - client decides to retry and a similar thing happens
>>(authenticates with ClientHelloOuter) but this time
>>with public_name of yetanother.example
>> - rinse/repeat until the client is fed up with retries
>>or manages to authenticate using ClientHelloInner if
>>ECH eventually works
>> 
>> My question is: should the client care about those
>> changes in public_name or not? I think the answer is
>> "not" but wanted to check.
>> 
>> Ta,
>> S.
>> 
>> 
>> 
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] tls@ietf112

[Martin Thomson]

Hey Sean, what is "Zero-Knowledge Proofs meet TLS"?  I can't find a draft and 
the link in the agenda is busted.

On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote:
> Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from 
> 1600-1800 (UTC). Please send in your agenda topics along with how much 
> time you think you will need to tls-cha...@ietf.org by 26 October 2021 
> (early is better).
>
> Cheers
> Chris, Joe, and Sean
> ___
> 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] Artart last call review of draft-ietf-tls-external-psk-guidance-03

[Martin Thomson via Datatracker]

Reviewer: Martin Thomson
Review result: Ready with Issues

This document addresses some of the less obvious aspects of how pre-shared keys
can be used in TLS.  A lot of this advice isn't specific to TLS, but it is a
helpful document.  For someone who might be deploying a protocol that relies on
TLS - or might rely on it - the document is a useful resource.

My only concern overall, and it is a vague concern, so I don't think action is
needed, is that the document could probably use a little trimming.  There are
some parts of the document that are less useful than other parts.  For example,
the bit about who has the PSKs is great (one server, one client, don't swap
roles); but it is repeated a little across multiple sections.  The same applies
to a few of the other points.  It is probably not worth trying to edit the
document down so that each point is made just once, because it isn't that bad,
but a shorter document would be more impactful.

A specific concern is the somewhat offhand way that early data is treated.  The
only mention is in a throwaway: "primarily for the purposes of supporting TLS
connections with early data" buried in a bullet in Section 6.  This is a pretty
big topic and having absolutely no mention seems odd.  I do think that it needs
some treatment in the document.  When early data is used with an external PSK,
the only additional source of entropy that provides key diversity is the
client's random value, which puts a lot of weight on that value containing
sufficient entropy.  In this case, even if the PSK is good enough, the entropy
in the random is significant as it is what ensures traffic key diversity if the
PSK is reused.  Reusing a PSK for early data also likely leads to poor
anti-replay performance if the random is not good enough.

I have to apologize to the authors for missing this when it went through the
working group.  Fresh eyes and all that.


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

Re: [TLS] Late DLS 1.3 issue

[Martin Thomson]

I left a comment, but I don't think that the fix, as it is specifically 
proposed, works.

The general shape of the proposal seems credible.  A larger epoch space, of 
which we only send the least-significant bits, would seem to address the 
concern.  But the proposal doesn't specify what to do with the per-record nonce.

If we go with a 48-bit epoch we get a few more records (2^32 times as many I 
suppose), which is probably enough.  And the value would fit in the per-record 
nonce.  Then you just need a bunch more text that explains how to encode that 
nonce.

A 64-bit epoch doesn't fit in any nonce we currently use.  We could truncate, 
which would need more analysis (my intuition is that it would be OK, but I'd 
like more than a gut feeling).  We might use the expanded nonce options that 
some (not all) AEAD ciphers have, but that would be a very bad idea.

Anyhow, this is all independent of how annoying this will be to implement.  
This change is likely to be VERY disruptive to our implementation.  From 
memory, we have exposed an epoch size through interfaces that we can't change.  
Has anyone looked at making the proposed changes in a serious implementation?

On Wed, Oct 6, 2021, at 10:14, Christopher Wood wrote:
> Hi folks,
>
> There's one late breaking issue we need to resolve for DTLS 1.3 before 
> it proceeds to publication:
>
>https://github.com/tlswg/dtls13-spec/issues/249
>
> Based on discussions with some people involved in the security analysis 
> of TLS 1.3, a proposed fix is here:
>
>https://github.com/tlswg/dtls13-spec/pull/255
>
> We'd like to merge this to resolve the issue and continue forward 
> progress. To that end, please review the issue and change and indicate 
> whether or not it is workable for you. Barring objections, we'll merge 
> the PR on Friday, October 15. 
>
> Best,
> Chris, for the chairs
>
> ___
> 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] =?UTF-8?Q?Re:__FYI, _a_subverted_implementation_attack_against_TLS_a?= t ia.cr/2020/1452

[Martin Thomson]

I don't think that this is a particularly important result.  The formalism is 
perhaps valuable, but the intuition is not novel: if you control an endpoint 
and it can send messages, those messages can contain information.  There are 
far too many places in almost any protocol where information can be placed for 
exfiltration.

Just looking at random nonces isn't going change anything here.  Those are just 
the easy choice.  Message size and timing contains information.  Ordering of 
extensions or options contains information.  GREASE contains information.

That Signal was hard is interesting, but I don't think that the authors were 
sufficiently creative.  They say "these low-bandwidth attacks cannot be used to 
leak the short-term, ephemeral keys", but I don't think that is true at all.  
I'll leave it as an exercise for the reader, but I believe it to be trivial to 
have all keying material available to the observer if an endpoint is 
cooperative.

The idea that you might somehow design your way into a protocol that has no 
exfiltration capability is a nice academic exercise, but any such protocol 
would be completely impractical.

On Thu, Aug 26, 2021, at 00:26, Dan Brown wrote:
> Dear TLS list,
> 
> FYI, ICYMI,
> 
> Berndt et al. describe a subverted implementation attack against TLS
> https://eprint.iacr.org/2020/1452
> I just noticed this report today and don't remember seeing it mentioned 
> on the TLS list already.  It seems to be worth at least considering.
> 
> A summary and brief discussion:
> 
> The subverted TLS implementation (IIUC) uses server randoms (nonce) to 
> quickly exfiltrate the server's signing key - so it could be 
> characterized as proof of concept instance of a well-known idea, 
> kleptography, (but please correct this summary if necessary, since it 
> is only based on a skimming of the report).
> 
> Granted: it is difficult (impossible?) to thwart all subverted 
> implementation attacks. But this attack is easier than others in that 
> category, so might be notable.
> 
> This general issue with public random nonces has been discussed on TLS, 
> for example:
> https://mailarchive.ietf.org/arch/msg/tls/56N_-KDN0LuWyEvAhmFnm7g8p6A/
> This past discussion led to a recommendation to use different RNGs for 
> the public random versus the DH secrets, but I don't see how that would 
> be enough to stop this attack.
> 
> In reviewing the TLS archive (from the thread above), I see that the 
> general difficulty of thwarting subverted implementations has also 
> already been raised. Basically, this argues that the best solution is 
> to prevent subversion of implementations in the first place, and that 
> making the protocol robust against subverted implementations is 
> hopeless and wasteful. Maybe that's right.  (Maybe part of this 
> anti-subversion defense would be separating the server keys, e.g. in a 
> separate signing module, from the rest of the implementation?  Maybe 
> some TLS servers already do this.)
> 
> >From the abstract of the attack report:
> "... We show that these protocols can be easily subverted by carefully 
> placing ASAs. Our analysis shows that careful design of ASAs makes 
> detection unlikely while leaking long-term secrets within a few 
> messages in the case of TLS ..., allowing impersonation attacks. ..."
> 
> The attack report also says that forward secrecy makes an 
> implementation inherently more vulnerable to this attack.  I didn't 
> look at the details, but I suspect that this is because ephemeral 
> public keys can also be filtered by hashing, e.g. a Simmons subliminal 
> channel,  - but this is presumably more costly, and more detectable?
> 
> The attack report has a section on Countermeasures and Design Lessons, 
> the most general countermeasure is to re-design the protocol not to 
> send freely random nonces, which I agree with, since it is so simple.  
> They also suggest requiring time-stamps to prevent replay attacks, (in 
> case re-used ephemeral keys).
> 
> Best regards,
> ​
> Dan Brown
> 
> --
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> Attachments:
> * smime.p7s

___
TLS mailing list
TLS@ietf.org

[TLS] Intolerance for delegated credentials

[Martin Thomson]

Hey,

We've found a server that is intolerant of our offer to use delegated 
credentials.  This seems to run a modern nginx and TLS 1.3, but it is not 
producing the same handshake keys as us, so I can't tell if it supports the 
extension or not (as the EncryptedExtensions message is indecipherable).  The 
TLS stack is unknown, but as it supports ARIA, CAMELLIA, and CCM_8 (!) that 
might narrow things down a little.

Is anyone deploying delegated credentials that I'm not aware of?  Or has the 
codepoint assignment (34) run afoul of an experiment we're not aware of?

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

Re: [TLS] RFC8447bis

[Martin Thomson]

On Thu, Aug 19, 2021, at 23:14, Salz, Rich wrote:
> I understand this concern. I am sympathetic to it. But perhaps 
> large-scale experiments on the whole Internet aren't the scope here?  
> Those kinds of things seem to ask for an early allocation. I am 
> thinking, in particular, of some GOST/TLS identifiers that weren't 
> quite right.

Nothing wrong with due diligence before allocation, or even a little reticence. 
 But I'm also concerned about people putting these ranges in their code and 
doing something special with them.  Like "this is experimental, so we will 
ignore these always" or similarly silly things.  You don't need to have a 
reserved space to say that a particular codepoint is temporary.

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

Re: [TLS] RFC8447bis

[Martin Thomson]

On Thu, Aug 19, 2021, at 12:30, Sean Turner wrote:
> The primary reason we are proposing this approach is that it seemed to 
> us to be a bit more explicit about the numbers in this space being part 
> of an experiment. The added benefit here is that we are in some sense 
> greasing the bits too.

I understand.  It's just that, as I said...

> > Experiments, particularly large-scale ones, turn into deployments.  
> > Consequently the difference between "an experiment" and "a standard" is the 
> > date at which you look.  See also RFC 6648.

That is, when you mark this space out, you are saying that it's special.  
People might try to treat it as such, but it won't be once a few experiments 
get successful.

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

Re: [TLS] RFC8447bis

[Martin Thomson]

On Wed, Aug 18, 2021, at 11:31, Eric Rescorla wrote:
> I'm a bit less sure about randomly versus sequentially, but I could go 
> either way. IIRC the QUIC thing leaned somewhat on the space being very 
> big.

That is true.  QUIC has a large space, but TLS is a lot smaller.  This is just 
my attempt to avoid a repeat of the extension 26 mess.

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

Re: [TLS] RFC8447bis

[Martin Thomson]

I don't think that this approach is the best we could do.

Experiments, particularly large-scale ones, turn into deployments.  
Consequently the difference between "an experiment" and "a standard" is the 
date at which you look.  See also RFC 6648.

In that light, why not use the entire unassigned space for experiments?  A 
registry policy that allowed allocations for experiments, but marked those 
entries as temporary (the word "provisional" is usual here) would suffice.  
Reclaiming these codepoints might be more challenging than the draft makes out; 
the expiration time you have in the draft is fine, though I expect that any 
dates will be roundly ignored if code is still shipping.

The point of a registry is to avoid collisions and the interoperability 
failures that follow.  So I would also add that all new allocations (experiment 
or otherwise) should draw from the unassigned space at random, rather than 
sequentially.  That should minimize collisions up until the point where we have 
exhausted the space.

I would also prefer to have no space reserved for private use (though a very 
small space is tolerable).

(It shouldn't be a surprise, but I'm advocating for the same general approach 
that QUIC took.)

On Wed, Aug 18, 2021, at 09:34, Christopher Wood wrote:
> Hi folks,
> 
> Based on discussing regarding draft-ietf-tls-hybrid-design during IETF 
> 111, it became clear that we need some mechanism to deal with 
> temporary, experimental codepoints for testing out new features. To 
> that end, Sean and Joe recently published this draft:
> 
>https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00
> 
> This document obsoletes RFC8447 and updates a number of other relevant 
> documents. The main changes in this document are:
> 
> - Experimental codepoint policy and process 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-17)
> - Updated Recommended registry values 
> (https://datatracker.ietf.org/doc/html/draft-salowey-tls-rfc8447bis-00#section-5)
> 
> Please review the document, especially if you have thoughts about the 
> experimental policy. Assuming there are no major objections, I'd like 
> to propose that we proceed with the proposal to get things started.
> 
> Thanks,
> Chris
> 
> ___
> 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] WGLC for draft-ietf-tls-cross-sni-resumption

[Martin Thomson]

This document is mostly fine.

The text on use of client certificates isn't particularly clear.  The key piece 
of information that a reader is going to need is that a resumed connection will 
include any (and potentially all) client authentication.

I found the meat of the flag definition hard to follow.  There is a lot of 2119 
language, but very little of it relates to the operation of this extension.  
Some is just restatement of RFC 8446, which comes with real risks and should be 
avoided.  I think that what this needs to say is:

1. What the protocol mechanism is: (a flag in NST)
2. What sending that signal means.  For example, "The flag is an assertion from 
the server that all servers that answer to the names in the certificate are 
able to use this ticket."
3. What the client might do with that.  For example, "If a client would accept 
the certificate for a new connection, it can/MAY attempt resumption even if the 
server name differs from the server name of the original connection." <- that 
might be the only 2119 language you need in the entire document, though I'm not 
sure you even need that.

Then talk about consequences (this is currently in Security Considerations and 
is mostly good, though not all of this belongs in a section with that title):

1. What if the server is wrong in its assertion.   For example, "A server that 
wrongly advertises this flag could cause clients to waste tickets on connection 
attempts where resumption will not be successful."
2. Why the server might choose not to do this: need to coordinate across a 
deployment, it could be wrong, certificate bloat, key compromise scope, etc... 
(the existing text on this is fine)
3. What the client needs to consider before exercising this option (tracking -> 
partitioning, client authn)

On Sat, Jul 17, 2021, at 09:55, Christopher Wood wrote:
> This is the working group last call for the "Transport Layer Security 
> (TLS) Resumption across Server Names" draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/
> 
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
> 
> https://github.com/vasilvv/tls-cross-sni-resumption
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> ___
> 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] WGLC for draft-ietf-tls-flags

[Martin Thomson]

I think that this is largely good.

I don't like how the IANA registry is structured and would like to discuss it 
more.  I think that it is 0-31 (Standards Action), 32+ (Specification 
Required), but it doesn't say that.  I think that the experimental range 
(64-79) should not be reserved.  That's relatively valuable space that is being 
effectively burned forever.  It is also highly dependent on judgment of 
experts, which gives those experts far more say in the use of the registry than 
is typical.

(It also says that the registry is initially empty in S2, but it then defines a 
flag.)

On Sat, Jul 17, 2021, at 09:55, Christopher Wood wrote:
> This is the second working group last call for the "A Flags Extension 
> for TLS 1.3" draft, available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> 
> Please review this document and send your comments to the list by July 
> 30, 2021. The GitHub repository for this draft is available here:
> 
> https://github.com/tlswg/tls-flags
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> ___
> 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] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Martin Thomson]

On Sat, Jul 31, 2021, at 06:25, Carrick Bartle wrote:
>  are you opposed to fully deprecating FFDHE? If so, why?

No so much opposed as that it is not necessary.  Though the TLS 1.2 variant is 
- as others have noted - close to impossible to negotiate the "good" groups, 
it's not concretely bad when you use it in TLS 1.3.

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Martin Thomson]

I support the *contents* of this document.  The title, however, I can't agree 
to.  So I want to be clear about the scope of the work, namely deprecating 
semi-static FFDH and ECDH suites and any use of FFDHE ephemeral suites with 
reused keys.

The draft limits the ban on ephemeral key reuse to FFDHE, which is right; I 
could tolerate a prohibition on reuse for ECDH, but I know that we rely on that 
for HPKE and other things, so it can't really be bad enough to ban.

Cheers,
Martin

On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> This is a working group call for adoption for Deprecating FFDH(E) 
> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 
> ). 
> We had a presentation for this draft at the IETF 110 meeting and since 
> it is a similar topic to the key exchange deprecation draft the chairs 
> want to get a sense if the working group wants to adopt this draft 
> (perhaps the drafts could be merged if both move forward).  Please 
> review the draft and post your comments to the list by Friday, August 
> 13, 2021.  
> 
> Thanks,
> 
> The TLS chairs
> ___
> 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] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Martin Thomson]

On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> This is a working group call for adoption of Deprecating Obsolete Key 
> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00 
> ). 
>  There was support for adopting this draft at the IETF 111 meeting.  Please 
> review the draft and post your comments to the list by Friday, August 13, 
> 2021.  

Yep, let's do it.  There were comments suggesting that this wasn't going to 
work for some deployments yet.  That's OK, that's how this works: we decide to 
deprecate, discuss and publish a document, then people get to work out how they 
change their deployments.  If we don't take that first step, then in many ways 
things don't get better.  Adopting this is that first step and a good idea.

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

Re: [TLS] Adoption call for "Secure Negotiation of Incompatible Protocols in TLS"

[Martin Thomson]

On Fri, Jul 30, 2021, at 04:20, Christopher Wood wrote:
> Based on positive feedback during this week's meeting, we'd like to 
> start an adoption call for "Secure Negotiation of Incompatible 
> Protocols in TLS." The document may be found here:
> 
>https://datatracker.ietf.org/doc/draft-thomson-tls-snip/

Yeah, I think we should do this.  Just in case there was any doubt.

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