Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions

[Andrei Popov]

I support adoption.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Watson Ladd
Sent: Friday, April 26, 2024 7:13 PM
To: Devon O'Brien 
Cc: tls@ietf.org; Bob Beck 
Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions

On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien 
 wrote:
>
> After sharing our first draft of TLS Trust Expressions and several 
> discussions across a couple  IETFs, we’d like to proceed with a call for 
> working group adoption of this draft. We are currently prototyping trust 
> expressions in BoringSSL & Chromium and will share more details when 
> implementation is complete.
>
>
> As we mentioned in our message to the mailing list from January, our primary 
> goal is to produce a mechanism for supporting multiple subscriber 
> certificates and efficiently negotiating which to serve on a given TLS 
> connection, even if that ends up requiring significant changes to the draft 
> in its current state.
>
>
> To that end, we’re interested in learning whether wg members support adoption 
> of this deployment model and the currently-described certificate negotiation 
> mechanism or if they oppose adoption (and why!).

We absolutely need to solve the problem and the draft is a good starting point.

>
>
> Thanks!
>
> David, Devon, and Bob
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www/.
> ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C02%7CAndrei.Popov%40micr
> osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> 7C=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D=0



--
Astra mortemque praestare gradatim

___
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] [EXTERNAL] Re: Adoption call for TLS Flag - Request mTLS

[Andrei Popov]

  *   Well, don't we want to say how this is supposed to work somewhere? I 
doubt this will take much time.
The authors may want to, but could this be an independent submission, rather 
than WG item? It seems that the real goal here is to enable a specific scenario 
between a cloud provider and a search engine… Furthermore, it appears that the 
authors recommend against general-purpose TLS stacks implementing this:

  *   Recommended shall be set to no (N)

Cheers,

Andrei

From: TLS  On Behalf Of Watson Ladd
Sent: Tuesday, April 2, 2024 10:37 PM
To: Eric Rescorla 
Cc: Christopher Patton ; TLS List 

Subject: [EXTERNAL] Re: [TLS] Adoption call for TLS Flag - Request mTLS


On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Adoption should not be required to register a code point [0], as the policy is 
Specification Required.

I'm mildly negative on adopting this document. What is the reason we need to 
spend WG time on this, rather than just having a code point assignment?

Well, don't we want to say how this is supposed to work somewhere? I doubt this 
will take much time.

-Ekr

[0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13 should 
clearly have
a policy which matches 8447 S 7, which is to say that an I-D is sufficient.


On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton 
mailto:40cloudflare@dmarc.ietf.org>>
 wrote:
I'd like to see this problem solved. There was some discussion about whether an 
I-D is needed or all we needed was to register a code point somewhere. If most 
agree that an I-D is needed, then let's adopt it. I'm happy to review.

Chris P.

On Tue, Apr 2, 2024 at 12:22 PM Sean Turner 
mailto:s...@sn3rd.com>> wrote:
At the IETF 119 TLS session there was some interest in the mTLS Flag I-D 
(https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see 
previous list discussions at [0]. This message is to judge consensus on whether 
there is sufficient support to adopt this I-D.  If you support adoption and are 
willing to review and contribute text, please send a message to the list.  If 
you do not support adoption of this I-D, please send a message to the list and 
indicate why.  This call will close on 16 April 2024.

Thanks,
Deirdre, Joe, and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/
___
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] [EXTERNAL] Re: Next steps for key share prediction

[Andrei Popov]

  *   …and now I'm coming around to the idea that we don't need to do anything 
special to account for the "wrong" server behavior. Since RFC8446 already 
explicitly said that clients are allowed to not predict their most preferred 
groups, we can already reasonably infer that such servers actively believe that 
all their groups are comparable in security.
It makes sense for some services to prioritize RTT reduction; others may 
prioritize group strength. There are a lot of services out there prioritizing 
weaker groups for CPU savings (e.g., this is one of the reasons why Curve 25519 
is so popular).


  *   I... question whether taking that position is wise, given the ongoing 
postquantum transition, but so it goes
Servers will have to be updated and reconfigured for PQC/hybrid support, at 
which time they will likely apply a different policy.


  *   Hopefully your TLS server software, if it advertises pluggable 
cryptography with a PQ use case, and yet opted for a PQ-incompatible selection 
criteria, has clearly documented this so it isn't a surprise to you. ;-)
Correct.


  *   Between all that, we probably can reasonably say that's the server 
operator's responsibility?
Yes.

Cheers,

Andrei

From: TLS  On Behalf Of David Benjamin
Sent: Friday, March 8, 2024 3:25 PM
To: Watson Ladd 
Cc:  
Subject: [EXTERNAL] Re: [TLS] Next steps for key share prediction

On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:
On Thu, Mar 7, 2024 at 2:56 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
>
> Hi all,
>
> With the excitement about, sometime in the far future, possibly transitioning 
> from a hybrid, or to a to-be-developed better PQ algorithm, I thought it 
> would be a good time to remind folks that, right now, we have no way to 
> effectively transition between PQ-sized KEMs at all.
>
> At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which aims 
> to address this. For a refresher, here are some links:
> https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
> (Apologies, I forgot to cut a draft-01 with some of the outstanding changes 
> in the GitHub, so the link above is probably better than draft-00.)
>
> If I recall, the outcome from IETF 118 was two-fold:
>
> First, we'd clarify in rfc8446bis that the "key_share first" selection 
> algorithm is not quite what you want. This was done in 
> https://github.com/tlswg/tls13-spec/pull/1331
>
> Second, there was some discussion over whether what's in the draft is the 
> best way to resolve a hypothetical future transition, or if there was another 
> formulation. I followed up with folks briefly offline afterwards, but an 
> alternative never came to fruition.
>
> Since we don't have another solution yet, I'd suggest we move forward with 
> what's in the draft as a starting point. (Or if this email inspires folks to 
> come up with a better solution, even better! :-D) In particular, whatever the 
> rfc8446bis guidance is, there are still TLS implementations out there with 
> the problematic selection algorithm. Concretely, OpenSSL's selection 
> algorithm is incompatible with this kind of transition. See 
> https://github.com/openssl/openssl/issues/22203

Is that asking whether or not we want adoption? I want adoption.

I suppose that would be the next step. :-) I think, last meeting, we were a 
little unclear what we wanted the document to be, so I was trying to take stock 
first. Though MT prompted me to ponder this a bit more in 
https://github.com/davidben/tls-key-share-prediction/issues/5, and now I'm 
coming around to the idea that we don't need to do anything special to account 
for the "wrong" server behavior. Since RFC8446 already explicitly said that 
clients are allowed to not predict their most preferred groups, we can already 
reasonably infer that such servers actively believe that all their groups are 
comparable in security. OpenSSL, at least, seems to be taking that position. 
I... question whether taking that position is wise, given the ongoing 
postquantum transition, but so it goes. Hopefully your TLS server software, if 
it advertises pluggable cryptography with a PQ use case, and yet opted for a 
PQ-incompatible selection criteria, has clearly documented this so it isn't a 
surprise to you. ;-)

Between all that, we probably can reasonably say that's the server operator's 
responsibility? I'm going to take some time to draft a hopefully simpler 
version of the draft that only defines the DNS hint, and just includes some 
rough text warning about the implications. Maybe also some SHOULD level text to 
call out that servers should be sure their policy is what they want. Hopefully, 
in drafting that, it'll be clearer what the options are. If nothing else, I'm 
sure writing it will help me crystalize my own preferences!

> Given that, I don't see a clear 

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Andrei Popov]

A few concerns I have with this extension:

  1.  Privacy: clients broadcasting intent to identify themselves to anyone who 
asks. I know, this is intended for crawler bots, but the TLS stack does not 
know whether our caller is a bot, so we will have to implement API support, 
which will be used by various apps/services.
  2.  Broadcasting intent to send a client cert before knowing the 
CerrtificateRequest parameters is contrary to the design of TLS client auth. 
What if the available client cert does not match the future CertificateRequest?
  3.  The stated goal is to use this extension to selectively interrogate 
crawler bots. This extension will only be useful for this purpose until general 
Web apps start using it. Which they will do, once TLS stacks are updated to 
support the new extension.

Doesn't the proposed extension facilitate surveillance by letting an 
unauthenticated TLS sever know that the client is willing to divulge its 
identity, and that querying client identity won't disrupt the flow or cause any 
notification to the user?


Cheers,


Andrei


From: TLS  on behalf of Ilari Liusvaara 

Sent: Tuesday, November 7, 2023 3:36 PM
To:  
Subject: [EXTERNAL] Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 12:26:03PM -0400, David Benjamin wrote:
> > So in my mind this is something that will (almost) never be sent by
> browsers.
>
> What cases would the "(almost)" kick in? This extensions model just doesn't
> match how client certificates work in browsers. I'm not seeing any
> interpretation beyond "always send" or "never send".

Explicit configuration to send this for some names/domains.

Needed for some "enterprise" use cases (can also pop up in much smaller
corporate contexts).




-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%7Cb542a7f746b74d5d539508dbdf9efbfe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638349646193968016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=9sTyFEtT1T3jmXmxjjFGAj39PbEms6IQfC1l1fX0Gug%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Andrei Popov]

Likewise, I support adoption, willing to contribute text and implementation.

Cheers,

Andrei


From: TLS  on behalf of David Benjamin 

Sent: Monday, November 6, 2023 9:26 AM
To: Joseph Salowey 
Cc:  
Subject: [EXTERNAL] Re: [TLS] Adoption call for Legacy RSASSA-PKCS1-v1_5 
codepoints for TLS 1.3

I support adoption and am willing to contribute text, but this is perhaps not 
surprising. :-)

On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft  
Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 
1.3 
(https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/01/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text.  If you do not 
support adoption of this draft please indicate why.  This call will close on 
November 27, 2023.

Thanks,

Sean, Chris 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

Re: [TLS] [EXTERNAL] Re: Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Andrei Popov]

Correct, hardware update takes years. Deployments that use client crypto 
devices without RSA-PSS support (or with an RSA-PSS implementation that 
produces TLS 1.3-incompatible signatures) have to disable TLS 1.3 on the client 
and/or server side.

In a lot of these deployments the system admin can detect incompatible client 
crypto devices and update TLS stacks as needed.

Cheers,

Andrei

From: David Benjamin 
Sent: Friday, October 27, 2023 11:34 AM
To: Benjamin Kaduk 
Cc: Andrei Popov ; TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk 
mailto:bka...@akamai.com>> wrote:
On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote:
>Additionally I want to emphasize that, because of the negotiation order
>between versions and client certificates, there is no way to do an
>incremental transition here. Saying deployments stick with 1.2 not only
>impacts the relevant hardware but also *any other connections that the
>server makes*. Essentially the server cannot enable TLS 1.3 until *every*
>client has stopped using one of these PSS-incapable signers. This is not a
>good transition plan.

I think we should probably think out the transition plan here a bit more.
Sure, if we can have updated clients offer new SignatureSchemes and the server
notice that to let them use TLS 1.3.  But how does the server get to a place
where it can use TLS 1.3 with every client that offers it?  It seems like it
has to know that all clients with old hardware tokens have updated, which would
require knowing about and tracking exactly which clients those are, since other
clients would not be sending the new SignatureSchemes in the first place.  I
see this getting a small win for the legacy clients but no improvement for
other clients or the server's default behavior.  Am I missing something?

Good question. You're right that, because we didn't do this from day one[*], 
the transition plan is not ideal.

Updating software is a lot easier than replacing hardware, so I think waiting 
for clients with old hardware tokens to update (at least those that have 
enabled TLS 1.3) can be viable. Most client certificate deployments that stick 
keys in interesting hardware tokens are relatively closed ecosystems on the 
client half, such as a managed enterprise deployment. You need to have a 
provisioning process that knows to use the TPMs. In those cases, it is viable 
for the enterprise to rollout client support for these legacy codepoints, wait 
a bit, and then start enabling TLS 1.3 on the servers.

Andrei is probably better to speak to how commonly that plan would and wouldn't 
be viable. If there are enough deployments where this doesn't work, I suppose 
we could define a ClientHello extension that means "I will either speak the 
legacy RSASSA-PKCS1-v1_5 codepoints, or it is not relevant to me". Those 
semantics are pretty messy though, and it makes the server-random downgrade 
hack much more complex. We can always do it later if enough folks need it, so 
I'm inclined to defer it for now.

David

[*] As I recall, TLS 1.3 was broadly intended to be deployable with the same 
keys as TLS 1.2, otherwise we probably needn't have bothered with RSA at all. 
We switched from PKCS#1 v1.5 to PSS mostly because it was perceived to cost us 
nothing. This was broadly true for server certificates. Client certificates not 
so much. In hindsight, I think banning PKCS#1 v1.5 for client signatures was a 
tad too ambitious for TLS 1.3.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Andrei Popov]

Hi TLS,

We would like to re-introduce 
https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
(it's intended for the TLS WG and the Standards track, despite what the 
document says at the top; we'll fix it as soon as the submission tool reopens).

In the course of TLS 1.3 deployment, it became apparent that a lot of hardware 
cryptographic devices used to protect TLS client certificate private keys 
cannot produce RSA-PSS signatures compatible with TLS.
This draft would allow RSA-PKCS signatures in the client CertificateVerify 
messages (and not in any other contexts), as a way to unblock TLS 1.3 
deployments.
This is an unfortunate situation, and work is being done with hardware vendors 
to reduce the likelihood of similar issues in the future, but existing devices 
tend to stay around for years.

Comments/suggestions are welcome,

Cheers,

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Andrei Popov]

> So it may be necessary to have the server respond with its own flag to 
> indicate that it really does want client cert auth and isn't just asking for 
> a client cert on autopilot.
An "I really mean it" flag. We can add these for every TLS message, not just 
authentication-related ones. Just to make sure the peer truly is serious about 
the TLS handshake.


-Original Message-
From: TLS  On Behalf Of Peter Gutmann
Sent: Tuesday, October 24, 2023 12:55 AM
To: tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Viktor Dukhovni  writes:

>I don't see in your comment anything to suggest that the flag is a no-go.

Oh, it's definitely not a no-go, just pointing out that you shouldn't read too 
much into seeing a cert request from a server.  In other words if the client 
says "I have a cert" and the server responds "please authenticate using the 
cert", that doesn't mean that the server will actually expect client cert auth 
at that point.

So it may be necessary to have the server respond with its own flag to indicate 
that it really does want client cert auth and isn't just asking for a client 
cert on autopilot.

Peter.

___
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] [EXTERNAL] Re: Request mTLS Flag

[Andrei Popov]

> At least as a client, you can't read anything into seeing a cert request from 
> the server, it's just a standard part of the handshake, like a keyex or a 
> finished.
This is exactly my argument: when a client receives a cert request the client 
cannot satisfy, the RFC says send an empty Certificate and continue with the 
handshake...

-Original Message-
From: Peter Gutmann  
Sent: Monday, October 23, 2023 7:41 PM
To: Andrei Popov ; tls@ietf.org
Subject: Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

Andrei Popov  writes:

>Yes, but, arguably, such broken clients won't be fixed by adding new 
>extensions/flags/etc. If they do not comply with the simple RFC 
>language that exists, can we expect them to implement the new flag correctly?

I would argue that it's the server that's broken, not the client.  An awful lot 
of (non-WWW) servers automatically request a client cert without anyone running 
the server being aware of it, or when asked, how to disable it.  The clients 
then sleepwalk their way past it with a zero-length reply and things continue 
as normal with neither the server admin nor the client-side user being aware 
that certificate auth was requested and denied.

At least as a client, you can't read anything into seeing a cert request from 
the server, it's just a standard part of the handshake, like a keyex or a 
finished.

Peter.

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Andrei Popov]

>> It would be useful to be able to request certificates conditioned on the 
>> client promising to not fail just because it is unable or unwilling to offer 
>> one.
TLS RFCs do not require clients to fail the handshake when the server requests 
a cert and the client cannot satisfy the request. E.g., TLS 1.3 says:

" If the server requests client authentication but no
   suitable certificate is available, the client MUST send a Certificate
   message containing no certificates (i.e., with the "certificate_list"
   field having length 0)."

>> They could just proceed without a certificate, or return a default
  one, but they don't.

Yes, but, arguably, such broken clients won't be fixed by adding new 
extensions/flags/etc. If they do not comply with the simple RFC language that 
exists, can we expect them to implement the new flag correctly?

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Viktor Dukhovni
Sent: Monday, October 23, 2023 10:38 AM
To: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Request mTLS Flag

On Mon, Oct 23, 2023 at 11:36:10AM -0400, David Benjamin wrote:

> Would you expect a browser user to send this flag? On the browser
> side, we don't know until the CertificateRequest whether a client
> certificate is configured. We have to do a moderately expensive query,
> dependent on information on the CertificateRequest of the OS's cert
> and key stores to get this information. This query may even call into
> things like 3p smartcard drivers, which may do arbitrarily disruptive
> things like showing UI.

One sensible use-case for such a signal is in mail user agent (MUA) to mail 
submission agent (MSA) communication.

- When the submission client is a bot, a client cert is a fairly
  natural choice of credential.

- Some Java TLS libraries (used to?) fail the handshake when the
  client has no configured certs, or the list of issuer CA DN hints
  does include any of its available (typically just zero or one)
  certificates.

  They could just proceed without a certificate, or return a default
  one, but they don't.

- Most MTAs and MSAs don't request certificates, avoiding the
  potential interoperability issue.

It would be useful to be able to request certificates conditioned on the client 
promising to not fail just because it is unable or unwilling to offer one.

Hence, I would like to see this flag move forward, though I'd also, perhaps 
separately, like to see an extension, that either combined with this flag, or 
alone, conveys an additional DNS name, where the server might find the client's 
TLSA records, allowing the client to establish a binding to that name.  
Something like, given:

_smtp-client.example.com. IN TLSA 3 1 1 ...

send a hint of "example.com", with the "_smtp-client" prefix implied by the 
application protocol (prepended by the server).

https://datatracker.ietf.org/doc/html/draft-huque-tls-dane-clientid

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

Re: [TLS] [EXTERNAL] Re: Request mTLS Flag

[Andrei Popov]

The use-case is not very clear to me: when is the decision whether to 
authenticate a client or not based on the availability of a pre-configured 
client certificate?
If the client says they have a pre-configured cert, the server authenticates 
them; otherwise, the connection succeeds without client auth (and, presumably, 
the server returns a different response at the application layer)?

The draft says:
>>Sometimes a server does not want to negotiate mTLS with every client, but 
>>might wish to authenticate a subset of them.
Yes, there are a number of scenarios of this nature, but in the use-cases I’ve 
seen, the decision is made post-handshake, based on what happens at the 
application layer. Something like a public landing page with some protected 
links that require client auth if the user chooses them.

From a TLS client’s perspective, let’s say the client certificate is 
preconfigured. Before receiving a CertificateRequest, the TLS client does not 
know whether the preconfigured cert even satisfies the request. The client 
could be coded to go look for a better-matching cert, based on the 
CertificateRequest.

>>This is aimed at bots, both internal and external. For example identifying a 
>>web crawler, and either allowing or disallowing it.
As soon as servers start rejecting bots based on the absence of this flag, 
won’t bots figure out to send the flag?

>>If the server unexpectedly requests a certificate from a human user, most 
>>users wouldn’t know what to do.
Sure, but there also bots that can select a certificate dynamically in response 
to a CertificateRequest. Should they send this proposed flag or no?

Cheers,

Andrei

From: TLS  On Behalf Of David Benjamin
Sent: Monday, October 23, 2023 9:26 AM
To: Jonathan Hoyland 
Cc:  
Subject: [EXTERNAL] Re: [TLS] Request mTLS Flag

> So in my mind this is something that will (almost) never be sent by browsers.

What cases would the "(almost)" kick in? This extensions model just doesn't 
match how client certificates work in browsers. I'm not seeing any 
interpretation beyond "always send" or "never send".

> For example identifying a web crawler, and either allowing or disallowing it.

I'm not following how this identifies web crawlers, unless perhaps we're using 
the term to mean different things? I would expect web crawlers to typically not 
do much with client certificates, and to typically want to index the web in the 
same way that humans with web browsers see it.

> I don't think this leaks more info than a dedicated endpoint (even accounting 
> for ECH), and from a security perspective is just a hint.

The difference is the dedicated endpoint case only kicks in once you are 
actually talking to a site that is deployed that way. A ClientHello flag would 
likely be sent unconditionally, because it's too early to condition it on much.

On Mon, Oct 23, 2023 at 11:58 AM Jonathan Hoyland 
mailto:jonathan.hoyl...@gmail.com>> wrote:
Hi David,

So in my mind this is something that will (almost) never be sent by browsers.

This is aimed at bots, both internal and external. For example identifying a 
web crawler, and either allowing or disallowing it.

Currently we identify many bots by IP range and user agent (and a bunch of ML), 
which isn't always reliable.

The web crawler case is where the dedicated endpoint falls over, because 
crawlers are indexing the human visible web.

I don't think this leaks more info than a dedicated endpoint (even accounting 
for ECH), and from a security perspective is just a hint.


Regards,

Jonathan

On Mon, 23 Oct 2023, 16:36 David Benjamin, 
mailto:david...@chromium.org>> wrote:
Would you expect a browser user to send this flag? On the browser side, we 
don't know until the CertificateRequest whether a client certificate is 
configured. We have to do a moderately expensive query, dependent on 
information on the CertificateRequest of the OS's cert and key stores to get 
this information. This query may even call into things like 3p smartcard 
drivers, which may do arbitrarily disruptive things like showing UI.

And if we could somehow predict this information, this would leak into the 
cleartext ClientHello when, starting TLS 1.3, the whole client certificate flow 
is in the encrypted portion of the handshake.

So, practically speaking, I don't think browsers could do anything meaningful 
with this extension. We'd either always send it, on grounds that we have code 
to rummage for client certs on request, or never send it on grounds that we're 
not preconfigured with a client cert at the time of ClientHello. Either way, it 
seems likely to interfere with someone's assumptions here.

The dedicated endpoint strategy seems more straightforward.

David

On Mon, Oct 23, 2023, 11:22 Jonathan Hoyland 
mailto:jonathan.hoyl...@gmail.com>> wrote:

Hey TLSWG,


I've just posted a new 
draft that 
defines a TLS 

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Andrei Popov]

  *   But how are you going to detect whether there's a crappy TCP/IP stack or 
an attack? You can't.
Understood. This is a general problem with insecure client-side fallbacks.

It is unclear what this draft is trying to achieve:

  *   Is this draft paving the way for TLS clients to advertise PQC groups 
without sending the corresponding key shares?
This is available today, and yes servers may or may not HRR in this situation. 
Server’s decision, depends on a variety of factors. Servers that really care 
about PQC (or some other distinction between supported groups) will HRR.

If this is the problem we’re trying to address, could this just be a security 
consideration in the PQC drafts?



  *   Is this draft anticipating a new wave of TLS clients performing insecure 
fallbacks?
Server-side protection against this is not effective. Especially when we have 
both servers that cannot handle large ClientHello messages and servers that 
have buggy HRR.

If this is the concern, would it be better to just say that TLS clients SHOULD 
NOT/MUST NOT implement insecure fallbacks to weaker TLS parameters?

Cheers,

Andrei

From: Rob Sayre 
Sent: Monday, October 16, 2023 4:36 PM
To: Andrei Popov 
Cc: David Benjamin ; tls@ietf.org
Subject: Re: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for 
draft-davidben-tls-key-share-prediction-00.txt

On Mon, Oct 16, 2023 at 3:51 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:

  *   Where these interpretations conflict, the selection may be downgraded, 
potentially even under attacker influence.
Downgrade by attacker is only possible if the client attempts insecure fallback 
(e.g., offer PQ key share, connection failed, retry without PQ key share)?
Or am I missing some other possible downgrade attack?

I think perhaps. The problem is that PQ key shares are going to be split across 
packets, and some software is going to break. This is just because our current 
ClientHellos fit in one packet (or maybe a few, the more you add, the worse it 
gets).

But how are you going to detect whether there's a crappy TCP/IP stack or an 
attack? You can't. So, as the new things roll out, this will happen. It's not 
really an interesting problem, but it is real. Think of how TLS 1.3 handshakes 
pretend to be something older. It's that sort of thing.

thanks,
Rob

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

Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Andrei Popov]

  *   Where these interpretations conflict, the selection may be downgraded, 
potentially even under attacker influence.
Downgrade by attacker is only possible if the client attempts insecure fallback 
(e.g., offer PQ key share, connection failed, retry without PQ key share)?
Or am I missing some other possible downgrade attack?


  *   Clients that assume a server implements the new rules may introduce a 
downgrade attack on a pre-existing server.
From the text, it is not clear to me exactly how.

  *   It updates server behavior to clarify that key shares may not reflect 
client preferences.
  *   While this algorithm avoids HelloRetryRequest whenever possible, it 
implicitly assumes the client prefers the values sent in key_share, and that 
the server has no preferences between any groups.
I don’t think so.
Servers accepting other than the server’s top-priority group in order to avoid 
HRR aren’t necessarily doing this because they honor client preferences or 
assume that key_share reflects client preferences.
They may simply find several groups acceptable and consider RTT reduction more 
important than the strength difference between certain groups. I’m not 
convinced that this is necessarily wrong, generally.

Cheers,

Andrei

From: TLS  On Behalf Of Rob Sayre
Sent: Monday, October 16, 2023 10:52 AM
To: David Benjamin 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Fwd: New Version Notification for 
draft-davidben-tls-key-share-prediction-00.txt

On Mon, Oct 16, 2023 at 9:18 AM David Benjamin 
mailto:david...@chromium.org>> wrote:
 I've thus rephrased it in terms of just one group, which I think is much 
tidier. How does this look to you?
https://github.com/davidben/tls-key-share-prediction/commit/310fa7bbddd1fe0c81e3a6865a59880efc901b33

I agree with the sentiment, but I still see one problem. This text seems really 
tough to write, so I sympathize.

The only remaining problem I see is "Restricting to prediction-safe groups".

Maybe "Restricting this selection to..."? I don't have a strong opinion, but 
I'm pretty sure "Restricting to" is not right.

thanks,
Rob

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

Re: [TLS] [EXTERNAL] Adoption call for draft-jackson-tls-cert-abridge

[Andrei Popov]

I support adoption.

Cheers,

Andrei Popov

-Original Message-
From: TLS  On Behalf Of Christopher Wood
Sent: Tuesday, August 1, 2023 12:36 PM
To: TLS@ietf.org
Subject: [EXTERNAL] [TLS] Adoption call for draft-jackson-tls-cert-abridge

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

Re: [TLS] [EXTERNAL] Re: RFC 9345 on Delegated Credentials for TLS and DTLS

[Andrei Popov]

A similar question for the client side: are there any Web browsers with 
Delegated Credentials support?

Cheers,

Andrei

From: TLS  On Behalf Of Jonathan Hoyland
Sent: Monday, July 17, 2023 4:39 AM
To: Ilari Liusvaara 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] RFC 9345 on Delegated Credentials for TLS and DTLS

Hi Ilari,

If you're looking for a currently live server 
www.facebook.com will serve you a Delegated 
Credential if you indicate support for it in your ClientHello.

If you want other implementations to test against, Cloudflare's fork of 
Go
 has an implementation, and with some finagleing you can make boringssl support 
DCs too.

Regards,

Jonathan

On Mon, 17 Jul 2023 at 07:46, Ilari Liusvaara 
mailto:ilariliusva...@welho.com>> wrote:
On Thu, Jul 13, 2023 at 03:29:20PM -0700, 
rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 9345
>
> Title:  Delegated Credentials for TLS and DTLS
> Author: R. Barnes,
> S. Iyengar,
> N. Sullivan,
> E. Rescorla
> Status: Standards Track
> Stream: IETF
> Date:   July 2023
> Mailbox:r...@ipv.sx,
> sub...@fb.com,
> n...@cloudflare.com,
> e...@rtfm.com
> Pages:  17
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-ietf-tls-subcerts-15.txt
>
> URL:https://www.rfc-editor.org/info/rfc9345
>
> DOI:10.17487/RFC9345

Are there any known servers that support this (for quick interop check)?
All the test servers I have found (three) seem to have been shut down.




-Ilari

___
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] [EXTERNAL] Re: SSL cert - CA issuer question - WIndows Event Reporting CA

[Andrei Popov]

 @M K Saravanan: if you export (w/o private key) and share the cert  with me, I 
can take a look. Windows does not MITM TLS connections.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Wednesday, June 7, 2023 2:17 PM
To: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] SSL cert - CA issuer question - WIndows Event 
Reporting CA

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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

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 
mailto:ietf-d...@dukhovni.org>> 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

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

[Andrei Popov]

  *   That seems way to soft and does not say anything about reusing a key 
share in an _ECDHE_ cipher suite for a long time making it static. But 
RFC8446bis now has added SHOULD NOT reuse key share which is very welcome. My 
preference would be MUST NOT reuse.
Agreed, and I also generally agree with your analysis of options 1-4.

However, the IETF standardizing any TLS MITM/visibility options would be a net 
negative, from my perspective. That would increase the (already significant) 
pressure on TLS stack implementors to provide these "visibility" solutions. 
This pressure already comes from a lot of different angles.

Cheers,

Andrei

From: TLS  On Behalf Of John Mattsson
Sent: Friday, April 7, 2023 8:25 AM
To: Andrei Popov ; John Mattsson 
; Christopher Wood 
; Sean Turner 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile


Thanks!

>"Implementations MUST NOT negotiate the cipher suites with NULL encryption."
I will add a link to RFC 9325 in the next version of 
draft-mattsson-tls-psk-ke-dont-dont-don't

>"Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
>(static) finite-field Diffie-Hellman (DH) key agreement."
That seems way to soft and does not say anything about reusing a key share in 
an _ECDHE_ cipher suite for a long time making it static. But RFC8446bis now 
has added SHOULD NOT reuse key share which is very welcome. My preference would 
be MUST NOT reuse.
Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Andrei Popov 
mailto:Andrei.Popov=40microsoft@dmarc.ietf.org>>
Date: Thursday, 6 April 2023 at 20:08
To: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 Christopher Wood mailto:c...@heapingbits.net>>, Sean 
Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org> mailto:TLS@ietf.org>>
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

  *   Maybe IETF (e.g., UTA) could say what organizations should definitely not 
do (like NULL encryption).
This is already done. UTA BCPs prohibit NULL encryption and static DH: 
https://www.rfc-editor.org/rfc/rfc9325.html
"Implementations MUST NOT negotiate the cipher suites with NULL encryption."
"Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
(static) finite-field Diffie-Hellman (DH) key agreement."

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of John 
Mattsson
Sent: Thursday, April 6, 2023 7:41 AM
To: Christopher Wood mailto:c...@heapingbits.net>>; Sean 
Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

Hi,

So, what should people do regarding visibility? There are obviously 
organizations that think they need visibility. I see the topic popping up 
frequently in a lot of different places. Both in IETF and outside.

I see four ways to achieve visibility.

  1. Do things in the endpoints.
  2. Use NULL encryption
  3. Use a static DH key instead of ephemeral. Share static DH key.
  4. Export session keys to intermediate node.

I don't see 2 and 3 are not viable solutions at all, ever.

Regarding 2. it violates several of the TLS security properties. NIST states as 
the first basic assumption for network connectivity for any organization that 
utilizes zero trust is that:

"The entire enterprise private network is not considered an implicit trust 
zone. Assets should always act as if an attacker is present on the enterprise 
network, and communication should be done in the most secure manner available. 
This entails actions such as authenticating all connections and encrypting all 
traffic."

Regarding 3. it violates one of the fundamental TLS 1.3 security properties 
namely "Forward secret with respect to long-term keys". It also violates zero 
trust principles. Two essential zero trust principles according to NIST and NSA 
are to assume that breach is inevitable or has likely already occurred and to 
minimize the impact when breach occur. One type of breach is key compromise. 
Using PFS is a must to limit the impact of key compromise and therefore to 
follow zero trust principles.

The only viable solutions I see are therefore 1 or 4:

1. do things in the endpoints

4. export sessions keys to the intermediary and making sure that the 
intermediary does not store the keys long term. Storing the session keys long 
term violates the TLS security properties and the zero trust principles 
described above.

Regarding 4. there are many different solutions.

- SSLKEYLOGFILE is a de facto standard for exporting TLS key material.

- ETSI CYBER has standardized Middlebox Security Protocol.
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

- Proprietary solutions such as
https:/

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

[Andrei Popov]

  *   Maybe IETF (e.g., UTA) could say what organizations should definitely not 
do (like NULL encryption).
This is already done. UTA BCPs prohibit NULL encryption and static DH: 
https://www.rfc-editor.org/rfc/rfc9325.html
"Implementations MUST NOT negotiate the cipher suites with NULL encryption."
"Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral 
(static) finite-field Diffie-Hellman (DH) key agreement."

Cheers,

Andrei

From: TLS  On Behalf Of John Mattsson
Sent: Thursday, April 6, 2023 7:41 AM
To: Christopher Wood ; Sean Turner 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

Hi,

So, what should people do regarding visibility? There are obviously 
organizations that think they need visibility. I see the topic popping up 
frequently in a lot of different places. Both in IETF and outside.

I see four ways to achieve visibility.

  1. Do things in the endpoints.
  2. Use NULL encryption
  3. Use a static DH key instead of ephemeral. Share static DH key.
  4. Export session keys to intermediate node.

I don't see 2 and 3 are not viable solutions at all, ever.

Regarding 2. it violates several of the TLS security properties. NIST states as 
the first basic assumption for network connectivity for any organization that 
utilizes zero trust is that:

"The entire enterprise private network is not considered an implicit trust 
zone. Assets should always act as if an attacker is present on the enterprise 
network, and communication should be done in the most secure manner available. 
This entails actions such as authenticating all connections and encrypting all 
traffic."

Regarding 3. it violates one of the fundamental TLS 1.3 security properties 
namely "Forward secret with respect to long-term keys". It also violates zero 
trust principles. Two essential zero trust principles according to NIST and NSA 
are to assume that breach is inevitable or has likely already occurred and to 
minimize the impact when breach occur. One type of breach is key compromise. 
Using PFS is a must to limit the impact of key compromise and therefore to 
follow zero trust principles.

The only viable solutions I see are therefore 1 or 4:

1. do things in the endpoints

4. export sessions keys to the intermediary and making sure that the 
intermediary does not store the keys long term. Storing the session keys long 
term violates the TLS security properties and the zero trust principles 
described above.

Regarding 4. there are many different solutions.

- SSLKEYLOGFILE is a de facto standard for exporting TLS key material.

- ETSI CYBER has standardized Middlebox Security Protocol.
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

- Proprietary solutions such as
https://www.nubeva.com/pillar/get-session-keys

If IETF cannot say that anything is recommended. Maybe IETF (e.g., UTA) could 
say what organizations should definitely not do (like NULL encryption). Seems 
like a lot of organizations are deploying different kinds of solutions right 
now. They will likely do less secure things than necessary...

Cheers,
John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Christopher Wood mailto:c...@heapingbits.net>>
Date: Thursday, 19 January 2023 at 15:57
To: Sean Turner mailto:s...@sn3rd.com>>
Cc: TLS@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile
Hi folks,

Apologies for the delay in concluding this adoption call. To close the loop 
here, it doesn't look like we have sufficient support to adopt the document as 
a WG item.

The chairs would like to recommend AD sponsorship as a viable path forward for 
this document. This should achieve the desired end goal of moving change 
control from the fine folks maintaining NSS to the IETF while also nailing down 
the now widely supported format used in production.

Best,
Chris, for the chairs

> On Nov 28, 2022, at 1:41 PM, Sean Turner 
> mailto:s...@sn3rd.com>> wrote:
>
> Hi!
>
> At TLS@IETF115, the sense of the room was that there was WG support to adopt 
> draft-thomson-tls-keylogfile [1].  This message is to judge consensus on 
> whether the WG should adopt draft-thomson-tls-keylogfile. Please indicate 
> whether you do or do not support adoption of this I-D by 2359UTC on 12 
> December 2022. If do not support adoption, please indicate why.
>
> Cheers,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-thomson-tls-keylogfile/
> ___
> 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] [EXTERNAL] Re: TLS 1.2 deprecation

[Andrei Popov]

IMHO, no reason to add post_handshake_auth to TLS 1.2, because TLS 1.2 already 
supports renegotiation.
While renegotiation had its share of issues we had to patch over time, doing 
TLS 1.2 client auth without renegotiation leaks client identity.

Cheers,

Andrei

From: TLS  On Behalf Of Rob Sayre
Sent: Friday, March 31, 2023 8:20 AM
To: David Benjamin 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] TLS 1.2 deprecation

On Thu, Mar 30, 2023 at 3:58 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
post_handshake_auth was only in TLS 1.3 because some folks relied on an 
existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a 
renegotiation and request a client certificate in the new handshake. I don't 
think it makes sense to backport post_handshake_auth to TLS 1.2. Such a 
backport would also require much more analysis than the average extension, 
since it concerns authentication.

No disagreement from me. My point was only that such things are already in the 
IANA registry.

thanks,
Rob

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

Re: [TLS] multi-identity support in RFC 8446

[Andrei Popov]

> I don't have details, but the NVMe/TCP specification suggests that it can 
> make use of multiple PSK identities during a TLS handshake.
>From my read of NVMe spec, it's one PSK/identity per TLS connection:

"8.13.5.9 Generated PSK for TLS
When used with a non-NULL DH exchange, the DH-HMAC-CHAP protocol is able to 
generate a session
key KS used to generate *a pre-shared key (PSK)* to establish a secure channel 
session with the TLS protocol
between host and controller. A TLS session is concatenated to an authentication 
transaction when the
SC_C indication is set to 01h in the AUTH_Negotiate message. A TLS session 
should not be concatenated
to an authentication transaction if the involved host and controller are 
administratively configured with *a
PSK* for use with each other. In this case, host and controller should just 
establish a TLS session based on
the configured PSK."

>From the above, it looks like NVMe specifies two options: 
1.  Generating PSK based on a Diffie-Hellman key exchange (as part of 
DH-HMAC-CHAP protocol).
2.  Admin configuring host and controller with a PSK.
In both cases, it seems that there is one PSK/identity per host-controller 
connection.

Please correct me if I mis-interpret the NVMe spec,

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Chuck Lever III
Sent: Thursday, March 2, 2023 6:32 AM
To: Peter Gutmann 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] multi-identity support in RFC 8446

[Some people who received this message don't often get email from 
chuck.le...@oracle.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

> On Mar 1, 2023, at 11:29 PM, Peter Gutmann  wrote:
>
> Chuck Lever III  writes:
>
>> We're implementing TLSv1.3 support for PSK and note there is a 
>> capability in the PSK extension described in S 4.2.11 for sending a 
>> list of identities. We don't find support for a list of alternate 
>> identities implemented in user space TLS libraries such as GnuTLS or 
>> OpenSSL. Is there a known reason for that omission?
>
> If it's the same as similar locations in previous versions of TLS 
> where it's possible to specify a list of X instead of just an X then 
> it could be because no-one has any idea why you'd specify a list of X, 
> or what to do with it if one does turn up.  There are several fields 
> where, in the past, we've had users ask what to do with them and it 
> turned out, after some testing, that the answer is "whatever you want" 
> because the other side pays no attention whatsoever to what's in there.

I don't have details, but the NVMe/TCP specification suggests that it can make 
use of multiple PSK identities during a TLS handshake.


--
Chuck Lever


___
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%7Cb6836344b47047a1463508db1b2ae622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638133643342690211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=cksCXJngPspqMYcCmfRTAHwtkRxJ62O50qHTx5gdkgc%3D=0

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

Re: [TLS] multi-identity support in RFC 8446

[Andrei Popov]

Hi Chuck,

> A quick browse of other sections of RFC 8446 does not show a similar 
> capability for sending multiple certificates.
This can be done using TLS 1.3 post-handshake client auth 
(https://www.rfc-editor.org/rfc/rfc8446#section-4.2.6). However, this is an 
optional TLS 1.3 feature and you may find that support for it among TLS stacks 
is either lacking or disabled by default. E.g., Windows TLS stack supports 
post-handshake client auth, but I don't think Chromium does.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Chuck Lever III
Sent: Wednesday, March 1, 2023 6:44 AM
To: tls@ietf.org
Subject: [EXTERNAL] [TLS] multi-identity support in RFC 8446

[Some people who received this message don't often get email from 
chuck.le...@oracle.com. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi-

We're implementing TLSv1.3 support for PSK and note there is a capability in 
the PSK extension described in S 4.2.11 for sending a list of identities. We 
don't find support for a list of alternate identities implemented in user space 
TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for that 
omission? Are there any planned changes in this area coming soon?

A quick browse of other sections of RFC 8446 does not show a similar capability 
for sending multiple certificates. We don't have a reason to need this yet, but 
would like our implementation to be prepared if such a capability were to be on 
the horizon.
Did I misread the RFC?


--
Chuck Lever



___
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%7C1b3998c595b04c513bb808db1a636bd4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638132786607881637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=VVjbauuSNgsMxuB2M4KkXVghXD1TxoSv%2BWfDtNDOB9k%3D=0

___
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

[Andrei Popov]

> If there were some technical means to ensure that this was less likely to be 
> abused, I'd like it more.
Perhaps require key update prior to secrets export

-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Monday, November 28, 2022 2:20 PM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile


I'm ok with adoption so long as we include sufficient caveats along the way 
(and then add more caveats just in case:-)

If there were some technical means to ensure that this was less likely to be 
abused, I'd like it more. (Could we e.g. require inclusion of a TLS extension 
that has a 100kB cat-picture payload?)

S.
___
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

[Andrei Popov]

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

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

[Andrei Popov]

Corrected typo inline.

-Original Message-
From: Andrei Popov 
Sent: Monday, November 28, 2022 11:02 AM
To: 'Salz, Rich' ; Sean Turner 
; TLS List 
Subject: RE: [TLS] Call for adoption of draft-thomson-tls-keylogfile

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.

Standards-track RFC that promotes the export of TLS secrets in clear-text sends 
the wrong message, can (and will) be used to push TLS stack vendors to 
implement this.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Salz, Rich
Sent: Monday, November 28, 2022 10:54 AM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I support adoption.

I assume the wireshark folk(s), etc., will review ...

___
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%7Ce5d4a41309dd44fe5e2108dad172043a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052584901610518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=ffuQE0lqf5IzkYWzizCPKXA4lEHU6e9Nh5kJ4gwd998%3D=0

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

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

[Andrei Popov]

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 not be an Informational RFC.

Standards-track RFC that promotes the export of TLS secrets in clear-text sends 
the wrong message, can (and will) be used to push TLS stack vendors to 
implement this.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Salz, Rich
Sent: Monday, November 28, 2022 10:54 AM
To: Sean Turner ; TLS List 
Subject: [EXTERNAL] Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

I support adoption.

I assume the wireshark folk(s), etc., will review ...

___
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%7Ce5d4a41309dd44fe5e2108dad172043a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638052584901610518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=ffuQE0lqf5IzkYWzizCPKXA4lEHU6e9Nh5kJ4gwd998%3D=0

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

Re: [TLS] [EXTERNAL] Re: [Technical Errata Reported] RFC8446 (7250)

[Andrei Popov]

Hi Alan,


  *   Windows 11 is doing this today with TLS-based EAP methods.  It's a 
disaster.
I own TLS in Windows; please share the details with me, on a separate thread, 
so we can figure out what’s broken. It’s probably a bug in the SSPI caller (EAP 
in this case).

Generally though, I don’t think RFCs should be updated for an obvious 
implementation bug. Disconnecting on ticket receipt is just plain not 
reasonable. An unreasonable implementer won’t heed an RFC update

Cheers,

Andrei

From: TLS  On Behalf Of Eric Rescorla
Sent: Monday, November 14, 2022 11:48 AM
To: Alan DeKok 
Cc: tls@ietf.org; sean+i...@sn3rd.com; paul.wout...@aiven.io; RFC Errata System 

Subject: [EXTERNAL] Re: [TLS] [Technical Errata Reported] RFC8446 (7250)



On Mon, Nov 14, 2022 at 11:28 AM Alan DeKok 
mailto:al...@freeradius.org>> wrote:
On Nov 14, 2022, at 1:09 PM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
>   I'd like to have a way to say "if you don't support session tickets, just 
> ignore them".
>
> Again this text is not quite right because

  I think you're talking at cross purposes to the problem I'm trying to 
describe.

Yes, I had thought you were talking about the server. I got confused because 
your text said "extension" but NewSessionTicket is not an extension but rather 
a handshake message. My mistake.



> Can you explain how you got into this posture? The only reason a client 
> should be sending session tickets is if it received one
> from the server.

  The problem isn't that.  The problem is long before the client tries to 
reconnect.  The problem is the client, not the server.  The problem is that the 
initial connection to the server is never successful.  It has nothing to do 
with other uses of PSKs.  It has nothing to do with clients sending anything to 
the server.

  The flow is this:

 Client connects to server.

 Client and server exchange TLS information.  They're both happy with 
everything.

 Server eventually sends a session ticket to the client.

 Client goes "OMFG" and hangs up.  No more TLS session.

 Repeat ad nauseam until server administrator (a) forbids the use of TLS 
1.3, or (b) forbids session tickets.


  Windows 11 is doing this today with TLS-based EAP methods.  It's a disaster.

I agree that this is a defect.


  Again, from Section 
4.6.1.:

  The client MAY use this PSK for future handshakes by including the
  ticket value in the "pre_shared_key" extension in its ClientHello

  and by *implication* the client also does not need to use the session ticket. 
 It is free to use the session ticket, or to ignore it entirely.

  What the client is *not* free to do is to treat the session ticket as a TLS 
connection failure.  This behavior can best be described as "surprising".

Yes, I agree with that. I would have thought this to be implicit in the spec, 
but I have filed 
https://github.com/tlswg/tls13-spec/issues/1280
 to address it for 8446-bis.

-Ekr



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

Re: [TLS] [EXTERNAL] Re: Published RFC 8446bis -05

[Andrei Popov]

In TLS <= 1.2, the client and server agree on the (EC)DHE group to use for key 
exchange by negotiating it (at the cost of a round-trip).

In TLS 1.3, the client tries to guess what (EC)DHE group(s) the server might 
support and sends key share(s) accordingly (saving a round-trip).
When a TLS 1.3 client fails to guess correctly, HRR message triggers handshake 
restart, this time with no guessing involved.
This failure to guess is undesirable, but luckily not very frequent (as long as 
TLS implementers choose to prioritize roughly the same sets of (EC)DHE groups).

The introduction of PQ algorithms and hybrid key exchange will add options and 
at the same time may reduce the number of different key shares the TLS client 
is willing/able to generate and send. It is possible that the HRR message flow 
might become more common during the PQC transition.

How can we possibly deprecate HRR (without deprecating TLS 1.3)?
(It's also not clear to me how we would get rid of HRR in a future TLS version, 
without removing algorithm options, adding round-trips, or relying on some 
out-of-band signals.)

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Monday, October 24, 2022 7:57 PM
To: Eric Rescorla ; Rob Sayre 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Published RFC 8446bis -05


Hiya,

On 25/10/2022 03:27, Eric Rescorla wrote:
> On Mon, Oct 24, 2022 at 7:17 PM Rob Sayre  wrote:
> 
>> Is removing HRR on the table?
>> 
> 
> No, I don't think so. It performs an important function.

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.

Cheers,
S.

> Moreover, the intent of this revision to TLS 1.3 was to clarify 8446, 
> and this would be a major (and breaking!) change.
> 
> 
> 
>> Maybe just opening a new socket would suffice?
>> 
> 
> I don't see that this would help.
> 
> 1. It would not be clear to the client what it had to do to provide an 
> acceptable CH. 2. Without some sort of HRR-like coupling, it would 
> allow downgrade attacks.
> 
> -Ekr
> 
> 
> 
>> thanks, Rob
>> 
>> On Mon, Oct 24, 2022 at 13:08 Eric Rescorla  wrote:
>> 
>>> Hi Folks,
>>> 
>>> I have just published draft-ietf-tls-rfc8446bis-05, with the 
>>> following changes:
>>> 
>>> * Update the extension table (Issue 1241) * Clarify user_canceled 
>>> (Issue 1208) * Clarify 0-RTT cache side channels (Issue 1225) * 
>>> Require that message reinjection be done with the current hash.
>>> Potentially a clarification and potentially a wire format change 
>>> depending on previous interpretation (Issue 1227)
>>> 
>>> I landed a few current PRs without review. If people think I handled 
>>> these incorrectly or mis-merged, please flag that.
>>> 
>>> This includes most of the outstanding issues and PRs. The following 
>>> remain:
>>> 
>>> PRS 1275 -- Clarifying unsolicited extensions [Waiting for review 
>>> from Kaduk] 1270 -- The impact of excessive key updates [Working on 
>>> text with MT] 1269 -- A new error for invalid tickets [see below] 
>>> 1231 -- Update in light of RFC 8773 [I missed this, but will get to 
>>> it on my next pass]
>>> 
>>> 
>>> SUBSTANTIVE ISSUES 1223, 1224 -- Revising the HRR rules 1278 -- 
>>> There are no entries in the table for which TLS 1.3 messages token 
>>> binding goes in.
>>> 
>>> 
>>> As preview of our discussion in London.
>>> 
>>> I believe I can handle 1275, 1270, and 1231 at the editorial level.
>>> 
>>> I believe we should not land 1269. As noted in the issue there is 
>>> already an unknown_psk_identity, which captures this. I propose to 
>>> close this issue.
>>> 
>>> We need to agree on what appears in the table for token binding. 
>>> I think this is mechanical. MT? DavidBen? Andrei?
>>> 
>>> 
>>> This leaves us with 1223 and 1224. I agree that the HRR semantics 
>>> are a little confusing, but we don't seem to be making much progress 
>>> on revising them and given that 8446 is already out, I think we 
>>> should just publish this revision and then if people get energy to 
>>> address this issue we can do so later.
>>> 
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___ TLS mailing list 
>>> TLS@ietf.org 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>> w.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=05%7C01%7CAndrei.Popo
>>> v%40microsoft.com%7C05e3b7f3afc84fe347bf08dab634b33c%7C72f988bf86f14
>>> 1af91ab2d7cd011db47%7C1%7C0%7C638022634746453365%7CUnknown%7CTWFpbGZ
>>> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>> %3D%7C3000%7C%7C%7Csdata=xWSwOGLU1Nd6jQvU7uQ0sEwGldTf8tz4EwO%2B
>>> HkCS6UQ%3Dreserved=0
>>> 
>> 
> 
> 
> ___ TLS mailing 

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

[Andrei Popov]

  *   - processing of invalid session ID, if it is repeated in the 2nd attempt, 
can be omitted using a smaller cache on the server side
Invalid session ID should not lead to handshake failure; it results in a full 
handshake and an updated session ID/ticket.


  *   - a server having more than one valid certificate for the domain name, 
can switch between them in various attempts.
Sure, but arguably TLS has reasonable methods for driving certificate 
selection, in terms of signature/hash suites.


  *   A cleartext correlator between different requests like this would also be 
a privacy concern and seems to run counter to the work in RFC 8446, appendix 
C.4.
Correct. I'm trying to see what the use-case would be, regardless of the 
proposed design.

From: Dmitry Belyavsky 
Sent: Friday, September 16, 2022 12:01 PM
To: David Benjamin 
Cc: Andrei Popov ; TLS Mailing List 
Subject: Re: [TLS] [EXTERNAL] Opt-in schema for client identification

>From the top of my head I can imagine 2 sort of real-life scenarios:

- processing of invalid session ID, if it is repeated in the 2nd attempt, can 
be omitted using a smaller cache on the server side
- a server having more than one valid certificate for the domain name, can 
switch between them in various attempts.

I agree with Andrei that other parameters are chosen either according to client 
or to the server preferences.

On Fri, Sep 16, 2022 at 8:53 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
I too am not seeing the use case here. Could you elaborate?

Since browsers were mentioned as an example, when Chrome makes several 
connections in a row (e.g. to measure impacts of a removal more accurately), we 
generally do not expect the server to change its selection algorithm across the 
two connections. A cleartext correlator between different requests like this 
would also be a privacy concern and seems to run counter to the work in RFC 
8446, appendix C.4.

On Fri, Sep 16, 2022 at 10:09 AM Andrei Popov 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:

  *   Server can distinguish the client and alter some parameters in response 
to make the new connection successful.
A TLS server would typically choose either server-preferred parameters (cipher 
suite, EC curve, etc.) among those advertised by the client, or honor the 
client's preferences.
Can you give some examples of what a TLS server would alter, to make the new 
connection successful, assuming the 2nd ClientHello has the same list of 
options as the 1st one?
Basically, what types of interop failures is this cookie intended to resolve?


  *   Modern real-life applications (e.g. browsers) may perform several 
handshakes in a row until the connection to the server is finally rejected.
Some TLS clients will vary their offered TLS parameters between these 
connection attempts.

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Dmitry Belyavsky
Sent: Friday, September 16, 2022 4:32 AM
To: TLS Mailing List mailto:tls@ietf.org>>
Subject: [EXTERNAL] [TLS] Opt-in schema for client identification

Dear colleagues,

I'd like to suggest an opt-in cookie-style schema allowing the server to 
identify the client in case when a client performs several unsuccessful 
connection attempts.

Modern real-life applications (e.g. browsers) may perform several handshakes in 
a row until the connection to the server is finally rejected. It may make sense 
to provide different handshake parameters on the server side on the consequent 
attempts.

To distinguish the same client from several different clients, it may be useful 
to add a cookie-style extension in ClientHello. The server responds with an 
encrypted extension containing a random value in a ServerHello. If the 
connection fails, a client may send a value received from the server in the 
next connection attempt. Server can distinguish the client and alter some 
parameters in response to make the new connection successful.

The schema differs from the current session/tickets mechanism because the 
current mechanism implies session resumption only for successfully completed 
handshakes.

As the schema is opt-in, it doesn't provide any extra surveillance 
opportunities.

I understand that the proposed schema may badly work with CDNs.

If there is an interest to my proposal, I could draft it and present on the 
upcoming IETF meeting.

--
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7C38aed490bde840d9809d08da98165079%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637989518872154364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=W7wN3D%2F1eKzp2An8BR4laCg9a%2Bmi8UnsonV04c3

Re: [TLS] [EXTERNAL] Opt-in schema for client identification

[Andrei Popov]

  *   Server can distinguish the client and alter some parameters in response 
to make the new connection successful.
A TLS server would typically choose either server-preferred parameters (cipher 
suite, EC curve, etc.) among those advertised by the client, or honor the 
client’s preferences.
Can you give some examples of what a TLS server would alter, to make the new 
connection successful, assuming the 2nd ClientHello has the same list of 
options as the 1st one?
Basically, what types of interop failures is this cookie intended to resolve?


  *   Modern real-life applications (e.g. browsers) may perform several 
handshakes in a row until the connection to the server is finally rejected.
Some TLS clients will vary their offered TLS parameters between these 
connection attempts.

Cheers,

Andrei

From: TLS  On Behalf Of Dmitry Belyavsky
Sent: Friday, September 16, 2022 4:32 AM
To: TLS Mailing List 
Subject: [EXTERNAL] [TLS] Opt-in schema for client identification

Dear colleagues,

I'd like to suggest an opt-in cookie-style schema allowing the server to 
identify the client in case when a client performs several unsuccessful 
connection attempts.

Modern real-life applications (e.g. browsers) may perform several handshakes in 
a row until the connection to the server is finally rejected. It may make sense 
to provide different handshake parameters on the server side on the consequent 
attempts.

To distinguish the same client from several different clients, it may be useful 
to add a cookie-style extension in ClientHello. The server responds with an 
encrypted extension containing a random value in a ServerHello. If the 
connection fails, a client may send a value received from the server in the 
next connection attempt. Server can distinguish the client and alter some 
parameters in response to make the new connection successful.

The schema differs from the current session/tickets mechanism because the 
current mechanism implies session resumption only for successfully completed 
handshakes.

As the schema is opt-in, it doesn't provide any extra surveillance 
opportunities.

I understand that the proposed schema may badly work with CDNs.

If there is an interest to my proposal, I could draft it and present on the 
upcoming IETF meeting.

--
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

+1 to defining separate extensions and avoiding unnecessary coupling.

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Friday, July 29, 2022 8:42 AM
To: Erik Nygren ; David Benjamin 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] Representing IP addresses in SNI -- proposed draft

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> > datatracker.ietf.org%2Fdoc%2Fdraft-nygren-tls-ip-in-sni%2Fdat
>>> > a=05%7C01%7CAndrei.Popov%40microsoft.com%7C9e531fd5d3634c79fb6b08d
>>> > a71791222%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63794706208
>>> > 9321629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
>>> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=w5M5RQ3
>>> > Ivo8%2FjWc6VQcoI4fXdAP2Yg8fXIQTzFmM7aw%3Dreserved=0
>>> >
>>> > 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 

Re: [TLS] [EXTERNAL] Re: Client programs and stapling?

[Andrei Popov]

The same situation with the Windows TLS stack: we're not parsing status_request 
carried in the CertificateRequest message. There has not been a business 
case/request to support this for client certs.

Cheers,

Andrei

From: TLS  On Behalf Of David Benjamin
Sent: Friday, May 20, 2022 10:24 AM
To: Salz, Rich 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Client programs and stapling?

Prior to TLS 1.3, it wasn't possible because the Certificate message didn't 
have extensions. Starting TLS 1.3, it looks like we did define status_request 
to be allowed in either direction. We (BoringSSL) never implemented the client 
certificate direction, since we haven't needed it yet. We just ignore the 
extension if we see it in CertificateRequest. At a glance, it looks like 
OpenSSL does the same. Dunno about other implementations.

On Fri, May 20, 2022 at 1:07 PM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
Do client programs staple a status when sending a cert to the server? It seems 
possible, someone just asked me if anyone does it.

___
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] [EXTERNAL] Re: [Uta] OCSP in RFC7525bis

[Andrei Popov]

Speaking for a broader-than-browser implementation: PKI stack in Windows found 
hard failure on OCSP non-deployable.
This is not to say that OCSP is entirely useless; OCSP information is 
considered as part of certificate validation.
A very much simplified summary:

  *   If OCSP says "revoked", certificate validation fails.
  *   Without positive OCSP response, CRL processing is used.
  *   "Must staple" extension is supported.
  *   Apps have latitude in how they handle "revocation offline" scenarios.

Cheers,

Andrei

From: Uta  On Behalf Of Eric Rescorla
Sent: Wednesday, January 19, 2022 10:50 AM
To: Yaron Sheffer 
Cc: u...@ietf.org; tls@ietf.org
Subject: [EXTERNAL] Re: [Uta] OCSP in RFC7525bis



On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer 
mailto:yaronf.i...@gmail.com>> wrote:
Hi,

RFC 7525 (the TLS BCP) has a section [1] with "weak" recommendations to use 
OCSP and OCSP stapling. We are changing these recommendations [2] in view of 
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail 
if they don't get an OCSP response within the handshake, i.e. they just ignore 
the problem. As far as we understand, this makes OCSP stapling completely 
ineffective for what it's trying to solve.

Well, many browser implementations have just stopped using OCSP entirely, in 
favor of centralized revocation information a la CRLSets, etc.

I don't know what non-browser implementations do.

So for the new BCP, we have three options:

  *   Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly 
also TLS 1.2 implementations) to fail the handshake if the OCSP response is 
missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

I don't think this is a good idea.


  *
  *   Remove the whole discussion of OCSP, saying that in its current form it's 
not adding value.
  *   Maintain the status quo, where many people implement OCSP on the server 
side, but clients rarely benefit.'
I think if we are to have anything here it would need to actually describe the 
situation and why people soft fail and/or are moving away from OCSP.

I might be able to provide some text from the browser perspective, though 
perhaps AGL or Carrick could also chime in?

-Ekr


  *

We would be grateful for feedback based on implementation experience. In 
particular if you have quantitative data on the use or quality of OCSP that's 
more recent than Chung18 [3], that would be very useful.

Thanks,
Peter, Thomas and Yaron

PS: apologies for cross-posting.


[1] 
https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] 
https://github.com/yaronf/I-D/pull/279/files
[3] 
https://cbw.sh/static/pdf/chung-imc18.pdf

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

Re: [TLS] [EXTERNAL] Re: TLS 1.3 and certificate based authentication

[Andrei Popov]

  *   IMHO this (post-handshake authentication method) is not correct default 
configuration in situation, where common browsers do not support post-handshake 
authentication (Firefox supports it, but it is disabled by default).
TLS client authentication is off by default in IIS, but it is true that a lot 
of IIS deployments use it.


  *   It means, before we can use certificate base authentication with IIS and 
TLS 1.3 protocol, we must change default configuration from post-handshake 
authentication method to in-handshake authentication method.
Correct. Unfortunately, there is no way to automatically handle this in the 
general case, because the server does not know in advance which protected 
resource (if any) the user might choose on the landing page. The server cannot 
ask for the right client certificate in advance of the request for a protected 
resource.

Also, for TLS < 1.3, configuring TLS client authentication in the original 
handshake exposes client certificates in the clear, leaking client identities 
to the network observer.

Cheers,

Andrei

From: Urmas Vanem 
Sent: Sunday, January 16, 2022 7:29 AM
To: Andrei Popov ; Eric Rescorla 
Cc: tls@ietf.org
Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

Microsoft Windows Server 2022 supports post-handshake as default authentication 
method with TLS 1.3. It means, before we can use certificate base 
authentication with IIS and TLS 1.3 protocol, we must change default 
configuration from post-handshake authentication method to in-handshake 
authentication method. So, by default it affects all Microsoft customers who 
want to enable certificate based authentication with TLS 1.3 in IIS, because 
enabling certificate based authentication with TLS 1.3 leads us to 
err_connection_reset error.
IMHO this (post-handshake authentication method) is not correct default 
configuration in situation, where common browsers do not support post-handshake 
authentication (Firefox supports it, but it is disabled by default).

It is good to hear that post-handshake authentication method is optional and 
not preferred.

Thanks,

Urmas

From: Andrei Popov 
mailto:andrei.po...@microsoft.com>>
Sent: Friday, January 14, 2022 10:24 PM
To: Eric Rescorla mailto:e...@rtfm.com>>; Urmas Vanem 
mailto:urmas.va...@octox.eu>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

Essentially, TLS 1.3 post-handshake authentication is analogous to client auth 
via renegotiation available with TLS <= 1.2.
An important difference is that TLS 1.3 post-handshake authentication is 
optional, and major browsers chose not to support it.

In practice, this means TLS server deployments and applications that rely on 
authenticating clients post-handshake have to change if they want to enable TLS 
1.3.
These changes can include creating separate endpoints for client-authenticating 
services, and configuring those endpoints to perform client authentication 
during the handshake.

This affects a significant number of Microsoft customers, who have been using 
client auth support via renegotiation in IIS.
The typical scenario is: landing page without client authentication, then 
renegotiation with client auth if the user navigates to a protected resource on 
the page.
I recommend customers to work directly with browser vendors if they want TLS 
1.3 post-handshake auth support. This is not a TLS 1.3 standard's limitation.

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Eric 
Rescorla
Sent: Friday, January 14, 2022 9:54 AM
To: Urmas Vanem mailto:urmas.va...@octox.eu>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

TLS 1.3 supports certificate-based client auth in the primary handshake.

-Ekr


On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem 
mailto:urmas.va...@octox.eu>> wrote:
Hello!

TLS 1.3 introduces post-handshake authentication. It relies on client/browser, 
client/browser must send post_handshake_auth extension to server before it can 
work. I hope I understood it correctly.
But today we know only Firefox from popular browsers support this extension 
(and not by default).

Question: How can I implement certificate based client authentication against 
web server in TLS 1.3 only environment, if browsers do not support 
post_handshake_auth extension.

I have open discussion with one big software company. Can you please share your 
opinion/recommendation here regarding to the issue?

Thanks in advance,

Urmas

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7CAndrei.Popov%40microsoft.com%7C75277cb97bbd46cbdae908d9d904f410%7C72f988bf

Re: [TLS] [EXTERNAL] Re: TLS 1.3 and certificate based authentication

[Andrei Popov]

Essentially, TLS 1.3 post-handshake authentication is analogous to client auth 
via renegotiation available with TLS <= 1.2.
An important difference is that TLS 1.3 post-handshake authentication is 
optional, and major browsers chose not to support it.

In practice, this means TLS server deployments and applications that rely on 
authenticating clients post-handshake have to change if they want to enable TLS 
1.3.
These changes can include creating separate endpoints for client-authenticating 
services, and configuring those endpoints to perform client authentication 
during the handshake.

This affects a significant number of Microsoft customers, who have been using 
client auth support via renegotiation in IIS.
The typical scenario is: landing page without client authentication, then 
renegotiation with client auth if the user navigates to a protected resource on 
the page.
I recommend customers to work directly with browser vendors if they want TLS 
1.3 post-handshake auth support. This is not a TLS 1.3 standard's limitation.

Cheers,

Andrei

From: TLS  On Behalf Of Eric Rescorla
Sent: Friday, January 14, 2022 9:54 AM
To: Urmas Vanem 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication

TLS 1.3 supports certificate-based client auth in the primary handshake.

-Ekr


On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem 
mailto:urmas.va...@octox.eu>> wrote:
Hello!

TLS 1.3 introduces post-handshake authentication. It relies on client/browser, 
client/browser must send post_handshake_auth extension to server before it can 
work. I hope I understood it correctly.
But today we know only Firefox from popular browsers support this extension 
(and not by default).

Question: How can I implement certificate based client authentication against 
web server in TLS 1.3 only environment, if browsers do not support 
post_handshake_auth extension.

I have open discussion with one big software company. Can you please share your 
opinion/recommendation here regarding to the issue?

Thanks in advance,

Urmas

___
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] [EXTERNAL] Re: supported_versions in TLS 1.2

[Andrei Popov]

Perhaps I missed some part of this thread, but it's still not clear to me what 
would be the purpose of adding supported_versions extension to a TLS 1.2 
implementation? What problem(s) would that solve?

Cheers,

Andrei

From: TLS  On Behalf Of Rob Sayre
Sent: Friday, November 26, 2021 11:15 AM
To: Eric Rescorla 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] supported_versions in TLS 1.2

I'd also add that it usually takes a few years to publish any RFC, so this 
group will increasingly push up against TLS 1.2's deprecation date. There are 
already a bunch of caveats one needs to take into account to deploy it 
securely, and it seems unlikely we've seen the last attack against it. It's 
much more complex than TLS 1.3 in many ways (obv everyone on this email knows 
this, just making the point).

SSL 2.0 1995Deprecated in 2011 (RFC 6176)
SSL 3.0 1996Deprecated in 2015 (RFC 7568)
TLS 1.0 1999Deprecated in 2020 (RFC 8996)
TLS 1.1 2006Deprecated in 2020 (RFC 8996)
TLS 1.2 2008Deprecated in 
TLS 1.3 2018

At the limit, this group could specify extensions to TLS 1.2 that would exist 
as published RFCs for a very short period of time before TLS 1.2 is deprecated. 
I don't feel strongly about the extension that sparked this discussion, but TLS 
1.2 efforts of any kind become more questionable with the passage of time.

thanks,
Rob



On Wed, Nov 24, 2021 at 1:20 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Thanks, Chris.

At a high level, I think we should be focusing our efforts on TLS 1.3.
That means that we should design new features for 1.3 and not for 1.2,
but if it's straightforward to also specify them for 1.2, this is
potentially worthy of consideration on a case-by-case basis.

We generally should not be doing TLS 1.2-only work (including cases
where we have to do a significantly different version or something for
TLS 1.2 and TLS 1.3) except in cases where there is some significant
defect of some kind. I think this is consistent with "maintenance".






-Ekr







On Wed, Nov 24, 2021 at 11:59 AM Christopher Wood 
mailto:c...@heapingbits.net>> wrote:
On Tue, Nov 23, 2021, at 8:03 PM, Peter Gutmann wrote:
> Rob Sayre mailto:say...@gmail.com>> writes:
>
>>The WG is not obligated to support TLS 1.2.
>
> Is that an official WG position, that the TLS WG has abandoned TLS 1.2?  If it
> is, can I have change control over it, because if the WG doesn't want to
> support it, someone will have to.

To clarify, the TLS WG group is chartered to maintain current and previous 
versions of (D)TLS, including TLS 1.2. Proposed changes that affect previous 
versions are therefore in scope.



___
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] [EXTERNAL] Re: Narrowing allowed characters in ALPN ?

[Andrei Popov]

+1 what Ryan said. Especially the point that added restrictions aren’t a viable 
path to better interoperability.

ALPN IDs are byte strings; the fact that some of them can be displayed as ASCII 
character strings merely reflects the fact that those ALPN IDs were chosen by 
humans.

Cheers,

Andrei

From: TLS  On Behalf Of Ryan Sleevi
Sent: Thursday, May 20, 2021 12:06 AM
To: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Narrowing allowed characters in ALPN ?



On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni 
mailto:ietf-d...@dukhovni.org>> wrote:
On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:

> I support limiting it.

I concur.  These are not strings used between users to communicate in
their native language.  They are machine-to-machine protocol
identifiers, and use of the narrowest reasonable character set promotes
interoperability.

I'm not sure I understand this. Could you expand further how adding more 
normative restrictions promotes, rather than harms, interoperability?

The fact that, as you highlight, they are machine-to-machine, seems like the 
greatest path to interoperability, because they shouldn't be assumed to be 
"human-readable", and because as specified, no other validation needs to be 
performed by either party. They should simply be treated as they're specified: 
an opaque series of bytes. Conversions to text strings or transformations such 
as character sets seems like fundamentally misunderstanding/misusing them, 
rather than being a thing to support.

The idea of restricting the character set seems like it only opens the door for 
less interoperability and more complexity. For example, senders need to make 
sure they're sending within the allowed character set (meaning validation 
before transmission), and receivers that wish to avoid malicious peers need to 
similarly validate the identifiers before exposing them as to API callers. This 
then adds complexity to the API design, as "no fail" operations now become 
"maybe fail" (e.g if a caller attempts to call with an invalid character 
string), and that propagates throughout the design of systems (e.g. config 
files that may fail to load now).

It seems there's a parallel here to the discussion about whether HTTP/2 should 
have been a text protocol, like HTTP/1.1 and its predecessors, which had 
similar arguments to what's being raised now, versus the binary protocol that 
was ultimately adopted.

If the argument is that the extensibility has already rusted shut because the 
ecosystem ignored the spec and we didn't GREASE it by using ALPN identifiers 
that actually behaved as opaque bytes, then we should at least make an effort 
to document why and when that happened, so that mistakes like that can be 
avoided in the future.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: Use-case for non-AEAD ciphers in network monitoring

[Andrei Popov]

This NIST 
workshop
 is investigating the exact problem discussed on this thread. Several types of 
solutions have been proposed there.

Cheers,

Andrei

From: TLS  On Behalf Of Darin Pettis
Sent: Monday, May 17, 2021 2:04 PM
To: Stephen Farrell 
Cc: tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] Use-case for non-AEAD ciphers in network 
monitoring

Hi Stephen,
Thanks for the quick reply as I know it is getting late in Ireland.

I’m sure you do remember the conversation as you spent a lot of time at the 
microphone around it.  :-)

It is certainly not an easy question to answer but this group comprises the 
smartest people that I know!!  Surely someone must be up for the challenge as 
fully half of the people in that London hall voiced the need for it.  
Furthermore, when the day comes that TLS 1.2 can’t be used anymore, for 
whatever the reason, this need is going to come racing down the tracks…

So, while everyone is breathing easy right now, it would be great to address 
the need proactively.

Respectfully,
Darin

On Mon, May 17, 2021 at 3:48 PM Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>> wrote:

Hiya,

On 17/05/2021 21:33, Darin Pettis wrote:
> TLS 1.3 did a great job regarding safety of data on the Internet. For the
> next version, let’s focus on how to best meet this used case

I think we had this discussion a few years ago. There is
no sensible boundary at which TLS can apply different
cryptographic treatment.

There were also many many other points raised at that
time that I don't think we'll benefit from repeating.

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

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

[Andrei Popov]

Hi Brian,


  *   Look at Windows Server 2012 and similar legacy products that are in 
widespread use, which don't support any PFS cipher suites except FFDHE.
Windows Server 2012/Windows 8 support both TLS_ECDHE_ECDSA and TLS_ECDHE_RSA 
cipher suites: TLS Cipher Suites in Windows 8 - Win32 apps | Microsoft 
Docs

Our telemetry shows extremely low usage of TLS_DHE cipher suites and I’m in 
favor of deprecating them.

Cheers,

Andrei

From: TLS  On Behalf Of Brian Smith
Sent: Monday, March 8, 2021 4:13 PM
To: Martin Thomson 
Cc:  
Subject: [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

It is sad that nobody is willing to discuss the obvious downsides of this 
proposal as written, which should at least be mentioned in the security 
considerations. Without discussing the downsides we're reducing engineering to 
politics. If we discuss the downsides then we can substantially improve the 
proposal.

Deprecating FFDHE key exchange without deprecating RSA key exchange will 
substantially increase the usage of RSA key exchange and thus make server key 
compromise more dangerous. At a minimum, RSA key exchange should be deprecated 
at the same time, in the same document.

Look at Windows Server 2012 and similar legacy products that are in widespread 
use, which don't support any PFS cipher suites except FFDHE. Please deprecate 
RSA key exchange at the same time so that there is enough motivation for 
vendors of these legacy products to add safe alternatives and/or for users of 
these legacy implementations to upgrade to something new that implements a safe 
alternative. (Note that Windows Server 2012 did add a patch to enable 
increasing its FFDHE key size to safe sizes.)

It would be useful for the browser vendors that recently dropped FFDHE support 
to share their measurements for how much RSA key exchange usage increased after 
their changes. That would help us quantify the real-world impact of this change.

RSA key exchange uses flawed and error-prone cryptography that is prone to side 
channels as well, PKCS#1 encryption/decryption. Previous studies have found 
widespread flaws in implementations that are (AFAICT) even more easily 
exploitable than the Racoon attack is.

It is easy to imagine a perfect implementation of RSA key exchange that also 
perfectly protects the server's private key. It is unrealistic to expect 
implementations to actually live up to that ideal. When RSA key exchange is 
used, then a government that can effectively undo all the past encryption of a 
server if it can force the server operator to disclose the key, even for a 
perfect implementation of RSA key exchange.

Deprecating RSA key exchange at the same time as FFDHE will encourage adoption 
of newer products that also often support TLS 1.3.

Without creating a new, correct, way to use FFDHE key exchange, we're left with 
elliptic curve (ECDHE) key exchange as the only reasonable and 
widely-implemented key exchange mechanism.

Cheers,
Brian
(Speaking only for myself)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: Regarding draft-bartle-tls-deprecate-ffdhe

[Andrei Popov]

TLS_DHE is weak when used with interoperable key lengths. It also causes 
interop issues dues to several instances of under-specification (leading zeros, 
lack of group negotiation). I'm in favor of deprecating TLS_DHE.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Monday, March 8, 2021 10:09 AM
To: David Benjamin ; Carrick Bartle 

Cc:  
Subject: [EXTERNAL] Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

One thing at a time?

On Tue, Mar 9, 2021, at 05:05, David Benjamin wrote:
> I'd suggest we also deprecate TLS 1.2 TLS_DHE_*, even when ephemeral:
> 
> - The construction is broken. The leak itself in the Raccoon attack 
> comes from TLS 1.2 removing leading zeros. We can't change the meaning 
> of the existing code points, so any fix there would involve dropping 
> them.
> 
> - It lacks group negotiation, which makes it very difficult to migrate 
> away from small groups. At least in the web, it's already no longer 
> supported by most implementations.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> ps.google.com%2Fa%2Fchromium.org%2Fg%2Fblink-dev%2Fc%2FAAdv838-koo%2Fm
> %2FbJv17voIBAAJdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5
> f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C
> 0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=eb3SfPDYI
> BMeqtBRlCwTB5U4kc4r9%2FkREnmrHN%2FAegc%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.mozilla.org%2Fshow_bug.cgi%3Fid%3D1496639data=04%7C01%7CAndr
> ei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf
> 86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C2000sdata=jQ0%2B%2Bh9q%2BSdHqIpeEyr9M08p8cAD6MG5U9OG4z9ybN
> 4%3Dreserved=0
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweak
> dh.org%2Fdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc
> 7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 7508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=nyyFho5b73MVWuD
> nV0uBdfZB2sUs4WUHox4q4aI3m9M%3Dreserved=0
> 
> On Mon, Mar 8, 2021 at 12:52 PM Carrick Bartle 
>  wrote:
> > Agreed. I'll change the title to reflect that.
> > 
> > > On Mar 8, 2021, at 7:33 AM, Martin Thomson  wrote:
> > > 
> > > Well overdue.  We should do this.
> > > 
> > > The title "Deprecating FFDH(E) Ciphersuites in TLS" doesn't seem to match 
> > > the document content.  I only see static or semi-static DH and ECDH key 
> > > exchange being deprecated (in the document as non-ephemeral).
> > > 
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.
> > > Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988b
> > > f86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7
> > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > > CJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJl
> > > MxGrSHmk%3Dreserved=0
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popo
> > v%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3D&
> > amp;reserved=0

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=04%7C01%7CAndrei.Popov%40microsoft.com%7C47c5f995fc7949dc806108d8e25d6a80%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637508238161348087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=b4N4EYeD9YENeDJ4JDBTtz19UdCoeb1AhJlMxGrSHmk%3Dreserved=0

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

Re: [TLS] [EXTERNAL] Re: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

[Andrei Popov]

As written, the document provides a basic/general description of MITM proxies. 
It mentions some of the issues (client auth, handling of 0-RTT application 
data, single point of failure, updates/patches, risks of disclosure of 
PII/PHI), but does not really provide alternatives or specific solutions. I 
oppose adoption of this document in its current shape.

Some specific issues:

  *   The document does not describe alternatives to MITM proxies.
  *   Section 4.1.2 “Inbound provisioning” does not discuss security and 
operational issues around server key sharing with the proxy. No real discussion 
of short-lived creds and “keyless” scenarios.
  *   Section 4.2 “Maintain security posture and limit modifications” seems to 
recommend modifications to the ClientHello, rather than having the proxy 
generate a new ClientHello. Proxies sending ClientHellos they did not generate 
are a common cause of interop issues.
  *   Section 4.2 also explicitly allows completely insecure configurations:

  “TLS proxy stacks MAY provide user configurable options, such as an
   option to accept self-signed server certificates, an option to let
   the handshake continue with expired but otherwise valid server
   certificates, etc.”

Cheers,

Andrei

From: TLS  On Behalf Of Nick Harper
Sent: Monday, July 27, 2020 7:12 AM
To: Ben Schwartz 
Cc: Jen Linkova ; Nancy Cam-Winget (ncamwing) 
; OpSec Chairs ; 
OPSEC ; tls@ietf.org
Subject: [EXTERNAL] Re: [TLS] [OPSEC] Call For Adoption: 
draft-wang-opsec-tls-proxy-bp

As currently written, this draft has multiple problems.

Section 4 decides not to repeat the Protocol Invariants described in section 
9.3 of RFC 8446. However, further sections are written assuming that a proxy 
acts in a way contrary to those Protocol Invariants. One such example is 
section 4.2 in this draft. It describes how a proxy might generate its list of 
cipher suites by modifying the client's list. A proxy that copies the cipher 
suites from the client-initiated ClientHello into its own ClientHello is 
violating the 1st and 3rd points of the TLS 1.3 Protocol Invariants. For a best 
practices document, I think it would be reasonable to reiterate the Protocol 
Invariants.

In addition to reiterating the Protocol Invariants, it should also summarize 
the advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One of 
the problems pointed out by those papers is that TLS proxies will make 
connections to a server that presents a certificate the client wouldn't accept, 
but because of the proxy, the client isn't aware of the certificate issues. I 
don't see this issue addressed at all in the draft. (A similar issue with the 
server selecting a weak cipher suite is possibly implied by section 4.2, but it 
is not spelled out well.)

If this draft is adopted, it needs to say the following things, which it 
currently doesn't.

- When a TLS proxy generates its ClientHello, it should be created 
independently from the client-initiated ClientHello. The proxy MAY choose to 
omit fields from its ClientHello based on the client-initiated ClientHello, but 
it MUST NOT add fields to its ClientHello based on the client-initiated 
ClientHello. This is effectively a restatement of the 1st (a client MUST 
support all parameters it sends) and 3rd (it MUST generate its own ClientHello 
containing only parameters it understands) points of the TLS 1.3 Protocol 
Invariants.

- If a proxy chooses to conditionally proxy TLS connections and needs more 
information than what is contained in the client-initiated ClientHello, then 
the only way to make that decision is to send its own ClientHello to the server 
the client is connecting to and use information observed on that connection to 
make the decision to proxy the pending connection.

- If a proxy chooses to not proxy some TLS connections, the proxy will fail 
open. The only way to avoid failing open is to proxy all connections.

On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz 
mailto:40google@dmarc.ietf.org>> wrote:
I'm concerned about this work happening outside the TLS working group.  For 
example, the question of proper handling of TLS extensions is not addressed at 
all in this draft, and has significant security and functionality implications. 
 There are various other tricky protocol issues (e.g. version negotiation, TLS 
1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock 
when buffers fill, ticket (non-)reuse, client certificate linkability 
pre-TLS-1.3, implications of SAN scope of synthesized certificates) that could 
arise and are going to be difficult to get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is possible to proxy TLS 
correctly, and that this document is the main source for how to do it.  I think 
the TLS WG is the right place to make those judgments..  For the OpSec group, I 
think a more appropriate draft would be something like "TLS Interception 
Pitfalls", documenting the operational 

Re: [TLS] [EXTERNAL] Re: consensus call: draft-ietf-tls-ticketrequests

[Andrei Popov]

Hi Nico,

> But also, this WG has tried to accomodate things like SChannel whose API 
> designs are very different from others and impinge on what is feasible in the 
> protocol.  E.g., reconnects are avoided.
Both Session ID-based and session ticket-based TLS resumption options are 
supported in schannel. It is true that the API design is different from others 
(GSS-like, an attempt to match Windows APIs used for other security protocols, 
e.g., Kerberos).

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Nico Williams
Sent: Wednesday, March 4, 2020 9:17 PM
To: Watson Ladd 
Cc: TLS List 
Subject: [EXTERNAL] Re: [TLS] consensus call: draft-ietf-tls-ticketrequests

On Wed, Mar 04, 2020 at 08:32:45PM -0800, Watson Ladd wrote:
> On Wed, Mar 4, 2020 at 6:07 PM Stephen Farrell 
>  wrote:
> > On 04/03/2020 16:06, Sean Turner wrote:
> > >  Must the ticket reuse use case be addresses  in 
> > > draft-ietf-tls-ticketrequests?
> >
> > Yes. I think Viktor's use case is one to not bugger up (even if one 
> > doesn't need to support it) and don't see how supporting it breaks 
> > something. (While also disliking generic ticket reuse.)
> 
> It's not the usecase: it's the program. Postfix made architectural 
> choices that make storing tickets allegedly expensive.

Well, Postfix runs about 40% of the world's email infrastructure outside of 
gmail and yahoo and such, so excuse me, but your response is just not 
acceptable.

But also, this WG has tried to accomodate things like SChannel whose API 
designs are very different from others and impinge on what is feasible in the 
protocol.  E.g., reconnects are avoided.

Nico
-- 

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf68655dfdfb74261cbe408d7c0c4787e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189822393462003sdata=%2F1yYpQkjpBiS7BTz1ZMcEVO4VzTf7AnYfrrOrQR5blQ%3Dreserved=0

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

Re: [TLS] [EXTERNAL] Explicit curve parameters in Server Key Exchange messages

[Andrei Popov]

Hi Juraj,

> related to the recent Windows/NSA custom curve certificate issues, we are 
> wondering whether there are any implementations also supporting explicit 
> curves in TLS server key exchange messages...
Just to clarify: Windows TLS stack only supports named_curve in SKE messages.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of Juraj Somorovsky
Sent: Friday, January 17, 2020 5:08 AM
To: tls@ietf.org
Cc: Robert Merget ; Nimrod Aviram 

Subject: [EXTERNAL] [TLS] Explicit curve parameters in Server Key Exchange 
messages

Dear all,

related to the recent Windows/NSA custom curve certificate issues, we are 
wondering whether there are any implementations also supporting explicit curves 
in TLS server key exchange messages as defined in
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4492%23section-5.4data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf76997d47f804c33ab4208d79b6f7aab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637148775489120191sdata=EQNVhlVtJnLlpuRF3eIVwbAfu9bivC%2FXsuFSjvmzS40%3Dreserved=0

Typical TLS implementations we are aware of only support named curves in server 
key exchange messages.

Note that this is different from the custom curves in X.509 certificates. 
According to RFC4492, it is also possible to use custom explicit curves 
directly in the TLS protocol.

Thank you

--
Dr.-Ing. Juraj Somorovsky

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
---
Universitätsstr. 150, Geb. ID 2/403
D-44780 Bochum

Telefon: +49 (0) 234 / 32-26740
Fax: +49 (0) 234 / 32-14347
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nds.rub.de%2Fchair%2Fpeople%2Fjsomorovskydata=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf76997d47f804c33ab4208d79b6f7aab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637148775489120191sdata=D76wCkI5gs0H5%2ByMcBlcUMZ3Alec5EpfOjJ2X8xVyX0%3Dreserved=0
@jurajsomorovsky

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf76997d47f804c33ab4208d79b6f7aab%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637148775489120191sdata=4UsAJvqTSE2ICmMsHHe78j3haF25CDxqsvFkT3ZmXFU%3Dreserved=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Andrei Popov]

My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data 
records must still be encrypted and authenticated. Otherwise, MITM can inject 
arbitrary numbers of these.

However, the current language is vague enough that I've seen major SW vendors 
send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is 
RFC-compliant, because " Zero-length fragments of Application Data MAY be sent".

Therefore, I support clarifications in this area.

Cheers,

Andrei

-Original Message-
From: TLS  On Behalf Of RFC Errata System
Sent: Friday, October 11, 2019 9:22 PM
To: e...@rtfm.com; r...@cert.org; ka...@mit.edu; c...@heapingbits.net; 
j...@salowey.net; sean+i...@sn3rd.com
Cc: lper...@bellaliant.net; tls@ietf.org; rfc-edi...@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC8446 (5874)

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3Dreserved=0

--
Type: Technical
Reported by: Mr Laurie Perrin 

Section: 5.1

Original Text
-
.

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data MAY be sent, as they are potentially
   useful as a traffic analysis countermeasure.  Application Data
   fragments MAY be split across multiple records or coalesced into a
   single record.

Corrected Text
--
.

   Application Data messages contain data that is opaque to TLS.
   Application Data messages are always protected.  Zero-length
   fragments of Application Data (i.e. those encapsulating an
   TLSInnerPlaintext record having a content field of length zero)
   MAY be sent, as they are potentially useful as a traffic analysis
   countermeasure. Application Data fragments MAY be split across
   multiple records or coalesced into a single record.

Notes
-
In the interest of clarity, it may be prudent to specify the type of record for 
which a fragment of length zero is being considered - it cannot be that of the 
TLSCiphertext itself, for "Application Data messages are always protected,"
therefore I infer this relates to the TLSInnerPlaintext content field (of 
length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment.

Note: This comment also applies to previous versions of the TLS specification, 
in particular with the introduction of the respective text concerning 
zero-length fragments in RFC 5246. In TLS 1.2, this would be the 
GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the 
TLSCompressed fragment.

Note: The implications of zero-length records must be considered with respect 
to potential vectors for denial of service.

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3Dreserved=0

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

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

[Andrei Popov]

> It is not clear if the proposal you outlined share this property; do you 
> duplicate a payload that an unenhanced server would assume only occurs once?
I think this property is preserved: only a server that knows the 
hybrid-key-exchange extension (or perhaps, a more specific 
one-traditional-and-one-PQ extension) will send KeyShareServerHello with two 
KeyShareEntries.
An “unenhanced” server will send only one KeyShareEntry. We’d need to think 
about how the “enhanced” client can distinguish the two KeyShareServerHello 
formats, but there are easy solutions to this, I think.

From: Scott Fluhrer (sfluhrer) 
Sent: Tuesday, July 30, 2019 12:44 PM
To: Andrei Popov ; David Benjamin 
; Watson Ladd 
Cc: TLS List 
Subject: RE: [TLS] Options for negotiating hybrid key exchanges for postquantum

I believe that one important property (of either of the options I listed) is a 
nice fallback if an enhanced client talks to an older server.  In both cases, 
the server will see a series of named groups that it doesn’t know (which it 
will ignore), and possibility an extension it doesn’t know (which it will 
ignore); the server will accept either a named group that it does understand 
(if the client did propose a traditional group as a fall back), or it will come 
to the correct conclusion that the two sides have no mutually acceptable 
security policy.

It is not clear if the proposal you outlined share this property; do you 
duplicate a payload that an unenhanced server would assume only occurs once?

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Andrei Popov
Sent: Tuesday, July 30, 2019 2:48 PM
To: David Benjamin mailto:david...@chromium.org>>; 
Watson Ladd mailto:watsonbl...@gmail.com>>
Cc: TLS List mailto:tls@ietf.org>>
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

Given these options, I also prefer option 2, for some of the same reasons.

For my understanding though, why not have the client advertise support for 
hybrid-key-exchange (e.g. via a “flag” extension) and then KeyShareServerHello 
can contain two KeyShareEntries (essentially, using the same format as 
KeyShareClientHello? This would solve the Cartesian product issue.

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
David Benjamin
Sent: Tuesday, July 30, 2019 11:24 AM
To: Watson Ladd mailto:watsonbl...@gmail.com>>
Cc: TLS List mailto:tls@ietf.org>>
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I think this underestimates the complexity cost of option 1 to the protocol and 
implementations. Option 1 means group negotiation includes entire codepoints 
whose meaning cannot be determined without a parallel extension. This compounds 
across everything which interacts with named groups, impacting everything from 
APIs to config file formats to even UI surfaces. Other uses of NamedGroups are 
impacted too. For instance, option 2 fits into draft-ietf-tls-esni as-is. 
Option 1 requires injecting hybrid_extension into ESNI somehow. Analysis must 
further check every use, say, incorporates this parallel lookup table into 
transcript-like measures.

The lesson from TLS 1.2 code points is not combined codepoints vs. split ones. 
Rather, the lesson is to avoid interdependent decisions:

* Signature algorithms in TLS 1.2 were a mess because the ECDSA codepoints 
required cross-referencing against the supported curves list. The verifier 
could not express some preferences (signing SHA-512 with P-256 is silly, and 
mixing hash+curve pairs in ECDSA is slightly off in general). As analogy to 
option 1's ESNI problem, we even forgot to allow the server to express curve 
preferences. TLS 1.3 combined signature algorithm considerations into a single 
codepoint to address all this.

* Cipher suites in TLS 1.2 were a mess because they were half-combined and 
half-split. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 said to use some ECDHE key 
exchange, but you need to check if you have a NamedGroup in common first. It 
said to use ECDSA, but you need to check signature algorithms (which themselves 
cross-reference curves) first. Early drafts of TLS 1.3 had it even worse, where 
a TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 full handshake morphed into 
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 on resumption. Thus, TLS 1.3 cipher 
suites negotiate solely AEAD + PRF hash.

In fairness to TLS 1.2, some of this was a consequence of TLS 1.2's evolution 
over time as incremental extensions over SSL 3.0. And sometimes we do need to 
pay costs like these. But hybrid key exchanges fit into the NamedGroup "API" 
just fine, so option 2 is the clear answer. Code points are cheap. Protocol 
complexity is much more expensive.

It's true that standards are often underspecified. This means the IETF should 
finish the job, not pass all variations through. RSA-PSS is a clear example of 
what to avoid. It takes more bytes to merely utter "RSA-

Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

[Andrei Popov]

Sure, hybrid-key-exchange “flag” extension is too generic. We could have the 
client advertise something like one-traditional-and-one-PQ, and still avoid the 
Cartesian product.
From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, July 30, 2019 12:12 PM
To: David Benjamin 
Cc: TLS List 
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

The nuisance with just a flag is the client can't express [what I think are] 
reasonable preferences. It should be able to say things like:

Offhand, I don’t see at all why the client should be able to say any of these 
“don’t”s:

* Don't do X25519 + P-256. This is just silly.
* Don't do PQ1 on its own. I really want the PQ scheme paired with something 
more established.
* Don't do PQ1 + PQ2. I said something more established, please.
* Don't do PQ1 + X25519 + P-256. Why are you doing three of these?
* Don't do PQ1 + PQ2 + PQ3 + PQ4 + X25519 + P-256 + P-384 + FFDHE2048 + 
FFDHE3072, oww my head.

This is the only thing that IMHO the client should be able to say:

* PQ1 + X25519 is cool. I like that combo.




On Tue, Jul 30, 2019 at 2:48 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:
Given these options, I also prefer option 2, for some of the same reasons.

For my understanding though, why not have the client advertise support for 
hybrid-key-exchange (e.g. via a “flag” extension) and then KeyShareServerHello 
can contain two KeyShareEntries (essentially, using the same format as 
KeyShareClientHello? This would solve the Cartesian product issue.

Cheers,

Andrei

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
David Benjamin
Sent: Tuesday, July 30, 2019 11:24 AM
To: Watson Ladd mailto:watsonbl...@gmail.com>>
Cc: TLS List mailto:tls@ietf.org>>
Subject: Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

I think this underestimates the complexity cost of option 1 to the protocol and 
implementations. Option 1 means group negotiation includes entire codepoints 
whose meaning cannot be determined without a parallel extension. This compounds 
across everything which interacts with named groups, impacting everything from 
APIs to config file formats to even UI surfaces. Other uses of NamedGroups are 
impacted too. For instance, option 2 fits into draft-ietf-tls-esni as-is. 
Option 1 requires injecting hybrid_extension into ESNI somehow. Analysis must 
further check every use, say, incorporates this parallel lookup table into 
transcript-like measures.

The lesson from TLS 1.2 code points is not combined codepoints vs. split ones. 
Rather, the lesson is to avoid interdependent decisions:

* Signature algorithms in TLS 1.2 were a mess because the ECDSA codepoints 
required cross-referencing against the supported curves list. The verifier 
could not express some preferences (signing SHA-512 with P-256 is silly, and 
mixing hash+curve pairs in ECDSA is slightly off in general). As analogy to 
option 1's ESNI problem, we even forgot to allow the server to express curve 
preferences. TLS 1.3 combined signature algorithm considerations into a single 
codepoint to address all this.

* Cipher suites in TLS 1.2 were a mess because they were half-combined and 
half-split. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 said to use some ECDHE key 
exchange, but you need to check if you have a NamedGroup in common first. It 
said to use ECDSA, but you need to check signature algorithms (which themselves 
cross-reference curves) first. Early drafts of TLS 1.3 had it even worse, where 
a TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 full handshake morphed into 
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 on resumption. Thus, TLS 1.3 cipher 
suites negotiate solely AEAD + PRF hash.

In fairness to TLS 1.2, some of this was a consequence of TLS 1.2's evolution 
over time as incremental extensions over SSL 3.0. And sometimes we do need to 
pay costs like these. But hybrid key exchanges fit into the NamedGroup "API" 
just fine, so option 2 is the clear answer. Code points are cheap. Protocol 
complexity is much more expensive.

It's true that standards are often underspecified. This means the IETF should 
finish the job, not pass all variations through. RSA-PSS is a clear example of 
what to avoid. It takes more bytes to merely utter "RSA-PSS with SHA-256 and 
usual parameters" in X.509 than to encode an entire ECDSA signature! We should 
not define more than a handful of options, regardless of the encoding...

On Tue, Jul 30, 2019 at 12:18 PM Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:

On Tue, Jul 30, 2019, 8:21 AM Scott Fluhrer (sfluhrer) 
mailto:sfluh...@cisco.com>> wrote:
During the physical meeting in Montreal, we had a discussion about postquantum 
security, and in particular, on how one might want to negotiate several 
different ‘groups’ simultaneously (because there might not be one group that is 
entirely trusted, and I put ‘groups’ in scarequotes because 

Re: [TLS] A use of flags

[Andrei Popov]

> No resumption in TLS 1.3...
You probably mean no renegotiation in TLS 1.3.

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Friday, March 29, 2019 10:25 AM
To: Hubert Kario ; tls@ietf.org
Subject: Re: [TLS] A use of flags

On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote:
> what about resumption and renegotiation?

No certificates in resumption.

No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more).

___
TLS mailing list
TLS@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftlsdata=02%7C01%7CAndrei.Popov%40microsoft.com%7Cb0eec22e1db4492231f408d6b428b219%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636894484211356742sdata=t0K5DCsx%2FZIV%2Bs7bnUe5lZO0SHtqqCT005GGRAuptUM%3Dreserved=0

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Andrei Popov]

> I don't think the TLS WG or IETF can win this skirmish.  
That's what I'm thinking as well, although I agree with the goals of 
draft-dkg-tls-reject-static-dh-01.

Cheers,

Andrei

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

Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Andrei Popov]

I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will cost 
servers some perf:

   "Given the concerns in Section 2 and the necessary client mitigations
   in the subsections above, servers need to avoid giving the appearance
   of using non-ephemeral DH.  Servers MUST NOT reuse ephemeral DH
   shares."

In our tests, we see significant drop in handshakes/sec on a busy TLS server 
with ephemeral DH share reuse time < 1 sec.

Also, won't the "enterprise TLS" server just create a bunch of static DH shares 
and send different ones at different times, thereby avoiding detection by most 
clients?

Cheers,

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

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Andrei Popov]

> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into TLS 
> was a mistake, and glad to see them gone in TLS 1.3.

I agree with the sentiment, but there is a concerted effort to bring fixed 
(EC)DH to TLS 1.3:
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf

It seems that a client that is not willing to participate has to actively look 
for and reject server certs with "VisibilityInformation" in them.
Except this won't always help, because "In some essential circumstances, the 
visibility information field may be omitted."

Cheers,

Andrei

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

Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[Andrei Popov]

On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time 
on the client side (this includes non-browser connections from all sorts of 
apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client 
connections.
Windows server negotiates TLS 1.0 ~1.5% of the time (all server apps, not just 
IIS), and the use of TLS 1.1 is negligible.

Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but will 
keep looking at the telemetry. If PCI/NIST/diediedie RFC make a difference, 
I’ll be happy to reduce the set of enabled-by-default TLS versions.

Cheers,

Andrei

From: TLS  On Behalf Of Eric Rescorla
Sent: Monday, July 9, 2018 9:57 AM
To: Kathleen Moriarty 
Cc:  
Subject: Re: [TLS] Fwd: New Version Notification for 
draft-moriarty-tls-oldversions-diediedie-00.txt



On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Thanks for writing this.

I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox 
Telemetry shows that about 1% of our connections are TLS 1.1

This should be 1.0.


(on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.

This is probably a higher number than we'd be comfortable turning off 
immediately, but it is probably worth starting the process.

-Ekr


On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:

Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.  There has
been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.  NIST has also been recommending TLSv1.2
as a baseline.  Applications other than those using HTTP may not have
had the same reduction in usage.  If you are responsible for services
where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.  We've received some feedback that has been incorporated
into the working draft and feelers in general have been positive.  It
would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-diediedie

Thanks in advance,
Kathleen


-- Forwarded message --
From:  mailto:internet-dra...@ietf.org>>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell 
mailto:stephen.farr...@cs.tcd.ie>>, Kathleen Moriarty
mailto:kathleen.moriarty.i...@gmail.com>>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:   draft-moriarty-tls-oldversions-diediedie
Revision:   00
Title:  Deprecating TLSv1.0 and TLSv1.1
Document date:  2018-06-18
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt
Status:
https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
   This 

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

Doesn’t IETF have a liaison process that is used to work with other standards 
bodies?
And the bigger question, since the ask is essentially for a multi-party 
security protocol: Is TLS WG the right place to discuss this?

Cheers,

Andrei

From: TLS  On Behalf Of Russ Housley
Sent: Thursday, March 15, 2018 10:29 AM
To: IETF TLS 
Subject: Re: [TLS] TLS@IETF101 Agenda Posted


  *   >> Nalini, why don't you (the consortium) define the standard, then?

> Indeed, if a “TLS13-visibility” standard has to be defined, it would make 
> sense for the consortium (rather than the TLS WG) to define it.

In fact, my mistake that was caught by Martin is exactly the reason that we 
want the experts in the TLS WG to review the document.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

> If your consortium want a multi-party security protocol that does not affect 
> other folks' security as you seem to claim, then that is the obvious route to 
> explore.

+1. It seems that this is at the core of the request. In which case the proper 
solution is to define this multi-party protocol, not to modify TLS for this 
purpose.

Cheers,

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   Second, using TLS1.2 does not technically address the issue.  If the 
client were to exclusively offer DHE-based ciphersuites, then the visibility 
techniques that have been used in the past are thwarted.
  *   Yes, the server cannot use the "tls_visibility" extension unless the 
client offers it.  This is to enable client opt-in.

It looks like both the TLS1.2 solution and “TLS1.3-visibility” depend on the 
client to support certain options…

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   If the client were to exclusively offer DHE-based ciphersuites, then the 
visibility techniques that have been used in the past are thwarted.
TLS1.3-visibility will be equally thwarted if the client does not send the 
empty "tls_visibility" extension, right?
(Assuming the server chooses to play by the rules, of course.)

Cheers,

Andrei

From: TLS  On Behalf Of Russ Housley
Sent: Tuesday, March 13, 2018 3:17 PM
To: Ted Lemon 
Cc: IETF TLS 
Subject: Re: [TLS] TLS@IETF101 Agenda Posted

Ted:

There's an easy way to do this, although as a sometime bank security geek I 
would strongly advise you to not do it: keep using TLS 1.2.

This is a bogus argument.  First, staying with an old protocol version often 
leads to locking in unmaintained versions of old software.  Second, using 
TLS1.2 does not technically address the issue.  If the client were to 
exclusively offer DHE-based ciphersuites, then the visibility techniques that 
have been used in the past are thwarted.

Russ

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

  *   "We" is a consortium of organizations.   I would say over 50 so far.  
They operate large data centers.   They are in manufacturing, insurance, 
finance, and others.


  *   Nalini, why don't you (the consortium) define the standard, then?

Indeed, if a “TLS13-visibility” standard has to be defined, it would make sense 
for the consortium (rather than the TLS WG) to define it.

Cheers,

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

Re: [TLS] Duplicate oid_filters

[Andrei Popov]

It should be OK to restrict to one appearance of the same OID, if there is a 
desire to do so.

-Original Message-
From: TLS  On Behalf Of Benjamin Kaduk
Sent: Friday, March 9, 2018 1:45 PM
To:  
Subject: Re: [TLS] Duplicate oid_filters

(See also 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1179=04%7C01%7CAndrei.Popov%40microsoft.com%7Cddb0cb5ca2684dcdf7d708d58607050a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636562287068258523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2=3QfikwA9T0ScU6Yw9T%2Fo3IDhmj1zYgcJzye1sx5M%2Bp0%3D=0)

On 03/09/2018 03:35 PM, Eric Rescorla wrote:
> See issue #1166.
>
> The current text neither allows nor prohibits the same OID appearing 
> twice. We should do one or the other.
>

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7CAndrei.Popov%40microsoft.com%7Cddb0cb5ca2684dcdf7d708d58607050a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636562287068258523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2=ArdtWlWWMO0DfeuREq%2F1ab8vNFhxvhoLW1yWIz089Oc%3D=0

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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Andrei Popov]

> Ideally, you'd want certificates to be able to have two signatures during
> the transition period, in order to support clients who have transitioned and
> those who have not.

> Hosting multiple certificates and switching based on the client is feasible,
> but requires some technical wizardry and isn't possible in all situations.

For my understanding, why is the former (double-signed certs, where either 
signature is trusted) better than the latter (multiple certs with different 
algorithms)?
The latter is currently supported by some TLS servers.

Cheers,

Andrei

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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Andrei Popov]

It's true, the migration will be slow, but IMHO it still makes sense to define 
and implement an alternative hash.

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Friday, December 15, 2017 10:34 AM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in 
general, and what we can do in TLS

On Fri, Dec 15, 2017 at 10:15:23AM -0800, Eric Rescorla wrote:
> On Fri, Dec 15, 2017 at 10:12 AM, Watson Ladd  wrote:
> 
> > We can force a rotate of all certs in 90 days, and I don't think 
> > most people will notice.
> >
> 
> Unfortunately, there are plenty of longterm certificates with 
> lifetimes >>
> 90 days.

Yes, currently the lifetime limit for public certificates is 39 months, and 
will be reduced to 825 days (~27 months) effective March 2018.


Then there is backdating to consider. It was seen in both MD5 and SHA-1 
deprecations. So maximum certificate lifetime sets limit on how fast features 
can be flushed out.

And then there would be enormous amounts of endpoints not supporting anything 
better. Those would have to be upgraded.

All in all, a real mess.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7CAndrei.Popov%40microsoft.com%7C248257e4202549b54e9208d543ea7ff7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489596817634560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=viW%2F6xW3bJoG6SlxgENwp%2BFH8%2Bqnb%2BFynkE4Yxfq%2Bjc%3D=0

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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Andrei Popov]

Correct.

-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Friday, December 15, 2017 9:46 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in 
general, and what we can do in TLS

On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote:
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> > Even nastier dependency: SHA-2. If that breaks, currently both TLS
> > 1.2 and 1.3 break. There are no alternatives defined.
> 
> Here's an attempt to define a SHA-2 alternative: 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools
> .ietf.org%2Fhtml%2Fdraft-wconner-blake2sigs-01=04%7C01%7CAndrei.P
> opov%40microsoft.com%7C30de6e3a48024110441608d543e3c8b7%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C636489567969040822%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&
> sdata=f72MvX0ydw5WvjkvngbY39sai8v9oOc5ZUYZOQI3XmI%3D=0

Also would need TLS ciphersuite codepoints with alternative handshake hash 
algorithms.


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

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Andrei Popov]

Here's an attempt to define a SHA-2 alternative: 
https://tools.ietf.org/html/draft-wconner-blake2sigs-01

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Friday, December 15, 2017 6:31 AM
To: Colm MacCárthaigh 
Cc: tls@ietf.org
Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in 
general, and what we can do in TLS

On Thu, Dec 14, 2017 at 05:05:37PM -0800, Colm MacCárthaigh wrote:

> But I do think the question
> is worth having an answer for. I think we *do* need to prepare for 
> turning off AES, there's always a chance we might have to.

Even nastier dependency: SHA-2. If that breaks, currently both TLS 1.2 and 1.3 
break. There are no alternatives defined.

Yes, sure SHA-2 has taken a lot of cryptoanalysis without serious trouble (I 
think one reason for starting SHA-3 process was preceived weakness in SHA-2, 
that later turned out not to be the case). 


-Ilari

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7CAndrei.Popov%40microsoft.com%7C22779f9a38834781928208d543c87f97%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636489450805010503%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=yVHsF021AGtXGR0DDpm2mV07gsCThPjk%2BGsDm8R4UyE%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Transcript-Hash during Handshake

[Andrei Popov]

Thanks, Ilari!

-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Thursday, November 23, 2017 11:52 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Peter Wu <pe...@lekensteyn.nl>; Le Van Gong, Hubert <hub...@levangong.org>; 
tls@ietf.org
Subject: Re: [TLS] Transcript-Hash during Handshake

On Thu, Nov 23, 2017 at 07:42:12PM +, Andrei Popov wrote:
> To confirm, TLSInnerPlaintext.type and TLSInnerPlaintext.zeros are not 
> part of the handshake messages, and therefore are not included in the 
> transcript hash?

Correct. The transcript hash is also not affected by fragmentation.

E.g. in TLS 1.3, the raw finished messag fed to SHA-256 is always
14 00 00 20 <32 bytes payload>. Regardless of padding and fragmnentation (for 
SHA-384, that would be 14 00 00 30 <48 bytes
payload>).

(In DTLS, the header would be different and larger, but also not affected by 
padding and fragmentation).


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

Re: [TLS] Transcript-Hash during Handshake

[Andrei Popov]

To confirm, TLSInnerPlaintext.type and TLSInnerPlaintext.zeros are not part of 
the handshake messages, and therefore are not included in the transcript hash?

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Wu
Sent: Tuesday, November 21, 2017 7:59 PM
To: Le Van Gong, Hubert 
Cc: tls@ietf.org
Subject: Re: [TLS] Transcript-Hash during Handshake

Hi Hubert,

On Tue, Nov 21, 2017 at 07:38:16PM -0800, Le Van Gong, Hubert wrote:
> Greetings,
> 
> Probably a trivial question but is the transcript hash (during 
> handhsake) calculated over decrypted versions of messages like 
> EncryptedExtensions or certificate or is it done over the raw/encrypted 
> messages?
> I could not find an exact confirmation in the spec.

It covers the decrypted handshake messages, see
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tls-tls13-21%23section-4.4.1=02%7C01%7CAndrei.Popov%40microsoft.com%7C5f27ddaec3b4434c6d8c08d5315d6d6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469199703666199=KKJRCPF%2BNTbh0LGMZG2zRZQW9NK8tgeP1Ws07n4Wanc%3D=0

This value is computed by hashing the concatenation
of each included handshake message, including the handshake message
header carrying the handshake message type and length fields, but not
including record layer headers

(The only way to know the message type is to have it in cleartext.)
--
Kind regards,
Peter Wu
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flekensteyn.nl=02%7C01%7CAndrei.Popov%40microsoft.com%7C5f27ddaec3b4434c6d8c08d5315d6d6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469199703666199=aRZZ0GYkqQEaHN1lsEXjAjetzsXgfnRiITpqulNoFYk%3D=0

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7C5f27ddaec3b4434c6d8c08d5315d6d6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469199703666199=IDfdpwgg1JsBr%2BijxbZvRRzVVb5i5D3aIuEttiR0eDk%3D=0

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

Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Andrei Popov]

The idea was for the client to randomly add non-existent TLS versions to 
supported_versions.
Presumably, this will exercise the extensibility joint and prevent it from 
becoming unusable.

I'm not convinced this new approach will help, but we know the old one required 
fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre ; Eric Rescorla 
Cc: tls@ietf.org; Tapio Sokura 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry in 
the ServerHello.
The problem with future middleboxes should be obvious.


From: Peter Saint-Andre 
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469742719473989=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D=0

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

[TLS] TLS 1.3 Record Boundaries

[Andrei Popov]

Draft-21 says:
"Handshake messages MUST NOT span key changes.  Implementations
  MUST verify that all messages immediately preceding a key change
  align with a record boundary; if not, then they MUST terminate the
  connection with an "unexpected_message" alert.  Because the
  ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate
 messages can immediately precede a key change, implementations
  MUST send these messages in alignment with a record boundary."

It is not clear to me what "sending messages in alignment with a record 
boundary" means.
Does it mean that each record is either all plaintext or all encrypted with key 
X? And therefore one cannot combine, e.g., ServerHello (plaintext) and 
EncryptedExtensions (encrypted with the handshake traffic key) messages in one 
record?

Thanks,

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Andrei Popov]

  *   Industry groups will force us to use newer versions
  *   Likely there will be regulatory mandates in many of the marketplaces and 
business segments that large Enterprises participate in.
  *   Business Partners or Government agency customers may require TLS1.3.

These mandates/requirements are typically motivated by the realization that TLS 
Vn is more secure than TLS Vn-x.
One of the important reasons TLS 1.3 may be more secure than TLS 1.2 and below 
is that it does not offer non-PFS options.
Then deploying a weakened configuration of TLS 1.3 (without PFS) would not meet 
the intent of those future mandates/requirements.
Then do we gain anything by standardizing a weakened configuration of TLS 1.3?

Cheers,

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

Re: [TLS] Labels in the TLS 1.3 key schedule

[Andrei Popov]

> The labels _are_ ASCII, but _not_ NUL-terminated.

Thanks; I can't find any mention of character set or nul-termination in 
draft-21. Perhaps it would be a good idea to clarify.

Cheers,

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

Re: [TLS] Should CCM_8 CSs be Recommended?

[Andrei Popov]

It seems that CCM_8 falls in the “limited applicability” bucket. However, 
there’s nothing wrong with IoT specs requiring these ciphers in their TLS 
profiles.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey
Sent: Wednesday, October 4, 2017 11:42 AM
To: Salz, Rich 
Cc:  
Subject: Re: [TLS] Should CCM_8 CSs be Recommended?

The current editor's copy of the draft has the following text about the 
recommended column:


The instructions in this document add a recommended column to many of the TLS 
registries to indicate parameters that are generally recommended for 
implementations to support. Adding a recommended parameter to a registry or 
updating a parameter to recommended status requires standards action. Not all 
parameters defined in standards track documents need to be marked as 
recommended.

If an item is marked as not recommended it does not necessarily mean that it is 
flawed, rather, it indicates that either the item has not been through the IETF 
consensus process or the item has limited applicability to specific cases.

On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich 
> wrote:
➢  We’re recommending that these five suites be dropped from the recommended 
list.  Please let us know what you think.


Does “recommended” mean for general use, in the public Internet?  Or is it “I 
know it when I see it” kind of thing?

Either way, I support un-recommending them

___
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] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size

[Andrei Popov]

  *   I don't argue with this but this is not the approach TLS 1.3 took. It 
provides a generic padding mechanism to be used across application protocols.
At some point I thought we said that the TLS 1.3 padding mechanism was supposed 
to be application-driven (in the form of application-provided policy or simply 
desired pad size), which would mean that the application has to be involved 
anyway.

Cheers,

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Andrei Popov]

Ah, I get what you’re saying.

DH parameter reuse for performance reasons is not a good thing, and it is not 
something recommended in the TLS RFCs. But offering standardized ways of 
exporting/importing keys for wiretapping/surveillance/discovery/analysis 
purposes is quite different. If a browser were to support this, I would want to 
avoid using such a browser.

Industry or corporate standards could define key import/export/escrow methods, 
and certainly SW vendors may choose to support them.
At the IETF, IMHO, we can better contribute by focusing on key protection, 
non-exportability and attestation.

Cheers,

Andrei

From: Colm MacCárthaigh [mailto:c...@allcosts.net]
Sent: Thursday, July 20, 2017 8:57 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Stephen Farrell <stephen.farr...@cs.tcd.ie>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol



On Wed, Jul 19, 2017 at 11:40 PM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:
Hi Colm,


  *   Today browsers do turn on wiretapping support in the normal case. There's 
nothing they can do about it, and it works right now.
This is news to me; which browsers do this (so that I can avoid using them)?

Like I said, all of them. I don't know of a single browser that forces DH-only 
and insists on unique DH parameters today, and it wouldn't be practical.  So if 
we're going to refer to an operator who has the server's private key using 
their own key to decrypt traffic as wire-tapping, then in those terms currently 
all browsers have support for that turned on, as it's part of existing versions 
of TLS.

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Andrei Popov]

Hi Colm,


  *   Today browsers do turn on wiretapping support in the normal case. There's 
nothing they can do about it, and it works right now.

This is news to me; which browsers do this (so that I can avoid using them)?

Thanks,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Thursday, July 20, 2017 1:05 AM
To: Stephen Farrell 
Cc:  
Subject: Re: [TLS] datacenter TLS decryption as a three-party protocol


On Wed, Jul 19, 2017 at 3:50 PM, Stephen Farrell 
> wrote:
That is a perfect example of the hideous dangers of all of this.
The implication in the above is that browsers would/should turn
on wiretapping support in the normal case.

Today browsers do turn on wiretapping support in the normal case. There's 
nothing they can do about it, and it works right now.

If static-DH is permitted, and I don't mean if we release a document describing 
it, I mean if we don't forbid static DH parameters; this will also continue to 
be the case. My take: I think we should forbid static DH for this reason.

Next, if proxies are deployed as the mechanism, this will also continue to be 
the case. Again, nothing a browser can do, and I argue that real-world security 
is left much much worse for users too.

On the other hand, if we standardize a signaled, opt-in, mechanism; then 
browsers have more fine-grained options. I suspect that browsers would NOT 
support this by default, just as they don't accept private CAs by default. 
Instead the browser would have to configured per a corporate policy. But they 
could /also/ choose to disable incognito mode in such circumstances, to be more 
fair to end-users. It's an example of something that can't be done today at all.

Such a mode is likely fine for the corporate users and what they want, but is 
not so useful for intelligence agencies and so on, precisely because its 
signaled and a bit more transparent. In real world terms, I would regard it 
much /less/ likely to create the kind of MITM infrastructure that's useful for 
that case.

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

Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!

[Andrei Popov]

> As Stephen points out, it looks like we've allocated 80 minutes to the topic 
> of how to remove the forward secrecy guarantees that we've struggled for over 
> a year to introduce.  That's more than we've allocated for the "main point of 
> the TLS WG", which are only 65 minutes combined.

+1. Restating the same positions over and over again for 80 minutes might get 
repetitive... It seems that all we need is a quick summary from each side, 
perhaps some Q and a hum.

Cheers,

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Andrei Popov]

Would the Informational track be an acceptable compromise? This does not have 
to be a product of the TLS working group.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, July 7, 2017 10:17 AM
To: Russ Housley ; Richard Barnes 
Cc: IETF TLS ; Matthew Green 
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01

I think there is little doubt that the draft is technically sound.

The question is, should the IETF "endorse" this by saying it is a product of 
the TLS working group?  That will certainly send a mixed message to some.  As 
we heard around around Seoul, not adopting might send a message to some 
industries that we are not interested in helping to solve their problems.

It is a fraught issue.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Separate APIs for 0-RTT

[Andrei Popov]

  *   What if the server receives data with the 0-RTT boundary spanning an 
HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid?
It appears safe to treat such data as 0-RTT; only the application can make this 
call, and it needs info from the TLS stack to make this call.


  *   We could say that the application profile should modify the protocol to 
reject such cases. Now, we’re taking on complexity in every protocol 
specification and parser.
It would of course be preferable (some would argue, necessary) to secure 0-RTT 
application_data at the TLS layer, but so far we’ve failed to come up with a 
way to do so.


  *   Our problem is a server wishes not to process some HTTP requests (or 
other protocol units) at 0-RTT and needs to detect this case. So check a 
boolean signal for whether the connection has currently passed the 1-RTT point 
before any unsafe processing.
I think this would be a valid implementation of #3. There may be other 
implementation options that make more sense for a different TLS API or a 
different application protocol, so I’d rather not put a specific implementation 
option in the RFC.

Cheers,

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

Re: [TLS] Separate APIs for 0-RTT

[Andrei Popov]

Regarding RFC language, I think we could be more specific:



1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the 
application has explicitly opted in;

2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the 
application has explicitly opted in;

3. When delivering 0-RTT application data to the application, a TLS 
implementation SHOULD/MUST provide a way for the application to distinguish it 
from the rest of the application data.



Or some better phrasing that our capable editor can craft.



Cheers,



Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Tuesday, June 13, 2017 11:48 AM
To: Ilari Liusvaara ; Colm MacCárthaigh 

Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

On 06/13/2017 01:35 PM, Ilari Liusvaara wrote:


On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:

On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk 
 wrote:



I have been operating under the impression that at least some application

profiles for early data will require that certain application protocol

requests (e.g., something like HTTP POST) must be rejected at the

application layer as "not appropriate for 0-RTT data", which requires the

application to know if the request was received over 0-RTT data.







That's a really good point; you've changed my mind. It's obviously a good

idea to return a 5XX to a POST over 0-RTT and that would need this.



I think the proper code to send is 400. The request is client error,

nor server error, so it is 4XX. And there does not seem to be suitable

4XX code, so it goes to catch-all client error code 400.



For HTTP/2, refusing the stream (sending stream error 7 without sending

server headers)  is also a good choice, as this should trigger a

retransmission of the offending request (POST requests failed by

refusing the stream are retryable).



At least the http 0-RTT profile that I started writing was going to allocate a 
new 4XX error code for this purpose.  I am under no pretense that my version of 
such a document will resemble anything that finally gets published, though.

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

Re: [TLS] Separate APIs for 0-RTT

[Andrei Popov]

  *   My fear is that, even with RFC 2119 terminology, 0RTT will likely be the 
cause of many problems in the future
  *   and that being extra careful here is important… :)

I agree with this assessment. A MUST would certainly work for me. There are two 
reasons I suggested SHOULD:

  1.  A MUST would be non-enforceable (a TLS client or server can’t enforce the 
use of a particular API by the peer).
  2.  There’s lack of consensus on the topic of 0RTT and I’m trying to suggest 
a compromise.

Cheers,

Andrei

From: Benjamin Beurdouche [mailto:benjamin.beurdou...@inria.fr]
Sent: Tuesday, June 13, 2017 9:50 AM
To: Eric Rescorla <e...@rtfm.com>
Cc: Rich Salz <rs...@akamai.com>; ML IETF TLS <tls@ietf.org>; Andrei Popov 
<andrei.po...@microsoft.com>
Subject: Re: [TLS] Separate APIs for 0-RTT

Please forgive me for this naive question, but is there a specific incentive 
for using “SHOULD” instead of
“MUST" only enable 0-RTT application data upon explicit opt-in by the 
application...
My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause 
of many problems in the future
and that being extra careful here is important… :)

Best,
Benjamin

On Jun 13, 2017, at 6:12 PM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS 
implementation SHOULD only enable 0-RTT application data upon explicit opt-in 
by the application?

This is more flexible and may involve separate APIs, new off-by-default flags 
in the existing APIS, whatever else makes sense for a particular TLS 
implementation…

Cheers,

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

Re: [TLS] Separate APIs for 0-RTT

[Andrei Popov]

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS 
implementation SHOULD only enable 0-RTT application data upon explicit opt-in 
by the application?

This is more flexible and may involve separate APIs, new off-by-default flags 
in the existing APIS, whatever else makes sense for a particular TLS 
implementation…

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich 
Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich 
> wrote:
Microsoft also has a separate API for 0RTT data.  I would characterize things 
as the two most popular browsers have stated their intention to have a single 
API, and the two most popular system libraries have two.  Outlier is clearly 
wrong.

I did not know that about Microsoft. Thanks for the update. I take back 
"outlier"


I agree we don’t have consensus, but do make sure that any wording change 
accommodates the fact that the split isn’t all-versus-one.

I was intending to use wording that was neutral between the two options without 
any claims about popularity.

Thanks,
-Ekr

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

Re: [TLS] Comments on EndOfEarlyData

[Andrei Popov]

Yes, it is my plan to make 0-RTT data opt-in only in the Windows TLS stack, 
with a clear distinction in the API.
It is possible, however, that certain middleware components above the TLS stack 
might choose to blur this distinction (which would be bad design, in my 
opinion).

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Tuesday, May 23, 2017 11:48 AM
To: Markulf Kohlweiss ; Kaduk, Ben ; 
tls@ietf.org
Cc: Antoine Delignat-Lavaud ; Samin Ishtiaq 
; Britta Hale 
Subject: Re: [TLS] Comments on EndOfEarlyData

> Given that 0-RTT and 1-RTT guarantees are very different, it seem important 
> to distinguish the two streams and model them separately.

Cool; is SChannel going to do that?

OpenSSL does.
___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7Cdd3c1a8132a34d29c46908d4a20c5706%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636311621300870812=MXINz0jr8SWWW9GWOt3Ayrojidu3RdiK%2FkBffEZZ0Eo%3D=0

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

Re: [TLS] The case for a single stream of data

[Andrei Popov]

> To me, the argument against this comes down to this:  The 0RTT data has 
> different security properties than the post-handshake data, and TLS 
> implementations should not hide that difference from applications.
This is true, and early on there seemed to be general agreement that 0-RTT data 
would require explicit opt-in from the caller, e.g. via new API surface.

> Once the initial SSL_write_early_data() call has completed successfully the 
> client may interleave calls to SSL_read_ex(3) and SSL_read(3) with calls to 
> SSL_write_early_data() as required.
I'm curious why the client does not have to call SSL_read_early_data instead of 
the normal SSL_read in this case.

Cheers,

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

Indeed, as long as the scope of the ticket <= scope of the nonce database, it 
appears that rerouting wont’ help the attacker.
From: Colm MacCárthaigh [mailto:c...@allcosts.net]
Sent: Thursday, May 4, 2017 11:33 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Ilari Liusvaara <ilariliusva...@welho.com>; tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

  *   Providers already work hard to maximize user affinity to a data center 
for other operational reasons; re-routing is relatively rare and quickly 
repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?

Yes, but I don't see the significance.  If the attacker reroutes the user, or 
replays a ticket, to a different data center - the ticket won't work, it'll 
degrade gracefully to a regular connection.  Of course the attacker succeeded 
in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace? That 
would be an implementation error; tickets should be scoped to the location they 
are issued from, and checked against its strike register (or not used at all).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

  *   Providers already work hard to maximize user affinity to a data center 
for other operational reasons; re-routing is relatively rare and quickly 
repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

  *   I don't think we'll have a problem implementing a single use cache, 
strike register, we have similar systems for other services, at higher volumes.
… and these things work across geographically distributed datacenters, without 
negating the latency benefits of 0-RTT?

Cheers,

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

IMHO what we have is a facility in TLS 1.3 that:
1. Requires extraordinary effort on the server side to mitigate replay (for all 
but the smallest deployments);
2. Offers no way for the client to determine whether the server is mitigating 
replay (before replay becomes possible);
3. Is trivial to enable on the client and improves connection latency;
4. Eliminates a nonce that other protocols (used to) rely on.

While it is true that there are cases where this facility is beneficial, there 
is no doubt that it will be widely misused, in both applications and protocols.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Thursday, May 4, 2017 2:35 AM
To: Colm MacCárthaigh 
Cc: tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of 
> a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from 
> the review and posted them as an issue on the draft GitHub repo:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1001=02%7C01%7CAndrei.Popov
> %40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636294872882067868=HTQL9a3CxUEC0GkAQ%
> 2BviRMMO5ts2PnifQjOaZ%2BLZXR8%3D=0

What I didn't see in the summary, but I think might be relevant in relation to 
0-RTT:

There is a thing called 0-RTT exporter, which are exporter values available 
during 0-RTT transmission.

If the server uses 0-RTT exporter and doesn't enforce non-replay, the value 
grossly fails to be "nonce", which means it is likely unsafe to use for 
authentication.

Unfortunately, there are protocols that are already discussing the use of TLS 
1.3 0-RTT exporter, and switching to "full" exporter.
Unfortunately, the easiest way is not to switch, which means the possibly weak 
0-RTT exporter will be used for authenticating even non-replayable data.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636294872882067868=sgnwm3v7jfjLeWHZV77zwpchfzgy85ASKeKYYxEQxss%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

[Andrei Popov]

Ø  Note that any client which in fact supports

Ø  SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,

Ø  is noncomformant. It's not clear to me how many such clients in fact exist.

We saw enough TLS 1.2 clients that are non-compliant in this way that I made 
the server-side change to accommodate them.
Obviously, Martin Rex’s code is one example.
I’ve also seen a number of embedded/IoT-oriented TLS stacks that had this 
defect initially, when they first implemented TLS 1.2, although they were quick 
to fix.
Some of our customers in East Asia reported that the TLS stacks they used had 
this defect; when pointed at the RFC, they took the issue to the corresponding 
SW vendor(s).
Overall, a small percentage, but it generated enough support calls that the 
server change was worthwhile.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, March 23, 2017 9:58 AM
To: Fries, Steffen 
Cc: TLS WG 
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations 
in TLS 1.2



On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen 
> wrote:
Hi Erik,

based on your reply my conclusion is that

-  there is no (standard compliant) way for a server to use a SHA256 
based certificate for server side authentication in cases where the client does 
not provide the signature_algorithm extension
Not quite. If the client offers TLS 1.1 or below, then you simply don't know if 
it
will accept SHA-256 and you should send whatever you have. If the client offers
TLS 1.2 and no signature_algorithm extension, then you technically are forbidden
from sending it a SHA-256 certificate. Note that any client which in fact 
supports
SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
is noncomformant. It's not clear to me how many such clients in fact exist.


-  clients should always use the signature algorithm extension to 
ensure the server can apply a certificate with the appropriate crypt algorithms
Yes.

-Ekr



Best regards
Steffen

On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni 
> wrote:

> On Mar 23, 2017, at 10:31 AM, Fries, Steffen 
> > wrote:
>
> According to  TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.

The signature algorithm is primarily about signatures made as part
of the TLS handshake, and not so much signatures in certificates.

This does not seem consistent with 
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2

"If the client provided a "signature_algorithms" extension, then all 
certificates provided by
the server MUST be signed by a hash/signature algorithm pair that appears in 
that extension."

I appreciate that there are people who feel that this rule is bad, and
to some extent it has been relaxed in 1.3, but I think the text is
pretty clear here.


> If the client does not use this extension, the server must use the
> signature algorithm in combination with SHA1.

For signing the TLS key exchange, however, it should still present
whatever certificate chain it has, even if that chain employs SHA256.
It is exceedingly unlikely these days that a client will not support
SHA256 signatures in the certificate chain.

Yes, that's generally true. Though a TLS 1.2 client which does not offer SHA-256
in its ClientHello but accepts SHA-256 is broken. So, this should generally
only happen with TLS 1.1 and below.



> Unfortunately the server is not allowed to use this extension, otherwise
> he could tell the client his preferences according to his security policy.

The protocol (as it should) lacks the additional round-trips necessary for
the server to initiate signature algorithm negotiation.

I'm not sure quite what the OP Is trying to achieve here. For certificates 
offered
by the server, the client just tells you what algorithms it will accept for no 
negotiation
is needed. For certificates offered by the client, the server tells the client
what algorithms it will accept in the CertificateRequest.
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4

-Ekr

___
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] Enforcing stronger server side signature/hash combinations in TLS 1.2

[Andrei Popov]

Hi Steffen,

You’re stepping on a sore point for this WG☺. Based on the strict 
interpretation of the TLS 1.2 RFC, your conclusions are correct.
If a TLS1.2 client does not send the signature algorithms extension (or the 
extension does not include SHA256), a compliant TLS 1.2 server with a SHA256 
certificate has no choice but terminate the handshake.

Unfortunately, in practice there are TLS 1.2 clients that support SHA256, but 
don’t advertise it via the signature algorithms extension. Some of their 
implementers will argue that extensions are, by definition, optional 
functionality. Or that a TLS client may not have insight into its PKI library’s 
capabilities. Or that a TLS server is has no say in what certificate to use.

Be that as it may, from the server’s perspective, this strict compliance with 
the RFC reduces interoperability without a clear security gain. A server that 
favors interoperability over RFC compliance would send its SHA256 cert anyway, 
and let the client terminate the handshake. This is a change I made (rather 
reluctantly) in the latest versions of Windows.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Fries, Steffen
Sent: Thursday, March 23, 2017 8:37 AM
To: TLS WG 
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations 
in TLS 1.2

Hi Erik,

based on your reply my conclusion is that

-  there is no (standard compliant) way for a server to use a SHA256 
based certificate for server side authentication in cases where the client does 
not provide the signature_algorithm extension

-  clients should always use the signature algorithm extension to 
ensure the server can apply a certificate with the appropriate crypt algorithms

Best regards
Steffen

On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni 
> wrote:

> On Mar 23, 2017, at 10:31 AM, Fries, Steffen 
> > wrote:
>
> According to  TLS 1.2 section 7.4.1.4.1. a client may use the
> signature_algorithm extension to signal any combinations the
> client supports, listed in the order of preferences.

The signature algorithm is primarily about signatures made as part
of the TLS handshake, and not so much signatures in certificates.

This does not seem consistent with 
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2

"If the client provided a "signature_algorithms" extension, then all 
certificates provided by
the server MUST be signed by a hash/signature algorithm pair that appears in 
that extension."

I appreciate that there are people who feel that this rule is bad, and
to some extent it has been relaxed in 1.3, but I think the text is
pretty clear here.


> If the client does not use this extension, the server must use the
> signature algorithm in combination with SHA1.

For signing the TLS key exchange, however, it should still present
whatever certificate chain it has, even if that chain employs SHA256.
It is exceedingly unlikely these days that a client will not support
SHA256 signatures in the certificate chain.

Yes, that's generally true. Though a TLS 1.2 client which does not offer SHA-256
in its ClientHello but accepts SHA-256 is broken. So, this should generally
only happen with TLS 1.1 and below.



> Unfortunately the server is not allowed to use this extension, otherwise
> he could tell the client his preferences according to his security policy.

The protocol (as it should) lacks the additional round-trips necessary for
the server to initiate signature algorithm negotiation.

I'm not sure quite what the OP Is trying to achieve here. For certificates 
offered
by the server, the client just tells you what algorithms it will accept for no 
negotiation
is needed. For certificates offered by the client, the server tells the client
what algorithms it will accept in the CertificateRequest.
https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4

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

Re: [TLS] Updating for non-X.509 certificate types

[Andrei Popov]

It will be inelegant to have two code points for what is conceptually the same 
thing, but I think this is the best option, under the circumstances.

Cheers,

Andrei

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Friday, March 10, 2017 10:53 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Ilari Liusvaara <ilariliusva...@welho.com>; tls@ietf.org
Subject: Re: [TLS] Updating for non-X.509 certificate types



On Fri, Mar 10, 2017 at 10:04 AM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

>  Does anyone use this?

>  I don't think anyone uses it.

Au contraire: Windows TLS stack supports user_mapping and this mechanism 
appears to be somewhat in use. However, I agree that this falls into the 
category of extensions that need to be either deprecated or redefined for TLS 
1.3.

Are you OK with deprecated followed by redefined with a new code point?

-Ekr


Cheers,

Andrei

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

Re: [TLS] Updating for non-X.509 certificate types

[Andrei Popov]

Well, admittedly neither user_mapping, nor cert_type is hugely popular. 
It would not make sense for the TLS 1.3 spec to be on hold until these 
extensions are reconciled with it.

However, I do think that a TLS 1.3 ClientHello should be able to advertise 
extensions that are not defined for TLS 1.3, when the client is willing to 
accept TLS<=1.2.

Cheers,

Andrei

-Original Message-
From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Friday, March 10, 2017 10:43 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] Updating for non-X.509 certificate types

On Fri, Mar 10, 2017 at 06:04:54PM +0000, Andrei Popov wrote:
> Ø  Does anyone use this?
> 
> Ø  I don't think anyone uses it.
> 
> Au contraire: Windows TLS stack supports user_mapping and this 
> mechanism appears to be somewhat in use. However, I agree that this 
> falls into the category of extensions that need to be either 
> deprecated or redefined for TLS 1.3.

Oh, sorry, quoting context fail: I meant that nobody uses cert_type, not that 
nobody uses user_mapping.


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

Re: [TLS] Updating for non-X.509 certificate types

[Andrei Popov]

Ø  Does anyone use this?

Ø  I don't think anyone uses it.

Au contraire: Windows TLS stack supports user_mapping and this mechanism 
appears to be somewhat in use. However, I agree that this falls into the 
category of extensions that need to be either deprecated or redefined for TLS 
1.3.

Cheers,

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

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Andrei Popov]

I agree with David: a different client auth mechanism is in the works for 
HTTP/2.

Cheers,

Andrei

From: David Benjamin [mailto:david...@chromium.org]
Sent: Wednesday, February 15, 2017 11:52 AM
To: David Wong <davidwong.cry...@gmail.com>; Andrei Popov 
<andrei.po...@microsoft.com>
Cc: Cas Cremers <cas.crem...@cs.ox.ac.uk>; tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view 
on client authentication in post-handshake mode in Revision 18

On Wed, Feb 15, 2017 at 2:49 PM David Wong 
<davidwong.cry...@gmail.com<mailto:davidwong.cry...@gmail.com>> wrote:
On Feb 15 2017, at 7:27 pm, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

Yes, I agree that it is useful to mention this in the spec.



It would be nice is to have two different PRs solving this issue. One 
mentioning this as a potential issue that the application must be aware of. 
I've seen things like that for example in rfc 5746: 
https://tools.ietf.org/html/rfc5746#section-5

>  While this extension mitigates the man-in-the-middle attack described in the 
> overview, it does not resolve all possible problems an application may face 
> if it is unaware of renegotiation. For example, during renegotiation, either 
> the client or the server can present a different certificate than was used 
> earlier. This may come as a surprise to application developers (who might 
> have expected, for example, that a "getPeerCertificates()" API call returns 
> the same value if called twice), and might be handled in an insecure way.

A second PR could try to tackle this by adding a new message, for example an 
"AcknowledgeClientAuthentication" message that the server would send to confirm 
(or not) the validation of the client certificate. I think this would add a bit 
of complexity for less "surprise". I'm not too keen on this, and I think this 
could be added as an extension instead, but I think it would be nice to have to 
see if it integrates nicely in the current draft.

Post-handshake auth exists basically entirely to service HTTP/1.1 reactive 
client certificate which was previously hacked on via renegotiation. I think we 
should not make this feature any more complicated than absolutely necessary to 
support this mode, and we should not add more bells and whistles to it to 
encourage further use.

For the HTTP/1.1 use case, this is not necessary because it's reasonable for 
client/server to agree that the server will not send any more data for that 
request until it has processed the client's authentication messages.

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

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Andrei Popov]

Yes, I agree that it is useful to mention this in the spec.

From: David Wong [mailto:davidwong.cry...@gmail.com]
Sent: Wednesday, February 15, 2017 2:07 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: David Benjamin <david...@chromium.org>; Cas Cremers 
<cas.crem...@cs.ox.ac.uk>; tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view 
on client authentication in post-handshake mode in Revision 18

I think I can agree that this is an application problem, not a TLS problem. But 
this should be mentioned in the spec nonetheless as Cas pointed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Questions on certificate_extensions...

[Andrei Popov]

> So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF 
> OBJECT IDENTIFIER for Extended Key Usage.
This is correct. The idea is to use the same format your PKI library already 
knows how to deal with.

> As regards the matching rules. How do these apply when a particular extension 
> is absent from the certificate?
"If the server has included a
  non-empty certificate_extensions list, the client certificate MUST
  contain all of the specified extension OIDs that the client
  recognizes."

> For example an absent Key Usage is often taken to mean no Key Usage 
> restrictions apply. If Key Usage is present in certificate_extensions does it 
> *require* that the Key Usage extension is explicitly present in the 
> certificate?
Based on the above, yes. However, a client that does not recognize e.g. Key 
Usage extension, must ignore and skip to the next CertificateExtension.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dr Stephen Henson
Sent: Tuesday, February 14, 2017 12:28 PM
To: tls@ietf.org list 
Subject: [TLS] Questions on certificate_extensions...

A couple of questions on the format and handling of certificate_extensions.

What format is the data that appears in certificate_extension_values? I'd say 
that it should be in the same format as the content octets of the extnValue 
field of Extension (from RFC5280 et al). So (for example) it would be a BIT 
STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended Key Usage.

As regards the matching rules. How do these apply when a particular extension 
is absent from the certificate? For example an absent Key Usage is often taken 
to mean no Key Usage restrictions apply. If Key Usage is present in 
certificate_extensions does it *require* that the Key Usage extension is 
explicitly present in the certificate?

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
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] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Andrei Popov]

Is it important for the client to know, from the TLS stack itself, whether 
client authentication succeeded or not? My assumption (perhaps incorrect) has 
been that it is the server that cares about the client's identity (or 
identities) in order to make an authorization decision.

This thread also seems to consider client authentication a binary state: the 
client is either authenticated, or not. In practice, the client may assert 
multiple identities, and the server may grant various levels of access.

Also, why should the client care whether session ticket X includes client 
identity Y? If a client resumes a TLS session with a session ticket that does 
not include (or point to) a client authenticator needed to satisfy the client's 
request, the server can initiate client auth (or deny the request).

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Wong
Sent: Tuesday, February 14, 2017 8:18 AM
To: David Benjamin 
Cc: Cas Cremers ; tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view 
on client authentication in post-handshake mode in Revision 18




On Feb 14 2017, at 4:44 pm, David Benjamin 
> wrote:
NewSessionTicket always includes in-handshake client auth. The resumption 
secret can't even be derived without it.


Oups, my bad. What about if the client do send a certificate, but the server 
decides not to accept it, but goes on with the connection (I think nothing in 
the spec says that the server needs to terminate the connection if the client 
cert is not good).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

[Andrei Popov]

What about Eric’s other point:

Ø  I am not sure that the regular TLS handshake guarantees these

Ø  properties either. The reason is that the server is permitted to

Ø  send data prior to receiving the client's second flight (0.5 RTT

Ø  data).

With the server sending data prior to receiving the client’s second flight, it 
seems that property B is not there when using in-handshake client 
authentication as well?

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 12:53 PM
To: Eric Rescorla 
Cc: tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view 
on client authentication in post-handshake mode in Revision 18


Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously 
considering TLS as able to enforce the ordering of messages which does seem to 
mitigate our scenario for property A. We haven't really had a chance to take 
that into consideration for property B, but at a glance it does still seem to 
be an issue.

As mentioned in my other email, one scenario we encountered this was if (using 
your message numbering as reference) messages 5 or 9 happened to be a 
NewSessionTicket. In this case, the client might be under the impression that 
they have a session ticket for a mutually authenticated channel.

Thanks,

Sam
On 10/02/17 20:39, Eric Rescorla wrote:
Cas, Sam,

I thought I understood your concern here but maybe I don't.

Say we have the following sequence of messages

  1. C->S: ClientHello
  2. S->C: ServerHello...ServerFinished
  3. C->S: ClientFinished
  4. C->S: App message
  5. S->C: App message
  6. S->C: CertificateRequest
  7: C->S: Certificate...Finished
  8: C->S: App message
  9: S->C: App message

As you indicate, there's some ambiguity from the client's perspective
(property B) about whether messages 5 and 9 were sent by the server
prior to or after receiving message 7, and also message 8. This
ambiguity exists even without an attacker and may or may not be
resolved at the application layer. An attacker can exploit this
ambiguity by holding messages 7 and 8 and (as long as application
semantics permit this).

Where I get confused is about property A. As I understand your
claim, an attacker can hold message 7 but deliver message 8 and
therefore, even if the client knows that 9 was in response to 8,
he doesn't know that the server received 7. As Ilari says, I don't
believe that this is correct because TLS enforces message ordering.
I agree that the specification doesn't explicitly say this, but
it's implicit in the processing rules via the following:

1. The encryption for each TLS record depends on the record sequence
   number (RSN).
2. Records do not carry their RSN, so when you decrypt a message, you
   must use the last RSN + 1
3. When you fail to decrypt a message (which is what happens if you have
   the wrong RSN) you are required to tear down the connection
   (https://tlswg.github.io/tls13-spec/#record-payload-protection).

For this reason, if the attacker removes message 7, then 8 will not
be decryptable, and so ordering is preserved. As Ilari says, this isn't
true in DTLS 1.3 which we'll presumably have to deal with one way
or the other before standardization (my plan would be just to forbid
post-handshake auth). Do you disagree with this? If so, perhaps you
could explain.

-Ekr

P.S. I am not sure that the regular TLS handshake guarantees these
properties either. The reason is that the server is permitted to
send data prior to receiving the client's second flight (0.5 RTT
data). See:
https://tlswg.github.io/tls13-spec/#protocol-overview





On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott 
> wrote:
Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the 
server cannot finish the handshake or begin processing incoming application 
data until authenticating the client. This *almost* gives us property (A). In 
practice, the client is aware that the server has successfully authenticated 
since the protocol continues.

In the case that the server has implemented the reject option (rejecting a 
certificate but still continuing), and indeed rejects the certificate, then the 
server should send an alert message (or NAK of some form) for the property to 
hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into 
account for the initial handshake, then it is clear that this decision can only 
be made by the server in the initial handshake, while in the post-handshake 
client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a 
new pair of keys explicitly provides this. Specifically, the client will send 
all subsequent data to the server under a new key. The server will not be able 
to decrypt this data until 

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Andrei Popov]

Indeed, "all known versions of SSL are broken and should never be used" is what 
I've been telling people for a while now...

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, December 2, 2016 6:36 AM
To: Peter Gutmann ; Stephen Farrell 
; David Benjamin ; Tony 
Arcieri ;  
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote:
> If no-one from Microsoft has any objections, can we just rename it 
> back to what it's always been for everyone but us, SSL?

fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of things, 
not only TLS.  Yesterday i got an e-mail from a reputable CA reseller that said 
"Your SSL is expiring in two days!  Buy a new SSL now!"

Surely no one is proposing that we also re-name the X.509 certificate format to 
"SSL" just because vendors whose business models revolve around these products 
are confused about terminology.  What else should we rename to "SSL" on that 
basis?  Maybe a load-balancer is also "SSL"!

Here's a useful and effective meme for convincing bosses that it's ok to turn 
off SSLv3: all known versions of SSL are broken and should never be used.  
Please do not break this meme by trying to rename TLS to SSL.

I don't care about the bikeshed over the number: i'd be fine with any of TLS 
1.3 or TLS 4 or TLS 2017.  But can we please not create *even more* confusion 
by bikeshedding over the name itself?

   --dkg

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Andrei Popov]

Not that I can speak for the whole of Microsoft, but I would not drop TLS 
support in Windows if it were renamed "SSL":).

However, "transport layer security" makes a lot more sense to me than "secure 
sockets layer" because the latter seems to imply network socket-style API, 
which is not a requirement of this protocol.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Gutmann
Sent: Friday, December 2, 2016 12:33 AM
To: Stephen Farrell ; David Benjamin 
; Tony Arcieri ;  

Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

Stephen Farrell  writes:

>IIRC that was sort-of a condition for adoption of the work in the IETF 
>20 years ago, when there were two different protocols already being 
>deployed and the proponents of one of them said "we'll use that other 
>one (SSL) but you gotta change the name of the standard or we can't get 
>our  to agree to change to all use the same thing."

It was Netscape with SSL vs. Microsoft with PCT.

If no-one from Microsoft has any objections, can we just rename it back to what 
it's always been for everyone but us, SSL?

Peter.

___
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] Confirming consensus: TLS1.3->TLS*

[Andrei Popov]

Peter has some excellent points here (although I would prefer "TLS 2.0").

Perhaps the "re-branders" are losing votes and hums because we're fragmented 
into numerous camps.

With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where the 
protocol name remains "TLS" and major version becomes > 1.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Gutmann
Sent: Friday, November 18, 2016 6:41 PM
To: Ilari Liusvaara 
Cc:  
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

Replying to several messages at once to save space:

Ilari Liusvaara:

>One can downnegotiate TLS 1.3 to TLS 1.2.

Ah, you're obviously a fan of Steve Wozniak humour.  When someone asked him 
whether it was possible to upgrade from an Apple II+ to an Apple IIe, he 
similarly said "yes, you unplug the power cable from the II+, throw it away, 
and plug the IIe into the newly-vacated power cable".

Christian Huitema:

>I prefer TLS 1.3, because is signals continuity with the ongoing TLS 
>deployment efforts.

Maybe it's just me, but wouldn't the fact that they're both called TLS sort of 
indicate that there's continuity there?

Dave Kern:

>I'm in favor of TLS 4, and ignoring the minor version number (in the 
>friendly text string, not the protocol field) moving forward.

That's actually a good point, "TLS 4" provides a single, clean number for 
people to remember.  Even a CTO or auditor should be able to get that one right 
without having to look up a table in a book to see that 1.3 > v3.

Peter.
___
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] draft-sullivan-tls-exported-authenticator-00

[Andrei Popov]

Yes, this line has confused me as well.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of William Whyte
Sent: Tuesday, November 1, 2016 1:42 AM
To: Nick Sullivan 
Cc: tls@ietf.org
Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00

I'm confused by the line "These messages are not encrypted", because on a plain 
reading it could mean that the authenticator is sent outside the encrypted TLS 
session. That would be bad because it would mean that clients that wanted to 
authenticate themselves but to the server only wouldn't be able to use this 
mechanism. I assume that's not the intent? If that isn't the intent, suggest 
rephrasing as "These messages are not encrypted, other than the encryption 
provided on transmission by the TLS session".

Cheers,

William

On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan 
> wrote:
draft-sullivan-tls-exported-authenticator-00>
I just posted a new Internet-Draft called "Exported Authenticators in TLS" in 
the TLS working group.

The intent of this draft is to enable participants in a TLS connection to prove 
ownership of additional certificates. This differs from previous proposals 
(https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00) in that 
these proofs are not sent as part of the TLS connection, but instead exported 
so that they can be sent out of band (as part of an application layer message, 
for example).

This proposal should enable a radical simplification of the Secondary 
Certificate Authentication in HTTP/2 proposal 
(https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), 
and should generally be a useful tool for binding a certificate ownership proof 
to a TLS connection.
Nick Sullivan

___
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 of draft-sandj-tls-iana-registry-updates-01

[Andrei Popov]

+1

Definitely good enough starting point.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Xiaoyin Liu
Sent: Saturday, October 22, 2016 10:02 AM
To: Eric Rescorla ; Stephen Farrell 
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

Xiaoyin

From: Eric Rescorla
Sent: Saturday, October 22, 2016 11:26 AM
To: Stephen Farrell
Cc: tls@ietf.org
Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01

+1

This draft just codifies stuff that we had already agreed on but had been 
awkwardly stuffed in TLS 1.3. Having it separate is an improvement.

-Ekr




On Sat, Oct 22, 2016 at 7:30 AM, Stephen Farrell 
> wrote:

Hi all,

Sean and Joe wrote up this IANA registry draft as per
discussions at WG meetings and on the list. As they've
done the initial work, but are WG chairs, they wanted
me (as responsible AD) to call consensus for it. (They
wrote this up as finding authors for such fairly boring
stuff was hard - thank them for taking one for us all
when you see 'em:-)

Based on the earlier discussions and limited mails on
this draft, I do think there's consensus to adopt this
approach and that the text in the I-D [1] is a good
enough starting point for the WG.

If you think otherwise, please comment to the list in
the next week.

If you've questions about all this from a process-crap
POV, feel free to ask those on or off the list as you
think appropriate;-)

Note that if this is adopted as a WG item, the chairs
might decide to continue as editors or recruit someone
else. In the former case, I'm fine with doing the WGLC
stuff when this is ready (which it nearly is IMO, so
there may or may not be a need for new authors, depends
on what the WG think of the text I'd guess).

Cheers,
S.



[1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01


___
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] SNI and Resumption/0-RTT

[Andrei Popov]

> The server ought to perform a full handshake whenever the full handshake will 
> result in selection & use of a _different_ TLS server certificate than what 
> was used for the original full handshake on a session resumption.
I think this is correct, assuming a server is only able to present one cert in 
a TLS session (which is currently the case).

However, this does not mean that the SNI at resumption time has to match the 
SNI at session establishment time, because the same server cert can match 
multiple SNIs.

Also, there appears to be interest in allowing the client to request server 
auth post-handshake. If this gets supported, a server may prove multiple 
identities to a client within the same TLS session. And then perhaps the client 
should be able to resume the session with an SNI that matches any of the 
identities the server has proved in this session.

Cheers,

Andrei

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Friday, October 21, 2016 6:52 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Eric Rescorla <e...@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this 
> session the server has proved an identity that matches the new SNI.
> In order to enforce this, the server would have to cache (or save in 
> the ticket) a list of identities it presented in each resumable session?

The current wording in rfc6066 may be slightly confusing about what is acutally 
important and why.

The server ought to perform a full handshake whenever the full handshake will 
result in selection & use of a _different_ TLS server certificate than what was 
used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the server 
from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the server certificate 
that a client gets to see, because that would essentially result in 
not-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching, and clients 
proposing the wrong session for resumption, and the server doing a full 
handshake results in interoperable, deterministic and secure behaviour.


-Martin

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

Re: [TLS] SNI and Resumption/0-RTT

[Andrei Popov]

Perhaps it’s OK to resume a session with a different SNI if in this session the 
server has proved an identity that matches the new SNI.
In order to enforce this, the server would have to cache (or save in the 
ticket) a list of identities it presented in each resumable session…

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Thursday, October 20, 2016 5:47 PM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT



On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

>  With that said, it does seem like there might be situations where it

>  would be useful to allow resumption/0-RTT with different SNIs.
What are some example situations where resumption with a different SNI is useful

A system where you have a bunch of co-tenanted names and you'd like to get 
0-RTT on
SNI A after negotiating with SNI B. Basically the same conceptual situation as 
Mike Bishops
add-a-server-cert draft.

With that said, I'm more than happy to stuff this in the "TODO-for-later" list.

-Ekr


Thanks,

Andrei

From: TLS [mailto:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On Behalf 
Of Eric Rescorla
Sent: Thursday, October 20, 2016 5:34 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] SNI and Resumption/0-RTT

We used to explicitly say that you had to check SNI for 0-RTT (but
didn't say anything about resumption). On the principle that 0-RTT and
resumption should be the same I removed that, but it turns out that
the document doesn't actually have any rule at all other than the one
we've inherited from RFC 6066, which clearly says that you can't
resume with a different SNI [0].

Following the discussion in
https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
to the draft clarifying that the RFC 6066 rule still applies [1]

With that said, it does seem like there might be situations where it
would be useful to allow resumption/0-RTT with different SNIs. My
intuition (partly informed by [2]) is that this is something we should
be pretty careful about and have the server opt-in explicitly (if at
all) but I'm willing to be wrong about that.

Comments?
-Ekr


[0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
[1] 
https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf


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