[TLS] Application data during renegotiation handshake

[Mike Bishop]

A question for TLS implementation owners:  During the discussion of the TLS 1.2 
portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it 
was pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface 
that some implementations may have assumed.

Since HTTP/1.1 only has one request per connection and that request is waiting 
on the client certificate to be retrieved via renegotiation, you can assume 
that the client will not send any application data between the new ClientHello 
and sending the Finished message.  ("...it is expected that the negotiation 
will begin before no more than a few records are received from the client.")  
Likewise, the server will not emit any application data between sending the 
HelloRequest and sending its own Finished message.  Since HTTP/2 will have 
other requests being generated and served in parallel, this is no longer the 
case.  Per the TLS 1.2 spec, that's permitted, but if it's not been done 
before, I'm afraid we may be hitting less-tested code paths.

I know that BoringSSL 
explicitly requires that application data flow be stopped during renegotiation. 
 If the HTTP working group adopts this draft, do the owners of other TLS 
implementations expect this to require changes in their TLS 1.2 implementations?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application data during renegotiation handshake

[Mike Bishop]

Doing it at the HTTP layer (as an authentication mechanism) is challenging, 
since applications aren’t expecting to receive it that way, and moves the 
authenticated exchange onto a different stream than triggered it.  I know that 
there’s the possibility for a layer to fake the client going away while 
actually sending a 401, but then you have to be able to tie the client’s second 
attempt back to the challenge, don’t you?

When I say “application,” I mean the code being hosted by the web server that’s 
actually responding to the interpreted requests.  While I’d like to minimize 
code changes in the HTTP server, my primary constraint is that I don’t change 
the application they’re hosting at all.  The change to HTTP/2 and/or TLS 1.3 
should be as transparent as possible.  Keeping auth that’s currently done via 
TLS still in TLS helps to reduce those changes at higher layers.

In the HttpBis working group meeting, there was fairly strong consensus that we 
needed a backward-compatibility mechanism for existing apps moving to HTTP/2 
over TLS 1.[23]; there was also interest in defining something cleaner in the 
future for new apps that could adopt something brand new, but not at the 
expense of quickly enabling current apps to keep working.  The draft below is 
the current candidate for least-ugly compat solution.  Doing it at the framing 
layer is definitely a good option for the something cleaner.

From: David Benjamin [mailto:david...@chromium.org]
Sent: Thursday, November 12, 2015 12:43 PM
To: Yoav Nir ; Adam Langley 
Cc: Mike Bishop ; tls@ietf.org
Subject: Re: [TLS] Application data during renegotiation handshake

On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir 
mailto:ynir.i...@gmail.com>> wrote:

> On 12 Nov 2015, at 3:32 AM, Adam Langley 
> mailto:a...@imperialviolet.org>> wrote:
>
> The TLS 1.3 post-handshake client-auth was intended, as I recall, to
> support HTTP/1.1 over TLS 1.3.

No, it was (and is) presented as a way to do client certificate authentication 
with HTTP/2 not at the initial handshake.

> With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e.
> by signing exporter values)?

It is. I thought that an HTTP authentication method based on certificates could 
be a drop-in replacement for TLS layer authentication, but someone (I think it 
was Mike) pointed out that with TLS-layer certificate authentication the stream 
continues after the authentication, while with HTTP-layer authentication, the 
stream ends with a 401 status code, and the client has to start a new stream 
with the Authorization header. So applications would need to be changed for 
this to work.

Using existing HTTP semantics would certainly be cleaner in a vacuum, but one 
could still do it in HTTP/2 layer without creating a new stream. Perhaps adapt 
SPDY's CREDENTIAL frame and add a new SWITCH_CREDENTIAL frame to swap a 
stream's credential slot mid-stream?

Alternatively, HTTP/2 frontend could make the application think there were two 
independent requests. Am I misunderstanding the objection? What about this:
1. Client hits HTTP/2 frontend. Frontend talks to application which decides it 
needs client auth, expecting it on the same stream.
2. Frontend immediately aborts that request and returns a 401 to the client. 
Application thinks the client just gave up.
3. Client makes a new stream, now authenticated. The frontend hits the 
application fresh. Application requests client auth as before and frontend 
responds immediately with the certificate the client asserted.
This is, by the way, how Chrome implements client auth today, even with renego. 
We never reconfigure client auth mid-stream.

I think it would be helpful to have examples of exactly what the applications 
look like, to know what constraints the various interested parties are working 
with.

For example, Apache httpd has some high-level configuration file.
https://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients
Existing Apache installs can easily compatibility regardless of how the 
HTTP/TLS interaction looks.

On the other extreme, if the goal is to keep Apache httpd unchanged while only 
changing OpenSSL, then we have a very different picture because the OpenSSL API 
is SSL_renegotiate/SSL_do_handshake (send a HelloRequest) + 
SSL_set_state/SSL_do_handshake (don't continue until renego completes). That 
one is quite overfit to the old flow and will be difficult to reconcile with 
almost anything.

draft-thomson-http2-client-certs-00's HTTP/2 mode seems to be targeting 
something in between. It's okay with adding a new application_context_id, but 
the client certificate still needs to be asserted at the transport. I'm having 
a hard time divining the constraints from this.

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

Re: [TLS] TLS ECH, how much can the hint stick out?

[Mike Bishop]

This is primarily an active attack, but not purely so.  Clearly the MITM is an 
active attacker, but there are situations in QUIC (and DTLS, I presume) where a 
ClientHello gets retransmitted.  Depending on server infrastructure, the client 
might get two different responses.  This isn’t limited to cases where the 
observer/attacker is the one performing the replay.

 

So I think we need to decide whether it’s a goal that, given that relatively 
narrow situation, the observer shouldn’t be able to identify ECH acceptance by 
comparing two ServerHellos that both respond to the same ClientHello.

 

From: TLS  On Behalf Of Christopher Patton
Sent: Tuesday, September 8, 2020 2:23 PM
To: Christian Huitema 
Cc: tls@ietf.org
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

 

Hi Christian, Hi list, 

 

The "don't stick out" property is a steganographic security goal: we want the 
"real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable from the 
"cover" protocol, i.e., the handshake pattern in which the client sends a 
"dummy" ECH extension that is ignored or rejected by the server. This is a 
property that TLS was never designed to have, but it seems that we need some 
degree of it in order to deploy ECH. The fundamental question that Christian 
raises is what is the right threat model for this property.

 

The "status quo" threat model considers a distinguisher that is strictly 
passive---it does not interfere with a handshake or probe the server---and that 
does not know the ECH configuration. This seems (to me, at least) sufficient to 
account for middleboxes that might ossify on the ECH extension. It also seems 
achievable, both by the ECH as it is and for the proposed change.

 

The distinguishing attacks described by Christian are much stronger, in the 
sense that they involve an active attacker. I don't believe there is any way of 
implementing ECH---either as it is or with the proposed change---that defeats 
active attacks in general. In particular---and as Christian points out---an 
active attacker can probe the server to learn the ECH configuration (via the 
ECH retry logic), which it can use to easily distinguish the real protocol from 
the cover protocol. This works regardless of whether the change is adopted.

 

In my view, achieving don't-stick-out-security against active attackers 
requires us to revisit the design of ECH altogether. The main difficulty is 
that client-facing servers publish the ECH configuration in a way that's easily 
accessible to an active attacker. Keeping the configuration secret may provide 
a way to achieve security, and some deployments might opt to do this; but the 
vast majority won't. We might consider adding support for this deployment 
scenario, but this can (and should, I think) wait for a later draft.

 

That said, it is worth considering mitigations against known attacks, in 
particualr (1). I think the suggestion for mitigating (2) adds too much 
complexity, and if it doesn't fully address the intended threat model (I don't 
think it does), then we'll likely need to replace it in the future. I think 
it's better to keep things simple until we fully address the intended threat 
model.

 

Best,

Chris P.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS ECH, how much can the hint stick out?

[Mike Bishop]

Certainly it’s better for the server if it can be consistent, especially if it 
expects multi-packet first flights.  If the same back-end sees both, it can 
discard the second, and that’s what I’d expect most of the time.  But here’s 
what I think is possible:

 

The client sends an Initial packet (randomly selected Destination CID), PTOs, 
then sends another Initial packet to the same Destination CID.  On the server 
side, the infrastructure assumes that Initial packets whose CIDs aren’t issued 
by them can be routed to a random back-end, and that back-end will set a new 
DCID that routes to it in the future.

 

The client will receive either of the Server Initial packets, switch to the new 
DCID, and will reject the other because attempts to change the server’s CID a 
second time.  The connection succeeds because whichever server’s ServerHello is 
used also has its DCID used, so all subsequent packets go to that back-end.

 

From: Eric Rescorla  
Sent: Thursday, September 10, 2020 3:58 PM
To: Mike Bishop 
Cc: Christopher Patton ; Christian 
Huitema ; tls@ietf.org
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

 

 

 

On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop mailto:mbis...@evequefou.be> > wrote:

This is primarily an active attack, but not purely so.  Clearly the MITM is an 
active attacker, but there are situations in QUIC (and DTLS, I presume) where a 
ClientHello gets retransmitted.  Depending on server infrastructure, the client 
might get two different responses.  

 

This doesn't sound correct. In this circumstance, the client and the server 
might have mismatched SH values and the handshake will fail. To the best of my 
knowledge, the server is required to behave consistently in this case, even if 
it consists of multiple machines.

 

-Ekr

 

 

So I think we need to decide whether it’s a goal that, given that relatively 
narrow situation, the observer shouldn’t be able to identify ECH acceptance by 
comparing two ServerHellos that both respond to the same ClientHello.

 

From: TLS mailto:tls-boun...@ietf.org> > On Behalf Of 
Christopher Patton
Sent: Tuesday, September 8, 2020 2:23 PM
To: Christian Huitema mailto:huit...@huitema.net> >
Cc: tls@ietf.org <mailto:tls@ietf.org> 
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?

 

Hi Christian, Hi list, 

 

The "don't stick out" property is a steganographic security goal: we want the 
"real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable from the 
"cover" protocol, i.e., the handshake pattern in which the client sends a 
"dummy" ECH extension that is ignored or rejected by the server. This is a 
property that TLS was never designed to have, but it seems that we need some 
degree of it in order to deploy ECH. The fundamental question that Christian 
raises is what is the right threat model for this property.

 

The "status quo" threat model considers a distinguisher that is strictly 
passive---it does not interfere with a handshake or probe the server---and that 
does not know the ECH configuration. This seems (to me, at least) sufficient to 
account for middleboxes that might ossify on the ECH extension. It also seems 
achievable, both by the ECH as it is and for the proposed change.

 

The distinguishing attacks described by Christian are much stronger, in the 
sense that they involve an active attacker. I don't believe there is any way of 
implementing ECH---either as it is or with the proposed change---that defeats 
active attacks in general. In particular---and as Christian points out---an 
active attacker can probe the server to learn the ECH configuration (via the 
ECH retry logic), which it can use to easily distinguish the real protocol from 
the cover protocol. This works regardless of whether the change is adopted.

 

In my view, achieving don't-stick-out-security against active attackers 
requires us to revisit the design of ECH altogether. The main difficulty is 
that client-facing servers publish the ECH configuration in a way that's easily 
accessible to an active attacker. Keeping the configuration secret may provide 
a way to achieve security, and some deployments might opt to do this; but the 
vast majority won't. We might consider adding support for this deployment 
scenario, but this can (and should, I think) wait for a later draft.

 

That said, it is worth considering mitigations against known attacks, in 
particualr (1). I think the suggestion for mitigating (2) adds too much 
complexity, and if it doesn't fully address the intended threat model (I don't 
think it does), then we'll likely need to replace it in the future. I think 
it's better to keep things simple until we fully address the intended threat 
model.

 

Best,

Chris P.

___
TLS mailing list
TLS@ietf.o

Re: [TLS] potential security concern regarding the exchange of client certificates during the TLS handshake process

[Mike Bishop]

This concern is also why many implementations of client certificates in TLS 1.2 
and earlier would perform a handshake without requesting a client certificate, 
then immediately begin renegotiation to exchange the client certificate under 
encryption. TLS 1.3 removes the need to do this.

-Original Message-
From: TLS  On Behalf Of Viktor Dukhovni
Sent: Monday, March 27, 2023 8:08 AM
To: tls@ietf.org
Subject: Re: [TLS] potential security concern regarding the exchange of client 
certificates during the TLS handshake process

On Sun, Mar 26, 2023 at 02:18:58AM +, Yannick LaRue wrote:

> [...] This means that information such as the client's name, email 
> address, and other identifying details are transmitted in cleartext, 
> potentially allowing for interception and exploitation by malicious 
> actors.

This is true for TLS versions 1.0–1.2, but not TLS 1.3.

> I propose that a solution to this issue would be to separate the 
> exchange of client certificates from the initial handshake process, 
> and instead require the client to present their certificate only after 
> the secure channel has been established. This would allow for mutual 
> authentication without exposing sensitive information to potential 
> interception.

In TLS 1.3, the client certificate is in the encrypted part of the handshake.  
TLS 1.3 also supports post-handshake-authentication.

> I urge you to consider this proposal and take action to address this 
> potential security vulnerability. Thank you for your attention to this 
> matter.

It seems you've rediscovered one of the concerns addressed in TLS 1.3.

-- 
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] New Internet Draft: The qpack_static_table_version TLS extension

[Mike Bishop]

My general thoughts, in no particular order:

  *   I’d be more excited about using a generic mechanism to agree on SETTINGS 
pre-handshake (e.g., ALPS) than using a protocol-specific TLS extension for 
just this feature.  Therefore, HTTP WG for this particular use-case, but if 
there were to be a generic mechanism, that would probably live in TLS WG with 
HTTP WG as a consumer.
  *   The value of a TLS extension is that it lets you agree on something 
before the application-layer protocol gets started.  That enables these things 
which you can’t do in SETTINGS:
 *   Wholesale replacement of the static table, to put different things in 
the low-bitcount real estate
 *   Use of “extended” entries in the first flight, to fit the most 
requests in the first packet(s); note that this matters more with TCP/TFO than 
QUIC 0-RTT.
 *   Reducing the size of the static table for micro clients; see below
  *   If we’re not doing one of those things, SETTINGS is the right model for 
this.  We decided in H3 that pre-application-data agreement wasn’t required for 
SETTINGS; do we want to revisit that?

  *   The value of the static table in the protocol drops as the table gets 
longer, as the entries get more expensive to reference. For a frequently-used 
field, the marginal impact may just be shortening the initial reference to put 
the header into the dynamic table.  How many bytes does this actually save in a 
real session?
  *   The difficulty of including the static table in a binary increases as the 
static table gets bigger, and this proposal could be very helpful in that 
problem – if a compact implementation could declare they only want to use the 
first 32 entries, for example.  The current version of QPACK imposes a minimum 
binary size on any H3 implementation, due to the requirement to keep the full 
static table accessible.
  *   Wholesale table replacement probably involves offer-select or a priority 
ordering, departing from the usual SETTINGS model.
  *   Agreement is somewhat implicit – if the decoder has advertised support 
for entry N, the encoder can only reference it if it knows the value of entry 
N. If it knows the value of N, it would ordinarily be willing to accept 
references to N as well.
 *   Exception: those micro-clients again. If a small binary contained a 
sparse selection of “useful values” from the static table, the encoder could 
use the entries of which it was aware, but a decoder could only advertise 
support for the first contiguous portion of the table.


From: TLS  on behalf of Lucas Pardue 

Sent: Tuesday, September 26, 2023 9:48 PM
To: Martin Thomson 
Cc: Mike Bishop ; HTTP Working Group ; 
TLS List ; Hewitt, Rory 
Subject: Re: [TLS] New Internet Draft: The qpack_static_table_version TLS 
extension

Hi Rory,

I echo Watson and Martin, lets discuss this in the HTTP WG.

As for a very brief technical response. In general I'm supportive of the idea 
of more agility of the static table but I think my motivations would be 
different than the ones behind this proposal. For me, I'd like more 
domain-specific tables to be defined, and to have the possibility of asymmetric 
tables; but lets stick that on the side for now.

The QPACK static table description states "The order of the entries is 
optimized to encode the most common header fields with the smallest number of 
bytes.". How does the proposed append-only table gel with this? I.e. each year, 
the new most common fields are added to the end? At what point would it make 
sense to wipe out the cruft and define a newer table altogether?

I think what might be needed is a good amount of datamodelling and simulation 
that is sufficient to decide when there is activation energy to make changes. 
Perhaps the proposal is a compromise to make it low effort enough for 
implementations to update, that they don't need tremendous amounts of 
overwhelming evidence to keep up. IIRC historically the effort to sample the 
Internet and propose a table has been quite high, and there have been some 
criticisms about the outputs. Given the HTTP WG has struggled with this aspect, 
I think it is decidedly impractical to make IANA or a designated expert solely 
responsible for deciding the QPACK entries. This is something that has to run 
through a consensus approach IMO, especially as lower entries are more valuable 
and couldn't ever be reclaimed.

I think the largest activation energy would be to convince endpoints to 
implement the negotiation mechanism because it is pushing it into the TLS layer 
and that crosses implementation boundaries. Watson asks why not SETTINGS. One 
answer is that it requires clients to have to wait for the server's settings, 
which adds a delay that many clients don't already apply. Trading off latency 
for a few bytes doesn't sound like a good tradeoff. Indeed, this is why we 
optimised the static table for the clien'ts fi

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

[Mike Bishop]

I don't know that the assumption that it starts as a re-ordering is going to be 
valid. Certainly we have at least one instance (the erratum you reported, 
Rory!) where we've found something in a static table that's simply invalid; I'd 
expect we drop that line in any versioned update, even if we have to keep it 
while extending. Similarly, fields that are lists of capabilities (e.g. 
Content-Encoding) are likely to have a new 1-2 top values that replace the old 
ones. I'd expect we generate the table de novo each time we do so, while hoping 
that many values remain the same over time.

I also do think there are interesting possibilities here for domain-specific 
tables which aren't a contiguous list of ongoing improvements. (Clients might 
also like not to remember the decades-old versions other than the fallback 
version zero.)  That might suggest something more like the TLS 
supported_versions 
(https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1) extension, in 
which the sender could indicate "I know the first 104 entries of version 0, the 
first 72 entries of version 1, and the first 32 entries of version 61932." This 
also allows us more flexibility for doing draft version support during 
development, similar to QUIC versions that embedded draft numbers.

Roy, to your comment a while back that the HTTP Archive isn't representative:  
It absolutely isn't, and yet it's the best resource we had at the time and what 
we used. If there's a more representative resource to be used in the future, 
please do suggest it when we start trying to build a new table.

Thanks,
Mike

From: Rory Hewitt 
Sent: Tuesday, October 17, 2023 2:21 PM
To: Martin J. Dürst 
Cc: HTTP Working Group ; TLS List ; Hewitt, 
Rory 
Subject: Re: [TLS] New Internet Draft: The qpack_static_table_version TLS 
extension

Hey Martin,

That's a fair point, and I appreciate you bringing it up.

What I wanted to clarify was that every 3 years, whoever is doing the sampling 
and appending of new entries should determine whether the new entries are 
sufficiently popular that re-ordering the table makes sense. They can certainly 
decide that it doesn't make sense to create an entire new registry just because 
entry 123 should actually be at position 98. As a consequence, I agree that 
creating a new table every 3 years doesn't necessarily make sense.

Indeed, the most common scenario is almost certainly that new field strings are 
appended to the table every year or so, but while they are 'somewhat' popular 
(more popular than the last entry in the table, at least), they're not 'really' 
popular - they're not going to be so popular that they displace the low-order 
numbers in the table and make a real difference. So no new version is required.

However...

Since the web traffic was originally sampled in 2018 to create that initial 
QPACK table, things have changed considerably. I suspect that some of the 
Client Hints header strings (Accept-CH etc.) have probably become very popular 
and will continue to do so - possibly to a point where it may make sense that a 
new registry be created with the table being reordered.

Additionally, the current QPACK table contains some entries that are, shall we 
say, weird. For example, many of the CORS entries (73-82) contain invalid 
values. While the point of the QPACK table is to aid compression (and therefore 
commonly-used fields, even if they are technically invalid, should be 
included), I'm surprised that some valid values are not included in there.

I wouldn't be surprised if we sampled traffic today (5 years after the original 
sample) we found a) a number of frequently-used headers which don't exist in 
the current static table; and b) that some of the headers in that table should 
be re-ordered because it would make an actual difference. Which would certainly 
mean appending those new fields, but very likely (again IMO) in re-ordering the 
table and creating a second registry.

Finally, while it may be the case that a new version is only needed every 10 
years, it makes sense to me to define the process for creating that version 
now, even if it's not needed for a while.

Thoughts?

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

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Mike Bishop]

Belatedly, as I’ve been offline for the past week, but I support this draft 
moving forward.

From: Nick Sullivan 
Sent: Thursday, May 3, 2018 1:16 PM
To: Sean Turner 
Cc: TLS WG 
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Does anyone have any comments about the draft, criticisms, or votes of support?

Nick
On Thu, May 3, 2018 at 1:12 PM Sean Turner 
mailto:s...@sn3rd.com>> wrote:


> On Apr 21, 2018, at 10:25, Sean Turner 
> mailto:s...@sn3rd.com>> wrote:
>
>
>> On Apr 19, 2018, at 16:32, Sean Turner 
>> mailto:s...@sn3rd.com>> wrote:
>>
>> All,
>>
>> This is the working group last call for the "Exported Authenticators in TLS" 
>> draft available at 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.  
>> Please review the document and send your comments to the list by 2359 UTC on 
>> 4 April 2018.
>
> … 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

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

Re: [TLS] WG adoption call: draft-rescorla-tls-esni

[Mike Bishop]

+1 – there are certainly kinks to work out, but this is a worthwhile direction.

From: TLS  On Behalf Of Patrick McManus
Sent: Wednesday, July 25, 2018 8:23 AM
To: Joseph Salowey 
Cc:  
Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni

I support adoption of this document and I will review and provide contributions 
to it as it evolves in the WG - its important work.

-Patrick


On Tue, Jul 24, 2018 at 10:16 PM, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

The sense of the TLS@IETF102 room was the the WG should adopt 
https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.  But, 
we need to confirm this on list.  If you would like for this draft to become a 
WG document and you are willing to review it as it moves through the process, 
then please let the list know by 2359UTC 20180807.  If you are opposed to this 
being a WG document, please say so (and say why).

Note that the draft has been marked as a "Candidate for WG Adoption” in the 
datatracker.



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

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

Re: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie

[Mike Bishop]

I support adoption, and I'm fine with -diediedie.  😉



-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Friday, August 17, 2018 10:33 AM
To: tls@ietf.org
Subject: [TLS] WG adoption call: draft-moriarty-tls-oldversions-diediedie



At the TLS@IETF102 session, there seemed to be some interest in adopting 
draft-moriarty-tls-oldversions-diediedie as a WG item. This email is to 
determine whether there is WG consensus to adopt this draft as a WG item.  If 
you would like for this draft to become a WG document and you are willing to 
review it as it moves through the process, then please let the list know by 
2359UTC 20180831.  If you are opposed to this being a WG document, please say 
so (and say why).



Note that we will suggest replacing “diediedie" with “deprecate" in the adopted 
draft’s name to address the naming comment raised during the meeting.



Thanks,

Chris, Joe and Sean

___

TLS mailing list

TLS@ietf.org

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

Re: [TLS] integrity only ciphersuites

[Mike Bishop]

I tend to think the strongest scenario for integrity-only ciphersuites is in an 
application where the data being transferred is already encrypted sufficiently. 
 For example, when running IPsec over an IP-HTTPS tunnel, Microsoft used a null 
cipher on the outer TLS layer.  However, as you say, this can be deceptive.  
DRM-protected media is already encrypted and seems like another application for 
this, but using TLS means it is not (as) trivial to identify that different 
flows are retrieving the same resource.

From: TLS  On Behalf Of Eric Rescorla
Sent: Monday, August 20, 2018 1:58 PM
To: Nancy Cam-Winget (ncamwing) 
Cc: tls@ietf.org
Subject: Re: [TLS] integrity only ciphersuites



On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) 
mailto:ncamwing=40cisco@dmarc.ietf.org>>
 wrote:
All,
A couple IoT consortiums are trying to embrace the improvements made to TLS 1.3 
and as they define their new security constructs would like to adopt the latest 
protocols, in this case TLS 1.3.   To that extent, they have a strong need for 
mutual authentication, but integrity only (no confidentiality) requirements.


In following the new IANA rules, we have posted the draft 
https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00 to 
document request for registrations of HMAC based cipher selections with TLS 
1.3…..and are soliciting feedback from the WG on the draft and its path forward.

Nancy,

As you say, you don't need WG approval for code point registration as long as 
you don't want Recommended status.

With that said, I don't think this document makes a very strong case for these 
cipher suites. Essentially you say:

1. We don't need confidentiality
2. Code footprint is important

Generally, I'm not very enthusiastic about argument (1). It's often the case 
that applications superficially need integrity but actually rely on 
confidentiality in some way (the obvious case is that HTTP Cookies are an 
authentication mechanism, but because they are a bearer token, you actually 
need confidentiatilty). It's much easier to just always supply confidentiality 
than to try to reason about when it is or is not needed.

The second argument is that you are trying to keep code size down. It's true 
that not having AES is cheaper than having AES, but it's possible to have very 
lightweight AES stacks (see for instance: https://github.com/01org/tinycrypt).

So, overall, this doesn't seem very compelling..

-Ekr




Warm regards, Nancy (and Jack)

___
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] Request to register value in TLS extension registry

[Mike Bishop]

Actually, I submitted a request to IANA while this RFC was in process which got 
sent to the tls-reg-review alias for approval.  There was apparently a hiccup, 
where the alias members did not receive the request from IANA, but did receive 
my follow-up e-mail asking if anyone had looked at it.  IANA's understanding of 
the new process at the time was:

>> Thank you for contacting us. We've sent this on to the new team of
>> IESG-designated experts. The Application-Layer Protocol Negotiation
>> (ALPN) Protocol IDs registry will be updated soon to include a link to
>> recently-approved document draft-ietf-tls-iana-registry-updates, which
>> provides new instructions for submitting registration requests for
>> some of the TLS registries. Specifically, in the future, new requests
>> should be sent to a mailing list (rather than IANA) for a three-week
>> review period. The experts will then contact us if they approve a
>> registration.

-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Wednesday, October 3, 2018 8:29 AM
To: Peter Gutmann 
Cc: tls@ietf.org
Subject: Re: [TLS] Request to register value in TLS extension registry



> On Oct 3, 2018, at 02:17, Peter Gutmann  wrote:
> 
> [CC'd back to the TLS list because this affects other TLS work as 
> well]
> 
> Benjamin Kaduk  writes:
> 
>> Having looked a bit harder, it seems that perhaps I need to point out 
>> that, if you want IANA to allocate a value, you need to *ask IANA for 
>> it*.  The tls-reg-rev...@ietf.org list is not a supported IANA 
>> entrypoint;
> 
> That's not what the RFC appears to say:
> 
>   Specification Required [RFC8126] registry requests are registered
>   after a three-week review period on the 
>   mailing list, on the advice of one or more designated experts.
> 
>   [...]
> 
>   Registration requests sent to the mailing list for review SHOULD use
>   an appropriate subject (e.g., "Request to register value in TLS bar
>   registry").
> 
> This is exactly what I did, I sent a registration request to the list 
> for review.
> 
>   Within the review period, the designated experts will either approve
>   or deny the registration request, communicating this decision to the
>   review list and IANA.
> 
> This never happened.
> 
> Did anyone actually test RFC 8447 before it was published?

You are the first.

> You send a request
> to a mailing list that doesn't seem to work, to be reviewed by a 
> secret panel (well, we know that Rich Salz is one member :-), with no 
> public discussion or list archives you can examine to see what 
> happened, and in my case no response to the registration request submitted as 
> per the RFC.

The “panel” is not secret.  The experts were identified when 
draft-ietf-tls-tls13 and draft-ietf-tls-iana-registry-updates were approved 
[0][1] and are/were enshrined in the IANA registry [2][3].

We are in the process of changing the archives to be public accessible.

Since you have been squatting on a code point for a bit [4], I am hoping that 
you can bear with us while we work the kinks out.

spt

[0] https://www.ietf.org/mail-archive/web/tls/current/msg25837.html
[1] https://www.ietf.org/mail-archive/web/tls/current/msg26316.html
[2] 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
[3] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[4] https://mailarchive.ietf.org/arch/msg/tls/rxIiS3pn63yp9YaZMODWXCk8mTg
___
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] Multi-CDN and ESNI

[Mike Bishop]

As we discussed in Montreal, the ESNI draft doesn't seem to interact well with 
origins which use multiple unrelated CDNs.  While Section 7.2.2 says that the 
scope of key sharing is between all hosts which can respond to a single IP 
address, but the DNS lookup method described actually makes it apply to all 
hosts responding to any IP address to which the target hostname might resolve.  
The conflict between these two generates the issue.

It would appear that there are two deployment models which are possible with 
the current draft:

Customers provide the ESNI keys to the CDN

This implies that the client will publish the TXT records directly and use the 
same keys across all CDNs they use to serve traffic.  This seems to be 
possible, since the ESNI extension carries the record_digest of the record; 
CDNs use the record_digest to look up the key which it should use to decrypt 
the extension.

However, an attacker can guess-and-check by resolving a particular domain and 
checking whether the record_digest returned matches that seen on an inspected 
connection.  If record_digests are unique per origin (or at least per 
customer's set of origins), ESNI protects relatively little.  Therefore, I 
presume that the desire is for ESNI keys to be the same for all / large 
populations of a CDN's customers.

CDN uses the same ESNI keys for all customers

This implies the CDN will be the one generating keys and publishing the ESNI 
records; the client domain will use CNAMEs to point to the CDN's ESNI record.  
However, a common strategy for load sharing between CDNs is to provide 
different CNAME responses to the desired portion of traffic.  If the CNAME 
returned during an A/ query differs from the CNAME returned during a TXT 
query, the server receiving the traffic will be unable to decrypt the SNI.  As 
far as I'm aware, DNS provides no mechanism to guarantee this selection will be 
atomic.

(Incidentally, you say in 6.2 that this will probably result in an invalid 
identity which doesn't chain to a public trust root; it might very well be a 
trusted certificate, albeit for the wrong name.)


Fundamentally, it seems like the choice of CDN and the choice of ESNI 
parameters have to be delivered to clients together and with comparable TTLs; 
the TXT record design makes it difficult to do that.  Embedding the ESNI 
information in Alt-Svc would be an HTTP-specific solution, but might be an 
alternative we should consider.

If there's a more general-purpose way of ensuring the information is delivered 
consistently without compromising privacy, I'm happy to see it solved in a 
non-HTTP manner instead / as well.  One such option, which I think someone 
raised in Montreal, might be to bind the ESNI record to the 
in-addr.arpa/ip6.arpa name for the resolved IP address instead of to the 
hostname.  This necessarily serializes the DNS queries, which is sub-optimal 
for performance.  More fatally, server operators in general are less likely to 
control this namespace.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

[Mike Bishop]

Perhaps a better way to phrase it is that a server which successfully 
authenticates as the public_name but does not support ESNI has securely 
disabled ESNI for that origin, subject to the same rules as if it had supplied 
a new ESNI key (i.e. use for now, but don't persist).  Leave as an 
implementation detail heuristics to extrapolate that the current network will 
securely disable ESNI for all origins.

-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Wednesday, February 13, 2019 4:24 PM
To: David Benjamin 
Cc: TLS WG 
Subject: Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE


Hiya,

Various bits'n'pieces below...

On 13/02/2019 23:55, David Benjamin wrote:
> Thanks for the comments! Responses inline.
> 
> On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell 
> 
> wrote:
> 
>>
>> Hiya,
>>
>> On 13/02/2019 22:15, Christopher Wood wrote:
>>>
>>>
>>> [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124
>>
>> I just re-read that. I've a question: why tie the version change to 
>> this PR and not the I-D rev? I'd prefer if we make the change to 
>> 0xff02 when -03 is published. (I don't care which PR does that, but 
>> wouldn't like to see every PR bump that number.)
>>
> 
> I bumped it because the PR was making a wire-incompatible change, but 
> batching them up to I-D revs makes sense too. No preferences here. 
> (Spec editors, do you care? I can remove that part of the change.)
> 
> 
>> Aside from that I think it's ok (though I may find other issues when 
>> implementing later) with two caveats that can be handled now or 
>> later:
>>
>> 1. The DNS RR structure still needs fixing but that is likely better 
>> handled separately. (By "fixing" I mean a new RR type but also that 
>> it needs to be designed for DNS admins as well and not only for TLS 
>> implementers which is the current case.
>> (I'm not saying what might or might not make it more dnsops friendly, 
>> just that that needs to be checked/done sometime.)
>>
> 
> I'm guessing this is to do with the various discussions around 
> multi-CDN and whatnot? That seems orthogonal to that PR. (I don't 
> personally have particularly strong opinions or experience there.)

Not just that. ESNIKeys is a fairly complex structure that has a number 
sets/sequences of values. There are various possible deployment models. The 
current structure assumes that it's ok to encode all that stuff up in one TLS 
style blob and then put that in the DNS. That might not make sense for some 
deployments in particular where the DNS operator is not closely tied to the TLS 
server admin or where there's
1 DNS operator and N TLS server admins (for the same origin).
And then there's the use of the TXT RR. But I agree this is orthogonal - I was 
mostly saying that in agreeing with this PR I continue to think the DNS RR 
stuff needs other work.

> 
> 
>> 2. I don't think the text below ought be included, it's not the job 
>> of this WG to design MITM attacks. (Or maybe I've misinterpreted it?)
>>
>> "The public name, however, makes this protocol compatible with 
>> deployments that use correctly-implemented MITM proxies. If the 
>> client has cached an ESNIKey for the origin server, the MITM proxy 
>> will process the cleartext SNI field and terminate a connection to 
>> the public name instead. If the client is configured to trust the 
>> proxy's certificate, it will accept the connection as valid for the 
>> public name and retry with ESNI disabled."
>>
> 
> That text isn't prescribing any particular behavior. 

Then delete it:-)

> It's just describing
> the effect the rest of the text has on "trusted MITM proxies" and the like.

Disagree. "Just describing" does not match the use of a meaningless marketing 
term like "trusted blah proxy" sorry. Better to avoid all that fuss really, no?

> Note this is specifically about "MITM proxies" which control a root 
> certificate that the client is configured to trust. I will refrain 
> from commenting on whether this deployment model is at all wise, but 
> it does exist (antivirus, etc). The text itself is just an updated 
> version of existing bits here:
> https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2

I don't recall that having a concept of it being possible to "correctly" 
implement breaking the TLS protocol? (As is inherent in being an MITM.)

> 
> As for where this effect comes from, it's a consequence of the 
> rollback and partial deployment robustness mechanism in the PR:
> 
>> If the server negotiates an earlier version of TLS, or if it does not 
>> provide an "encrypted_server_name" extension in EncryptedExtensions, 
>> the client proceeds with the handshake, verifying the certificate 
>> against ESNIKeys.public_name as described in {{verify-public-name}}. 
>> The client
> MUST
>> NOT enable the False Start optimization {{RFC7918}}. If the handshake
> completes
>> successfully, the client MUST abort the connection with an
> "esni_required" alert.
>> It then SHOULD

Re: [TLS] Two Multi-CDN proposals

[Mike Bishop]

Despite the additional complexity of #137, I think it's probably the better 
approach (and I would be fine with the simplification, if that makes it more 
palatable).  Particularly when multi-CDN is used, there's a lot of logic 
involved in generating the "right" A/ record in response to a request.  
#136 essentially lets the ESNIKeys result override the A/, which means 
ESNIKeys needs to be equally tailored and duplicate all the existing logic for 
a new record type.  In #137, the ESNIKeys essentially contains enough 
information to check that the A/ results came from the same entity as the 
ESNIKeys result but leaves the DNS complexity where it already exists.  (It has 
the option to override, and removing that would be the simplification.)



The tripping point of #137, however, is that it may need a recovery path (i..e. 
a second A/ resolution) in case the records come from mismatched providers. 
 We don't currently have data on how often that would happen -- whether it's 
10% or 0.001% of the time would make a big difference.



-Original Message-
From: TLS  On Behalf Of Christopher Wood
Sent: Wednesday, February 27, 2019 8:18 AM
To:  
Subject: [TLS] Two Multi-CDN proposals



Hi folks,



Below are two PRs that seek to address the multi-CDN issue discussed on this 
list and in meetings:



   1. https://github.com/tlswg/draft-ietf-tls-esni/pull/136

   2. https://github.com/tlswg/draft-ietf-tls-esni/pull/137



#136 implements the combined or stapled record approach discussed several 
times, most recently in [1]. It includes these via an ESNIKeys extension. #137 
builds on this design with a mechanism that lets clients detect and recover 
from A/ and ESNI mismatch (if desired).

It is certainly more complex in several respects. A third variant, which is not 
(yet) in PR form, is a simplification of #137 wherein ESNIKeys addresses are 
only used as filters, instead of filters *or* complete addresses.



We are asking for feedback on these PRs, as we would like to merge one of them 
for the next draft version. As #136 is simpler and permits extensibility, that 
is the current preference.



Thanks in advance for your feedback.



Best,

Chris (no hat, on behalf of the authors)



[1] https://mailarchive.ietf.org/arch/msg/tls/WXrPgaIsIPItDw3IQthmJk9VRlw



___

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] Two Multi-CDN proposals

[Mike Bishop]

Stephen, there are a couple complicating factors here where I think we all have 
varying knowledge gaps.

  *   There are two major ways of pointing to a CDN:  Direct A/ records and 
CNAMEs.  The easiest way to handle key update complexities on the part of the 
CDN(s) is simply to CNAME the ESNI query for your domain to their ESNI record, 
but you can certainly directly host your CDN’s keys in your domain if you 
prefer.  Nothing should preclude that.
  *   The issue we’re trying to address is when the ESNI record and the A/ 
record follow different CNAME chains and you get the records from different 
hosts.  Of course, if we move to an ESNI RRType with the same hostname (see 
#105), there’s hopefully a single CNAME chain that gets cached at the resolver 
and used when looking up both queries.  If they remain separate hostnames, it 
seems like it gets much easier for them to diverge.
  *   It’s my understanding that DNSsec doesn’t play well with returning a 
subset of all extant RRs for a given name+type.  However, some CDNs return DNS 
results tailored to the user’s location; the load-balancing servers will (in 
some cases) return CNAMEs to different targets based on the desired traffic 
share.  That’s not a behavior that maps well to DNSsec as I understand it.  You 
mention DNSsec signing your domain as part of why you have issues with the 
proposal, but I think this is an open issue beyond ESNI or these PRs.



Maybe someone better-steeped in DNS/DNSsec can help us figure out how all that 
should work, and I agree with you that there are definitely bumps here we need 
to iron out – maybe those are just questions to answer, or maybe changes to the 
structure of the record are warranted.



However, these PRs are primarily about what information should be in these 
records and how clients make use of it.  I disagree with you that we have to 
resolve both questions at the same time.  Let’s agree on content first, and 
spent some time separately with DNS folks to see whether the content can be 
more pleasantly arranged.



-Original Message-
From: TLS  On Behalf Of Stephen Farrell
Sent: Thursday, February 28, 2019 2:50 AM
To: Eric Rescorla 
Cc:  
Subject: Re: [TLS] Two Multi-CDN proposals





Hiya,



On 28/02/2019 02:40, Eric Rescorla wrote:

> On Wed, Feb 27, 2019 at 5:56 PM Stephen Farrell

> mailto:stephen.farr...@cs.tcd.ie>>

> wrote:

>

>>

>> Hiya,

>>

>> On 28/02/2019 01:41, Eric Rescorla wrote:

>>> I think you're misunderstanding the scenario here: we have two CDNs

>>> A and B, and some switching service in front, so that when you

>>> lookup

>> example.com,

>>> you get a CNAME to A or B, and then you get the ESNIKeySet

>>

>> (ESNIKeySet is a type you've just invented I guess?)

>>

>

> No. I forgot it was named ESNIKeys

>



Phew:-)



>>> for A or B as

>>> the case may be. So you're not going to get both ESNIKeys values.

>>

>> Yes, that's not the model I had in mind. I don't recall that having

>> been written down but maybe I missed it. (Where should I look?)

>>

>

> I believe this was discussed in Bangkok during the discussion of

> problems with the current structure.



FWIW, I didn't take from that discussion that we only want that model to be 
supported, but it may have passed me by if that was stated.



>> The model I had in mind was where the hidden site has it's own DNS

>> operator but >1 CDN/front-site with each of those having a private

>> ESNI value. (And if there's some front-end DNS cleverness, it'd kick

>> in when the CNAME from #137 is being chased down.)

>>

>

> I don't see how this is conflicts with what I said above, as that

> server still needs to ensure consistency.



I don't think mine conflicts with the model you describe, but I do think it has 
different consequences for how we ought structure the ESNIKeys stuff.



To be more specific, say in my model I have example.com and want to see ESNI 
used for www.example.com and I publish the zone for 
example.com including ESNIKeys.



Now I want browsers to be able to use either cdn1.example or cdn2.example to 
front for www.example.com where those are independent 
CDNs.



So I need to update my DNS zone periodically whenever one or other CDN changes 
their ESNI public key share.

In my tiny little case doing this for a few domains, I already have a small 
infrastructure that allows me to do that kind of thing because of the need for 
regular DNSSEC re-signing. (Mine currently works at a weekly or daily cadence, 
but doing it hourly would be fine.)



I'd like to do that via a simple update to my zone files without having to 
unpack and re-pack the data structures I get from cdn1 or cdn2. Now sure, I 
could write a new tool to munge together what I get from the CDNs but that's 
more work (that could go wrong) and doesn't match my current work flows. And I 
suspect others may operate similarly.



That's what leads me to think that we'd be be

Re: [TLS] Two Multi-CDN proposals

[Mike Bishop]

"The issue" the PRs are attempting to solve, not in terms of ESNI 
all-inclusive.  I think we're on the same page, then, except that I'm confused 
by two things in your reply that appear to be contradictory:  You want to 
address the content "and structure" of ESNIKeys now, but in the next paragraph 
reiterate that you're fine leaving what I see as the structural parts for later.

Reading through the thread again, I think I see at least one concrete issue 
with the current PRs that you raised:  The PRs currently assumes that they get 
back a single ESNI record and one or more A/ records.  Depending on the 
deployment, it's possible that there are multiple ESNIKeys records and the 
draft explicitly permits this, but PR#137 currently does not describe the 
handling for that.  (PR#136 doesn't really need to, since it disregards the 
A/ records.)

However, the more common deployment scenario for multi-CDN would be a single 
record (per version, eventually) from each CDN; each client would receive only 
one.

-Original Message-
From: Stephen Farrell  
Sent: Friday, March 1, 2019 3:53 PM
To: Mike Bishop ; Eric Rescorla 
Cc:  
Subject: Re: [TLS] Two Multi-CDN proposals


Hiya,

On 01/03/2019 23:19, Mike Bishop wrote:
> Stephen, there are a couple complicating factors here where I think we 
> all have varying knowledge gaps.
Doubtless. I confess lots of ignorance as to how CDNs operate.

> 
> *   There are two major ways of pointing to a CDN:  Direct A/
> records and CNAMEs.  The easiest way to handle key update complexities 
> on the part of the CDN(s) is simply to CNAME the ESNI query for your 
> domain to their ESNI record, but you can certainly directly host your 
> CDN’s keys in your domain if you prefer.  Nothing should preclude 
> that.`

I agree that we need something that works for both. As there are meta-issues 
with some privacy mechanisms encouraging more centralisation, I think it's 
important that we be explicit in considering such, as we've been doing here. 
(To simplify and paraphrase it a bit: part of my position is that "nothing 
should preclude" is too weak - ESNI needs to work for both - to the extent 
possible.)

> *   The issue we’re trying to address is when
> the ESNI record and the A/ record follow different CNAME chains 
> and you get the records from different hosts.  Of course, if we move 
> to an ESNI RRType with the same hostname (see #105), there’s hopefully 
> a single CNAME chain that gets cached at the resolver and used when 
> looking up both queries.  If they remain separate hostnames, it seems 
> like it gets much easier for them to diverge.

I agree with all you say except the first one of the two words "the issue" - 
there is more than one issue at play I'd say:-)

> *
> It’s my understanding that DNSsec doesn’t play well with returning a 
> subset of all extant RRs for a given name+type.  However, some CDNs 
> return DNS results tailored to the user’s location; the load-balancing 
> servers will (in some cases) return CNAMEs to different targets based 
> on the desired traffic share.  That’s not a behavior that maps well to 
> DNSsec as I understand it.  You mention DNSsec signing your domain as 
> part of why you have issues with the proposal, but I think this is an 
> open issue beyond ESNI or these PRs.

It seems I didn't explain myself so well. For my setup the fact that I support 
DNSSEC (and hence periodic re-signing) makes it easier for me to support 
periodically acquiring and (re-)publishing ESNIKeys from multiple sources. So 
having an existing DNSSEC setup helps here.

Other than that, I'm not sure DNSSEC and ESNI have so much to do with one 
another, given that DNSSEC really doesn't provide any cryptographic linkage 
when things like MX or CNAME are used in the DNS.

> Maybe someone better-steeped in DNS/DNSsec can help us figure out how 
> all that should work, and I agree with you that there are definitely 
> bumps here we need to iron out – maybe those are just questions to 
> answer, or maybe changes to the structure of the record are warranted.
> 
> 
> 
> However, these PRs are primarily about what information should be in 
> these records and how clients make use of it.  I disagree with you 
> that we have to resolve both questions at the same time.  Let’s agree 
> on content first, and spent some time separately with DNS folks to see 
> whether the content can be more pleasantly arranged.

I'm not quite sure what you mean but I can think of two things:-

1. I have argued about how the content and structure of ESNIKeys can affect 
deployment models and manageability, and do think that now is the time to 
consider both. I maintain that position. And my main points in this thread have 
all been about how the structure of ESN

Re: [TLS] Two Multi-CDN proposals

[Mike Bishop]

Totally agree that we want to avoid the extra DNS round-trip as often as 
possible.  However, I see the options in the opposite light – if all you need 
is #136, then you can put exact addresses into #137 and get the same behavior.  
The question is whether the additional capabilities of #137 are safe and 
needed.  Depending how much later #137 is added, we may wind up needing to 
support both, which would be… suboptimal.

I think what will swing the needle on safety – how often there’s divergence – 
lies in how the record is positioned.  Two problems with the current approach 
that I see:

  *   Correct me if I’m wrong, but I don’t believe the alias is allowed to have 
subdomains.  If www.example.com<http://www.example.com> is a CNAME, then 
_esni.www.example.com cannot exist, can it?
  *   Even presuming that it did, or that it weren’t a subdomain, it would 
follow its own CNAME chain which might not lead to the correct provider.

If, however, the ESNIKeys RRType is resolved by following the CNAME from the 
host, it depends on how often two queries for two different RRTypes on the same 
hostname follow different CNAME chains.  We have a ready-made way to test that 
– A and .  I have an idea where we can get some data on that.

From: TLS  On Behalf Of Eric Rescorla
Sent: Friday, March 1, 2019 7:19 PM
To: Nick Sullivan 
Cc:  
Subject: Re: [TLS] Two Multi-CDN proposals


On Fri, Mar 1, 2019 at 6:39 PM Nick Sullivan 
mailto:40cloudflare@dmarc.ietf.org>> 
wrote:


On Fri, Mar 1, 2019 at 6:27 PM Christopher Wood 
mailto:christopherwoo...@gmail.com>> wrote:
On Fri, Mar 1, 2019 at 3:19 PM Mike Bishop 
mailto:mbis...@evequefou.be>> wrote:
>
> Stephen, there are a couple complicating factors here where I think we all 
> have varying knowledge gaps.
>
> There are two major ways of pointing to a CDN:  Direct A/ records and 
> CNAMEs.  The easiest way to handle key update complexities on the part of the 
> CDN(s) is simply to CNAME the ESNI query for your domain to their ESNI 
> record, but you can certainly directly host your CDN’s keys in your domain if 
> you prefer.  Nothing should preclude that.
> The issue we’re trying to address is when the ESNI record and the A/ 
> record follow different CNAME chains and you get the records from different 
> hosts.  Of course, if we move to an ESNI RRType with the same hostname (see 
> #105), there’s hopefully a single CNAME chain that gets cached at the 
> resolver and used when looking up both queries.  If they remain separate 
> hostnames, it seems like it gets much easier for them to diverge.
> It’s my understanding that DNSsec doesn’t play well with returning a subset 
> of all extant RRs for a given name+type.  However, some CDNs return DNS 
> results tailored to the user’s location; the load-balancing servers will (in 
> some cases) return CNAMEs to different targets based on the desired traffic 
> share.  That’s not a behavior that maps well to DNSsec as I understand it.  
> You mention DNSsec signing your domain as part of why you have issues with 
> the proposal, but I think this is an open issue beyond ESNI or these PRs.
>
> Maybe someone better-steeped in DNS/DNSsec can help us figure out how all 
> that should work, and I agree with you that there are definitely bumps here 
> we need to iron out – maybe those are just questions to answer, or maybe 
> changes to the structure of the record are warranted.
>
> However, these PRs are primarily about what information should be in these 
> records and how clients make use of it.  I disagree with you that we have to 
> resolve both questions at the same time.  Let’s agree on content first, and 
> spent some time separately with DNS folks to see whether the content can be 
> more pleasantly arranged.

Thanks all for the discussion so far! Focusing strictly on the content
of the records and not the formatting, as Mike suggests, we
essentially have the following:

- #137 gives clients a way to detect A/+ESNI mismatch and recover,
at the cost of another sequential DNS query for ESNI. In this change,
A/ records still control where traffic goes.
- #136 never requires clients to send a second DNS query for ESNI
since clients ignore the A/ results. In this change, ESNI records
dictate routing.

With #137, clients willing to send a second DNS query will get ESNI
for all supporting providers. Clients unwilling to send a second DNS
query will only get ESNI for those providers which ensure that their
A/ and ESNI records very rarely mismatch. With #136, clients only
get ESNI for those providers capable of building ESNI records with
correct addresses. In theory, these providers should be the same ones
that could ensure A/ and ESNI record matching.

Given this, the discussion seems to hinge on the following question:
Are operators comfortable with the risks of letting ESNI 

Re: [TLS] On the difficulty of technical Mandarin (SM3 related)

[Mike Bishop]

The actual requirement in RFC 8126 doesn’t say the public specification needs 
to be in English, but it does say that “the designated expert will review the 
public specification.”  This suggests that whatever language the authoritative 
specification might be posted in, the designated expert needs to be able to 
understand it and/or the WG would need to designate an alternate expert able to 
review it appropriately.

Obviously, given that the IETF works in English, an authoritative 
English-language specification makes that easier to achieve.  But a 
translation, even one hosted by a responsible body, almost always contains 
verbiage that only the original language is considered authoritative.

From: TLS  On Behalf Of Watson Ladd
Sent: Monday, August 19, 2019 11:05 AM
To: TLS List 
Subject: [TLS] On the difficulty of technical Mandarin (SM3 related)

Dear all,

I see no reason why English alone should be accepted for standards documents we 
reference. French and German pose few difficulties, and one can always learn 
Russian.

What I don't know is how difficult Mandarin is at a level to read a standards 
document. I expect the mechanics of using the dictionary to dominate.

I'm concerned about the traceability of unofficial Englidh PDFs on some 
website: could the Chinese body responsible host them instead?

I fully expect this to be a more general IETF problem.

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

Re: [TLS] Clarification on Delegated Credential validation

[Mike Bishop]

I would have assumed the second interpretation as the intent, but you’re 
correct that value doesn’t exist.  Perhaps we should say that the credential’s 
“remaining” time to live is no more than the maximum validity period?  And fix 
the assertion, of course.

From: TLS  On Behalf Of Kevin Jacobs
Sent: Wednesday, February 26, 2020 5:53 PM
To: tls@ietf.org
Subject: [TLS] Clarification on Delegated Credential validation


TLSWG,

There seems to be some ambiguity in draft-ietf-tls-subcerts. [4.1.3 Validating 
a Delegated Credential] states: "1. Verify that the current time is within the 
validity interval of the credential and that the credential's time to live is 
no more than the maximum validity period. This is done by asserting that the 
current time is no more than the delegation certificate's notBefore value plus 
DelegatedCredential.cred.valid_time."

There are two issues with this:

  1.  The described assertion only ensures that the first condition is met.
  2.  The second condition - "and that the credential's time to live is no more 
than the maximum validity period" - is unclear:

 *   If we assume "time to live" on a DC to be the remaining time (based on 
the verifying peer's clock), the described check should also assert 
"EECert.notBefore + DC.valid_time - currentTime <= maximum validity period".
 *   If we assume "time to live" on a DC to be the initial TTL (spanning 
issuance to expiration), we lack the information needed to effectively verify 
this, as DC.valid_time is based on EECert.notBefore rather than DC.notBefore 
(which does not exist). For example, if 7-day DCs are issued, "EECert.notBefore 
+ DC.valid_time" will be a 7-day span on the first issuance, a 14-day span on 
the second, etc. until the EE cert is reissued.

I believe the first interpretation is intended, but the client is then unable 
to verify that the DC lifespan is actually less than the maximum validity 
period (should such a check be desired), only that the DC will expire within 
that period. Either way, the expected behavior should be clarified.

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

[TLS] HTTP, Certificates, and TLS

[Mike Bishop]

Hi, folks -

Martin and I had come previously to the TLS WG to discuss our work with 
handling client certificates at the HTTP layer.  Based on that discussion, we 
revised our model to cover signatures of an exporter value and carry the proof 
in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipping the 
model in the opposite direction - carrying additional server identities as 
well.  That means we now have a proposal for carrying both client and server 
certificates above TLS, found at 
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

We have also discussed that it might be preferable to pull part of this 
capability back into TLS, expanding post-handshake authentication to allow 
providing multiple certificates in either direction.  Since that would 
necessarily require additional work on that part of the TLS 1.3 spec, we 
discussed the possibility of splitting post-handshake authentication into a 
separate spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled 
and take a little longer on the second draft.

Having spoken to some other TLS WG members, some people would prefer to move 
post-handshake authentication entirely to our layer.  While that's probably not 
feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what 
HTTP/2 does), we can retain our application-layer authentication.  This has the 
advantage of leaving TLS 1.3 unchanged, but keeps a security draft in a 
non-security working group.  We are concerned that, by doing this at the HTTP 
layer, we'll be missing necessary security expert review as this moves forward. 
 (EKR already suggested some necessary improvements to our signature model to 
prevent some pretty trivial attacks; these aren't reflected in the current 
draft.)  If that's the route we go, I would greatly appreciate some TLS folks 
visiting the HTTP WG and helping us review this draft.

I was on the "time permitting" list to present in the TLS meeting on Tuesday, 
and we didn't get a chance to.  We'll be discussing the actual draft tomorrow 
morning in HTTP; I'd be happy to have some TLS folks there to discuss the 
draft, and I'd like to get a sense from the TLS WG whether there's a preference 
for us to do this at the application layer or pass additional requirements to 
post-handshake auth.

Thanks!
-Mike Bishop
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

I assume you're referring to Section 3, SNI's ServerNameList MUST NOT contain 
more than one name of a given type?  Technically, we're not violating that, 
since we're not changing SNI.  The client requests a single identity in the TLS 
handshake, which the server provides.  Additional identities can be 
demonstrated later, regardless of where.



Or are you referring to the (lower-case) must not resume if SNI and the 
certificate used in the resumed session differ?  For HTTP, we're leaving 
resumption out of the picture, requiring that any secondary certificates be 
proved anew for each connection.  You're certainly correct that if the logic 
were moved to TLS, the semantics of resumption would have to be defined.  That 
may be a solid argument on why it should remain at the application layer.



-Original Message-
From: Martin Rex [mailto:m...@sap.com]
Sent: Thursday, July 21, 2016 5:57 PM
To: Mike Bishop 
Cc: tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS



Mike Bishop wrote:

>

> That means we now have a proposal for carrying both client and server

> certificates above TLS, found at

> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs.

>

> We have also discussed that it might be preferable to pull part of

> this capability back into TLS,



You are facing a MUST NOT in rfc6066 for this particularly bad idea.



I'm currently wondering what kind of (weird) TLS session caching strategy would 
actually allow you to create such client or server behaviour.

You're definitely in severe conflict with the "principle of least surprise"

in respect to deterministic behaviour of your TLS clients and TLS servers.



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

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

Ah, I was seeing the lower-case version in Appendix A from a quick search.  
Yes, that one is upper-case.

Still, that seems simple enough to handle in whatever discussion of how 
resumption affects this.  If they remain in effect across a resumption, any 
name in that set could reasonably be valid; if not, then only the name on the 
certificate is originally valid.

>From an HTTP layer, we see this as analogous to a certificate with multiple 
>SANs present -- if the original connection asked for one name on the cert, but 
>a resumption asked for a different SAN, is resumption permitted?  This seems 
>to suggest that it's not, and to strictly obey that requires that the server 
>remember which of several hostnames tied to that certificate was actually used 
>to establish the connection.

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Thursday, July 21, 2016 6:42 PM
To: Mike Bishop 
Cc: m...@sap.com; tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS

Mike Bishop wrote:
>
> I assume you're referring to Section 3, SNI's ServerNameList MUST NOT 
> contain more than one name of a given type?
>
> Or are you referring to the (lower-case) must not resume if SNI and 
> the certificate used in the resumed session differ?

My (online) copy of rfc6066 has a (fully reasonable) upper-case MUST NOT.


Last paragraph on page 7, rfc6066 (TLS extension server_name_indication)

https://tools.ietf.org/html/rfc6066#page-7

   A server that implements this extension MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session.


-Martin

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

Re: [TLS] HTTP, Certificates, and TLS

[Mike Bishop]

That argument seems like it would apply to all post-handshake authentication, 
unless there's something different about that.

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Thursday, July 21, 2016 7:08 PM
To: Martin Thomson 
Cc: m...@sap.com; Mike Bishop ; tls@ietf.org
Subject: Re: [TLS] HTTP, Certificates, and TLS

Martin Thomson wrote:
> On 21 July 2016 at 18:41, Martin Rex  wrote:
>>A server that implements this extension MUST NOT accept the request
>>to resume the session if the server_name extension contains a
>>different name.  Instead, it proceeds with a full handshake to
>>establish a new session.
> 
> If that's the only barrier to doing this, I'd be surprised.  The 
> prospect of having to overcome this is not at all daunting.

No, that is only the tip of an iceberg, and you're going Titanic here.

Really, this is about TLS session cache management (which is something very 
close to TLS) vs. Endpoint identification, i.e. interpreting end-entity 
certificates -- which is something that is explicitly outside of the scope of 
TLS (e.g. rfc2818 and rfc6125).


Could you please describe the approach to session cache management that you're 
conceiving here?  In the original TLS architecture (up to TLSv1.2) TLS sessions 
are read-only after creation, and identities (certificates) are locked down.  
Forgetting to cryptographically bind the communication identities into the 
session properties allowed the triple-handshake-attack.


If you want to change any session properties (including certificates), you MUST 
perform a new full handshake, which creates a new session with new properties 
and a new session ID / session cache entry.

Session resumption (and session resumption proposal) should operate based on 
requested properties (is there an existing session with the requested 
properties?) and this is conceptually independent from the app-level endpoint 
identification (such as rfc2818/rfc6125).


The wording in rfc6066 is not optimal.  It should have better said:
whenever a full handshake would result in selection of a different server 
certificate, then the server MUST perform a full handshake, in order to produce 
predictable/deterministic behaviour that is not side-effected by session cache 
management / session cache lifetime effects.  The principle of least surprise.


-Martin

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

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Mike Bishop]

There are a couple of scenarios we need to keep in mind:

1.   Existing HTTP/1.1 exchanges over upgraded TLS clients.  If we need a 
brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 
1.3, that’s fine.

2.   Client authentication in HTTP/2.  Slightly longer RFC for this (but 
possibly the same one) that says post-handshake client auth is allowed for 
HTTP/2, then describing how to use the context (and new HTTP/2 frames, if 
needed) to bind the PHA exchange to one or more streams.

3.   Secondary server authentication in HTTP/2.  This approach still 
doesn’t give a clean way to do this, unless we use exporters and roll our own.  
That has proven to be a little hazardous to everyone’s peace of mind, but 
remains something we can refine in the future.

What concerns me more, though, is the prospect that a lot of TLS 
implementations would simply omit support.  Obviously, it’s not used in most 
HTTP sessions, and you may be an implementation whose niche doesn’t require 
supporting it – but since the application profile allows it, you still need to 
know how to decline if asked.  If it’s allowed in HTTP, which I assume is a 
supported workload for most implementations, then it’s allowed in your 
application profile and therefore prohibiting it by default doesn’t seem like 
it buys you much.  Having a simple way to disclaim support, either at 
connection time or upon receiving a challenge, seems like it provides more 
simplicity for the implementations that want to omit it.

From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla ; Hannes Tschofenig 
; Mike Bishop 
Cc: tls@ietf.org
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for 
specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use case 
was only
about HTTP/H2.

Thanks,
-Ekr



On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enable
> are not needed. Some types of connections/implementations don't need to
> support key updates (some unidirectional connections), session tickets
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don't
> need to be.
>
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts more
> explicit.
>
> PR:
> https://github.com/tlswg/tls13-spec/pull/676
>
> Nick
>
>
> ___
> TLS mailing list
> TLS@ietf.org<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
>

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

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

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

[Mike Bishop]

Ekr, can I ask you to clarify this a little? I fully agree that extensions to 
TLS which support a particular application-layer protocol should be done in 
that protocol’s working group unless and until it’s demonstrated that many 
unrelated applications will need something similar. (At which point, it 
probably makes sense to build the general thing, either in TLS or a new WG.) 
But this isn’t that.

For something that concerns the TLS exchange itself, the TLS WG does still seem 
like the natural home to me. Where are you suggesting the standards work 
happens instead? Are you suggesting that this should be registered to the I-D, 
or go to a new/different working group? The former path seems like it won’t get 
the review it needs, and I’m not sure any other WGs are appropriately chartered 
for the latter.

Personally, I support adoption for the use case. It sounds like there’s an 
alternative design that might need to be hammered out, but since it appears a 
document may be needed for either path, let’s adopt and argue about that later.

From: TLS  On Behalf Of Eric Rescorla
Sent: Wednesday, April 3, 2024 10:28 AM
To: Watson Ladd 
Cc: Christopher Patton ; TLS List 

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



On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:

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?

Why? The attitude I am trying to get away from is that the TLS WG has to
be involved in every extension to TLS. Rather, we should decide what things
are important and spend time on them and then let others extend TLS 
independently
in areas we don't think are important.

-Ekr

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

[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

[Mike Bishop]

RFC 9460 says this:

Protocol mapping documents MAY specify additional underscore-prefixed labels to 
be prepended. For schemes that specify a port (Section 3.2.3 of [URI]), one 
reasonable possibility is to prepend the indicated port number if a non-default 
port number is specified. This document terms this behavior "Port Prefix 
Naming" and uses it in the examples throughout.



As this document is not a protocol mapping, but simply the definition of a 
SvcParam which could be used by any protocol mapping, I don’t believe mandating 
anything about how mappings construct their names is appropriate here.



RFC 9460 does use Port Prefix Naming for HTTPS records when accessing an origin 
on a non-default port; that doesn’t use MUST, but it’s a definition of how the 
HTTP origin maps to the HTTPS query name.  Another protocol mapping might 
choose a different construction, and that wouldn’t affect anything about how 
this SvcParam works.



-Original Message-
From: Raghu Saxena 
Sent: Wednesday, June 12, 2024 11:31 PM
To: tls@ietf.org
Subject: [TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted 
ClientHello with DNS Service Bindings



I had one comment earlier that seems to have been missed [0].



Basically I was wondering if it may be useful to use stronger language in the 
draft to indicate a client MUST use Port Prefix Naming when looking up the SVCB 
record.



Regards,



Raghu Saxena



[0] https://mailarchive.ietf.org/arch/msg/tls/ynRkX60dGq-ofmSW4POhppQcgkY/



On 6/13/24 2:10 AM, Sean Turner wrote:

> This email starts the working group last call for "Bootstrapping TLS 
> Encrypted ClientHello with DNS Service Bindings” I-D, located here:

>

> https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/

>

> The WG Last Call will end 26 June 2024 @ 2359 UTC.

>

> Please review the I-D and submit issues and pull requests via the GitHub 
> repository that can be found at:

>

> https://github.com/tlswg/draft-ietf-tls-svcb-ech

>

> Alternatively, you can also send your comments to 
> tls@ietf.org.

>

> Thanks,

> spt

> ___

> TLS mailing list -- tls@ietf.org

> To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

[Mike Bishop]

I support publication, but I'm slightly biased since my name is on the doc.

However, I noticed that the repo didn't have the Issue Tracker or Editor's Copy 
enabled; I've enabled those, so if anyone has been holding WGLC feedback for 
that reason, you can file your issues now. I created issues for the two WGLC 
comments I've seen so far.

-Original Message-
From: Sean Turner  
Sent: Wednesday, June 12, 2024 2:11 PM
To: TLS List 
Subject: [TLS]Working Group Last Call for Bootstrapping TLS Encrypted 
ClientHello with DNS Service Bindings

This email starts the working group last call for "Bootstrapping TLS Encrypted 
ClientHello with DNS Service Bindings” I-D, located here:

https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/

The WG Last Call will end 26 June 2024 @ 2359 UTC.

Please review the I-D and submit issues and pull requests via the GitHub 
repository that can be found at:

https://github.com/tlswg/draft-ietf-tls-svcb-ech

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

[Mike Bishop]

Responses to some of these in-line below. More generally, I think several of 
these arise from the question of whether requirements on "publishers" apply 
specifically to a tool which is automatically generating these records or 
generally to the operating entity causing the records to be created. I believe 
Section 3 is attempting to describe a state that needs to exist for safe 
deployment, not attempting to specify a tool per se. Thus I generally support 
leaving and/or moving requirements on automation to [1].

> -Original Message-
> From: Stephen Farrell 
> Sent: Monday, June 24, 2024 8:00 PM
> To: Sean Turner ; TLS List 
> Subject: [TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted
> ClientHello with DNS Service Bindings
> 
> 
> Hiya,
> 
> On 21/06/2024 17:26, Sean Turner wrote:
> > Gentle reminder this WGLC is still ongoing.
> 
> I (strongly:-) support publication. I do have comments but really am ok if 
> those are
> ignored.
> 
> - section 3 has a MUST for checking all IP addresses are for servers that have
> access to the relevant ECH private key material. We go into some more detail 
> on
> how to do that in [1] so perhaps some of that text ought be here, or (given 
> the
> best HOWTO may change) that could be via a reference to [1]. OTOH, that'd
> maybe be a normative ref so could delay things, so not sure how best to 
> proceed.
> (See also the "bind" comment at the end.)

I'm wary about adding a normative reference to an I-D that's not finalized yet; 
that's how we wound up with this document to begin with. In [1] you note that 
your mechanisms aren't intended to be universal, and I'm not sure that pulling 
it into this doc is required. I think the statement in Section 3 describes the 
desired state -- each IP the name might resolve to needs access to either the 
indicated key(s) or a certificate for the public name.

> - A particular case of the above is if an ECHConfigList has more than one
> ECHConfig (e.g. for different algs). I'm not sure if the text here implies 
> that all
> public values must "work" or if it means that at least one public value must
> "work."  (In publication code I've written I check all public keys and only 
> publish if
> all public keys are ok, but one could do otherwise and not suffer
> disaster:-)

I'm inclined to agree that all keys should ideally be supported by all servers 
identified by the TargetName, but being authoritative for the private name 
cures any gaps. Perhaps this needs to be more granular? MUST be authoritative 
for the public name and SHOULD have access to the private key seems reasonable 
at first glance, but is there a deployment scenario where the front-end will 
not be authoritative for the public name?

> - I'm not clear if section 3 implies a server has to check that all relevant 
> A/
> and ipv[46]hint values are present and correct before publication. (Test
> publication code I've done currently ignores hints at publication time, and 
> just
> checks one of A/ works, but I'd be ok with being more picky.)
> 
> - I think it'd be better (but not necessary) if section 3 had some guidance 
> on when
> >1 HTTPS RRdata value is reasonable or to be expected for ECH-specific 
> >reasons.
> (Basically, if one has >1 CDN I guess?)

Typically multi-CDN works by having a DNS server that issues different 
responses at different times, not by listing them all in a single RRSet. More 
likely this is if you have endpoints with different capabilities that aren't on 
the same server -- say, HTTP/2 and HTTP/3 are served off of different machines 
or at different port numbers.

> - I wonder if there's a need to consider the new happy eyeballs stuff [2] 
> before
> declaring victory here. I've no strong opinion but this and [2] probably 
> should at
> least not contradict one another.
> (I don't know if that's been checked.)

HEv3 says that ECH records should be sorted ahead of non-ECH records, but 
doesn't say anything about switching to SVCB-reliant per 4.1. We should 
probably file that feedback with HEv3, but I don't believe this document needs 
to change.

> - Does 4.1 correspond to what browsers do now with ECH? It's not clear to me
> that it does, but I'm not sure. (I'm currently writing a test generator to 
> figure that
> out but it'll be some weeks before I could answer the question myself.)
> 
> - 4.2 implies but does not say that parts of the ech= value that affect the 
> outer CH
> need to be encoded as extensions within the ECHConfigList, or else are at the
> whim of the client code. That's probably ok, but worth a bit of thought.
> (Personally, I'd prefer we disparage extensions within ECHConfigList values 
> but I
> think I've lost that argument before:-)
> 
> - 4.3 has a MUST NOT for clients - do we need to say that that means normal
> clients and not the special-case client that is needed to do checks before
> publication?

I think that seems clear enough, since the publisher isn't a "client" in this 
sense. Bu

[TLS] Re: Mike Bishop's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)

[Mike Bishop]

I was mostly looking for something like "DTLS usage is not restricted" or "This 
restriction does not apply to use in DTLS" as a separate sentence. It's the 
fact that the entry, rather than the restriction, is the subject of the current 
sentence. That's correct for the "intended for use in TLS 1.3 or later" part, 
and then gets weird when suddenly the subject is really the restriction rather 
than the entry.

That said, I'm happy to leave those updates to either of the pending updates if 
you find that preferable. This is just clarity, not a technical blocker.

From: Salz, Rich 
Sent: Friday, March 21, 2025 8:28 PM
To: Mike Bishop ; The IESG 
Cc: draft-ietf-tls-tls12-fro...@ietf.org 
; tls-cha...@ietf.org 
; tls@ietf.org ; s...@sn3rd.com 

Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-tls12-frozen-06: 
(with COMMENT)


The registry note "Any entry [...] makes no requirement on DTLS" does not seem
correct. Consider rewording this to indicate that the *notation* does not
impact DTLS, or consider adding separate explicit columns for TLS and DTLS
version restrictions.

Thanks for the review. That sentence is clunky and hard to understand (my 
fault) but I think it’s correct. The intent is that if the comment says “For 
TLS 1.3 or later” it only applies to TLS and says nothing about DTLS (which is 
spelled out in the note).  We’ve managed to not have DTLS comment fields so 
far, and the TLS registries are about to get an update. Also we’re just 
starting on a DTLS 1.3bis doc to fix bugs that have been found.

So I am not planning on doing anything for this.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT)

[Mike Bishop]

Sorry, I should have quoted it. It's 
https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#section-4.1.3-11 in 
the editor's copy:

[RFC8996<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#RFC8996>] 
and Appendix 
E.5<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#backward-compatibility-security>
 forbid the negotiation of TLS versions below 1.2. However, server 
implementations which do not follow that guidance MUST set the last 8 bytes of 
their ServerHello.random value to the bytes:

  44 4F 57 4E 47 52 44 00

Appendix E.5 states that versions below 1.2 "MUST NOT be negotiated for any 
reason," yet this text then has a MUST-level requirement applying exclusively 
to server implementations which ignore the MUST NOT.

From: Eric Rescorla 
Sent: Friday, May 30, 2025 10:54 AM
To: Mike Bishop 
Cc: The IESG ; draft-ietf-tls-rfc8446...@ietf.org 
; tls-cha...@ietf.org 
; tls@ietf.org ; s...@sn3rd.com 

Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with 
COMMENT)

Thank you for comments. I have made a PR to address most of these comments:

https://github.com/tlswg/tls13-spec/pull/1385

I am a bit unsure about one comment. Can you point to the offending text for the
comment below:


The language around the SCSV for pre-1.2 values feels odd. You MUST NOT
negotiate older versions, but if you do anyway, you MUST do it this way? I
would shift this to a description of how clients and servers were required to
behave prior to this revision of 1.3 at most.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT)

[Mike Bishop]

From a real-world perspective, I agree — if servers choose to negotiate 
deprecated protocols, they should at least use the anti-downgrade mechanisms 
we've built. In terms of spec consistency, it feels very odd to have 2119 
requirements that only apply if you choose to violate the requirements we've 
already stated. So it's a 6919-esque MUST NOT (BUT WE KNOW YOU WILL).

RFC8996 acknowledges that there will be a delay between publication of the BCP 
and implementation of the deprecation in the real world; "Adopting the 
practices recommended by this document for any systems that need to communicate 
with the aforementioned class of systems will cause failure to interoperate. 
[Consider the trade-off] when deciding how quickly to adopt the recommendations 
specified in this document." I can certainly understand making a similar 
acknowledgement here, but perhaps stronger language warning such 
implementations that they're straying off the beaten path is useful.

Regardless, this is a non-blocking comment, and I'll defer to you, the WG, and 
the responsible AD on exactly how to balance this.

From: Eric Rescorla 
Sent: Monday, June 2, 2025 11:35 AM
To: Mike Bishop 
Cc: The IESG ; draft-ietf-tls-rfc8446...@ietf.org 
; tls-cha...@ietf.org 
; tls@ietf.org ; s...@sn3rd.com 

Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with 
COMMENT)

Thanks.

It might help to start with some background. While it's true that the IETF
has deprecated TLS versions prior to TLS 1.2, we also know that there
are many sites which support TLS 1.0 and TLS 1.1. [0]

We would still like those implementations to perform anti-downgrade, despite
violating this other MUST. So, I don't think that treating this as a historical
requirement is the right answer.

-Ekr


[0] https://www.ssllabs.com/ssl-pulse/





On Mon, Jun 2, 2025 at 7:40 AM Mike Bishop 
mailto:mbis...@evequefou.be>> wrote:
Sorry, I should have quoted it. It's 
https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#section-4.1.3-11 in 
the editor's copy:

[RFC8996<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#RFC8996>] 
and Appendix 
E.5<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#backward-compatibility-security>
 forbid the negotiation of TLS versions below 1.2. However, server 
implementations which do not follow that guidance MUST set the last 8 bytes of 
their ServerHello.random value to the bytes:

  44 4F 57 4E 47 52 44 00

Appendix E.5 states that versions below 1.2 "MUST NOT be negotiated for any 
reason," yet this text then has a MUST-level requirement applying exclusively 
to server implementations which ignore the MUST NOT.

From: Eric Rescorla mailto:e...@rtfm.com>>
Sent: Friday, May 30, 2025 10:54 AM
To: Mike Bishop mailto:mbis...@evequefou.be>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-tls-rfc8446...@ietf.org<mailto:draft-ietf-tls-rfc8446...@ietf.org> 
mailto:draft-ietf-tls-rfc8446...@ietf.org>>;
 tls-cha...@ietf.org<mailto:tls-cha...@ietf.org> 
mailto:tls-cha...@ietf.org>>; 
tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>; 
s...@sn3rd.com<mailto:s...@sn3rd.com> mailto:s...@sn3rd.com>>
Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with 
COMMENT)

Thank you for comments. I have made a PR to address most of these comments:

https://github.com/tlswg/tls13-spec/pull/1385

I am a bit unsure about one comment. Can you point to the offending text for the
comment below:


The language around the SCSV for pre-1.2 values feels odd. You MUST NOT
negotiate older versions, but if you do anyway, you MUST do it this way? I
would shift this to a description of how clients and servers were required to
behave prior to this revision of 1.3 at most.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8447bis-13: (with COMMENT)

[Mike Bishop]

Yes, I was suggesting a link to each registry in addition to its name. Not 
critical, but a convenience for readers.

From: Sean Turner 
Sent: Wednesday, June 4, 2025 12:13 PM
To: Mike Bishop 
Cc: The IESG ; draft-ietf-tls-rfc8447...@ietf.org 
; TLS Chairs ; TLS 
List ; Deirdre Connolly 
Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8447bis-13: (with 
COMMENT)



On Jun 3, 2025, at 14:11, Mike Bishop via Datatracker  wrote:

Mike Bishop has entered the following ballot position for
draft-ietf-tls-rfc8447bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/



--
COMMENT:
--

Thanks for your work on this. I think this will make the distinction between
"types" of N clearer in the TLS registries. Two minor suggestions:

First, pointers to the IANA registries in each section would be appreciated.

I did that via the headings ;) or, do you mean like a hyperlink / reference?

Second, the abstract asserts that "This document updates the following RFCs:
3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447." However, the header
states only that it updates RFC8447. I suspect the logic is that this document
is updating the updates made by 8447, so that the "updated" 8447 makes
different changes to the older documents. That seems needlessly complex; the
header should reflect the documents to which this will make changes in practice.

drat: I changed the header but forgot to update the abstract. Fixed via:
https://github.com/tlswg/rfc8447bis/pull/87

spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Mike Bishop's Yes on draft-ietf-tls-keylogfile-04: (with COMMENT)

[Mike Bishop]

The Abstract begins "A format that supports the logging information about the 
secrets used in a TLS connection is described." I was suggesting that this 
should read either "A format that supports logging information about the 
secrets used in a TLS connection is described." or "A format that supports the 
logging of information about the secrets used in a TLS connection is described."

Yes, all nits, as I said. The PR looks good.

From: Martin Thomson 
Sent: Wednesday, June 4, 2025 8:45 PM
To: Mike Bishop ; The IESG 
Cc: draft-ietf-tls-keylogf...@ietf.org ; 
tls-chairs ; tls@ietf.org ; Sean Turner 

Subject: Re: Mike Bishop's Yes on draft-ietf-tls-keylogfile-04: (with COMMENT)

Thanks Mike,

On Thu, Jun 5, 2025, at 05:39, Mike Bishop via Datatracker wrote:
> Mike Bishop has entered the following ballot position for
> draft-ietf-tls-keylogfile-04: Yes

See https://github.com/tlswg/sslkeylogfile/pull/31

I couldn't find the abstract text you quoted, but the rest saved the RFC editor 
some work, I suspect.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS and COMMENT)

[Mike Bishop]

Inline with [MB]


From: Thomas Fossati 
Sent: Tuesday, June 24, 2025 9:59 AM
To: Mike Bishop 
Cc: The IESG ; draft-ietf-tls-dtls-...@ietf.org 
; tls-cha...@ietf.org ; 
tls@ietf.org ; s...@sn3rd.com 
Subject: Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS 
and COMMENT)

Hi Mike, thanks for the thorough review and suggestions!

On Mon, 23 Jun 2025 at 18:03, Mike Bishop via Datatracker
 wrote:
> --
> DISCUSS:
> --
>
> The RFC 9000 reference is currently informative, used to support the 
> definition
> of the term "anti-amplification limit" in Section 2. However, conformance with
> this limit is normatively required in Section 6. Please rephrase Section 2 to
> include the full definition in this document that is required to understand 
> the
> normative requirement; RFC 9000 can optionally be retained as an informative
> reference to a parallel usage, as done in Section 5.  (Alternatively, you 
> could
> make the RFC 9000 reference normative, but I don't think that's necessary.)

Sorry, I am unclear about what you mean by "rephras[ing] Section 2 to
include the full definition in this document that is required to
understand the normative requirement."

In §2, we say that we "reuse the definition of anti-amplification
limit from [RFC9000] to mean three times the amount of data received
from an unvalidated address. This includes all DTLS records
originating from that source address, excluding discarded ones."

What is missing that would prevent understanding the requirement in
§6, where we say that "the receiver [...] MUST stop sending any
buffered application data, or limit the data sent to the unvalidated
address to the anti-amplification limit"?

[MB] If that's a full definition, then rephrasing it to be clear the reference 
doesn't contain additional necessary detail should be sufficient. Something 
like:

CURRENT:
This document reuses the definition of "anti-amplification limit" from 
[RFC9000<https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-17.html#RFC9000>]
 to mean three times the amount of data received from an unvalidated address. 
This includes all DTLS records originating from that source address, excluding 
discarded ones.

CONSIDER:
The "anti-amplification limit" means three times the amount of data received 
from an unvalidated address. The received data includes all DTLS records 
originating from that source address, excluding discarded ones. This follows 
the pattern of 
[RFC9000<https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-17.html#RFC9000>],
 applying a similar concept to DTLS.

However, in that case, you might consider simply putting the definition at the 
place it's normatively used. Note that RFC9000 doesn't define the term in its 
Terms and Definitions section, but directly in Section 8, Address Validation:

The primary defense against amplification attacks is verifying that a peer is 
able to receive packets at the transport address that it claims. Therefore, 
after receiving packets from an address that is not yet validated, an endpoint 
MUST limit the amount of data it sends to the unvalidated address to three 
times the amount of data received from that address. This limit on the size of 
responses is known as the anti-amplification limit.

(I also note that "excluding discarded ones" is stricter than RFC9000's usage, 
where any datagram received counts even if it's not usable, IIRC.)

> --
> COMMENT:
> --
>
> Section 5.2.1 should describe in more detail that the case where "it is not
> possible to distinguish between an attack and an improvement in routing" will
> look different from the viewpoint of Sender and Receiver. Because the attacker
> is duplicating the Sender's packets from the old address to the new address,
> the Sender would see the RRC message as a re-validation for the current path
> and would generate a path-response, believing it is doing what Figure 6
> illustrates. However, the attacker will forward this path-response to the
> Receiver; if it wins the race (or can cause packet loss on the old path), the
> Receiver will see the path-response message arrive from the new address, not
> the old.

True, but is that essential to the comprehension?  Anyway, if you
really think it's important to make it explicit, we'll try to add a
paragraph to capture the essence.

[MB] I think it leads into why the restriction on generating path_drop is 
needed. Your call on how much detail to explain around 

[TLS] Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS and COMMENT)

[Mike Bishop]

Diffs look good; I'm fine to clear the DISCUSS once a draft has those changes.

I do still encourage you to explicitly name the registry you're requesting IANA 
create in 11.3.

Thanks,
Mike


From: Thomas Fossati 
Sent: Wednesday, June 25, 2025 3:56 AM
To: Mike Bishop 
Cc: The IESG ; draft-ietf-tls-dtls-...@ietf.org 
; tls-cha...@ietf.org ; 
tls@ietf.org ; s...@sn3rd.com 
Subject: Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS 
and COMMENT)

Hi Mike,

See some replies inline below, and the diff here [1]

[1] 
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-dtls-rrc&url_2=https://tlswg.github.io/dtls-rrc/mike/draft-ietf-tls-dtls-rrc.txt

Cheers & thank you!

On Tue, 24 Jun 2025 at 21:59, Mike Bishop  wrote:
>
> Inline with [MB]
>
> 
> From: Thomas Fossati 
> Sent: Tuesday, June 24, 2025 9:59 AM
> To: Mike Bishop 
> Cc: The IESG ; draft-ietf-tls-dtls-...@ietf.org 
> ; tls-cha...@ietf.org 
> ; tls@ietf.org ; s...@sn3rd.com 
> 
> Subject: Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with 
> DISCUSS and COMMENT)
>
> Hi Mike, thanks for the thorough review and suggestions!
>
> On Mon, 23 Jun 2025 at 18:03, Mike Bishop via Datatracker
>  wrote:
> > --
> > DISCUSS:
> > --
> >
> > The RFC 9000 reference is currently informative, used to support the 
> > definition
> > of the term "anti-amplification limit" in Section 2. However, conformance 
> > with
> > this limit is normatively required in Section 6. Please rephrase Section 2 
> > to
> > include the full definition in this document that is required to understand 
> > the
> > normative requirement; RFC 9000 can optionally be retained as an informative
> > reference to a parallel usage, as done in Section 5.  (Alternatively, you 
> > could
> > make the RFC 9000 reference normative, but I don't think that's necessary.)
>
> Sorry, I am unclear about what you mean by "rephras[ing] Section 2 to
> include the full definition in this document that is required to
> understand the normative requirement."
>
> In §2, we say that we "reuse the definition of anti-amplification
> limit from [RFC9000] to mean three times the amount of data received
> from an unvalidated address. This includes all DTLS records
> originating from that source address, excluding discarded ones."
>
> What is missing that would prevent understanding the requirement in
> §6, where we say that "the receiver [...] MUST stop sending any
> buffered application data, or limit the data sent to the unvalidated
> address to the anti-amplification limit"?
>
> [MB] If that's a full definition, then rephrasing it to be clear the 
> reference doesn't contain additional necessary detail should be sufficient. 
> Something like:
>
> CURRENT:
> This document reuses the definition of "anti-amplification limit" from 
> [RFC9000] to mean three times the amount of data received from an unvalidated 
> address. This includes all DTLS records originating from that source address, 
> excluding discarded ones.
>
> CONSIDER:
> The "anti-amplification limit" means three times the amount of data received 
> from an unvalidated address. The received data includes all DTLS records 
> originating from that source address, excluding discarded ones. This follows 
> the pattern of [RFC9000], applying a similar concept to DTLS.

Looks great, thanks!

> However, in that case, you might consider simply putting the definition at 
> the place it's normatively used. Note that RFC9000 doesn't define the term in 
> its Terms and Definitions section, but directly in Section 8, Address 
> Validation:
>
> The primary defense against amplification attacks is verifying that a peer is 
> able to receive packets at the transport address that it claims. Therefore, 
> after receiving packets from an address that is not yet validated, an 
> endpoint MUST limit the amount of data it sends to the unvalidated address to 
> three times the amount of data received from that address. This limit on the 
> size of responses is known as the anti-amplification limit.

It would be perfect if that were the only instance of the term being
used, but since 'anti-amplification limit' is also used elsewhere
(twice in §6.3), I think it's better to factor it out.

> (I also note that "excluding discarded ones" is stricter than RFC9000's 
> usage, where any datagram received counts even if it

[TLS] Mike Bishop's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-tls12-frozen-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/



--
COMMENT:
--

The registry note "Any entry [...] makes no requirement on DTLS" does not seem
correct. Consider rewording this to indicate that the *notation* does not
impact DTLS, or consider adding separate explicit columns for TLS and DTLS
version restrictions.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's No Objection on draft-ietf-tls-esni-24: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-esni-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/



--
COMMENT:
--

I've previously reviewed this document and have very few additional comments;
these comments can be incorporated or ignored at the authors' and responsible
AD's discretion.

6.1.8: "has been forced to change" imputes external events that aren't relevant
to the protocol. The server's configuration may have changed since the client
received the retry configs; the client doesn't need to speculate on why.

10.9 notes that there's no collision between ECH acceptance (in 1.3) and
downgrade protection (in <1.3) because of the version scoping. It's worth
noting, however, that this forecloses using the same approach to guard against
downgrades to 1.3 from future TLS versions.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-rfc8446bis-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/



--
COMMENT:
--

Thanks for this clean and well-written revision. I have only a few minor
observations which can be incorporated at the discretion of the author and the
responsible AD:
===

In the list of diffs, one of the bullets appears to be two changes. Should
these be separate bullets, or should a sentence be added before these two
explaining how they're connected?

>Restore text defining the level of "close_notify" to "warning".
>Clarify behavior around "user_canceled", requiring that
>"close_notify" be sent and that "user_canceled" should be ignored.

===

The language around the SCSV for pre-1.2 values feels odd. You MUST NOT
negotiate older versions, but if you do anyway, you MUST do it this way? I
would shift this to a description of how clients and servers were required to
behave prior to this revision of 1.3 at most.

===

CURRENT: select a group based "supported_groups"

CONSIDER: select a group based on "supported_groups"

===

OLD: For X25519 and X448, the contents of the public value are the byte string
inputs and outputs of the corresponding functions

CURRENT: For X25519 and X448, the contents of the public value is the K_A or
K_B value

CONSIDER: For X25519 and X448, the content of the public value is the K_A or
K_B value



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS and COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-dtls-rrc-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/



--
DISCUSS:
--

The RFC 9000 reference is currently informative, used to support the definition
of the term "anti-amplification limit" in Section 2. However, conformance with
this limit is normatively required in Section 6. Please rephrase Section 2 to
include the full definition in this document that is required to understand the
normative requirement; RFC 9000 can optionally be retained as an informative
reference to a parallel usage, as done in Section 5.  (Alternatively, you could
make the RFC 9000 reference normative, but I don't think that's necessary.)


--
COMMENT:
--

Section 5.2.1 should describe in more detail that the case where "it is not
possible to distinguish between an attack and an improvement in routing" will
look different from the viewpoint of Sender and Receiver. Because the attacker
is duplicating the Sender's packets from the old address to the new address,
the Sender would see the RRC message as a re-validation for the current path
and would generate a path-response, believing it is doing what Figure 6
illustrates. However, the attacker will forward this path-response to the
Receiver; if it wins the race (or can cause packet loss on the old path), the
Receiver will see the path-response message arrive from the new address, not
the old.

The behavior as defined in Section 6.2 addresses this by preventing a switch on
receipt of a path_response without regard to the path on which it actually
arrived. However, if the attacker is able to elicit a response of type
path_drop to a given path_challenge, for example by injecting a modified copy
of the path_challenge, that can be used to spoof dropping the challenged older
path. This may need an additional branch in 6.2 step 3, prohibiting any
response if the path where the message was received has never been a preferred
path.

In 10.1, consider advising that implementations log when responses to a single
path_challenge are received, as this could also be suggestive of an attempt at
the above attack.

In 11.2, why is this extension not Recommended for implementations to support?
That would seem to say that it either "has not been through the IETF consensus
process, has limited applicability, or is intended only for specific use
cases." While the applicability is limited to DTLS, that is already
communicated by the DTLS-Only column.

In 11.3, please fully specify the name of the requested registry. Also, why is
a DTLS-Only column needed in a registry which contains messages within a
sub-protocol which only exists in DTLS? This restriction could be communicated
with a note on the registry or in the title of the registry (e.g. "DTLS Return
Routability Check Message Types"). (Obviously retain it if there is future work
to support RRC outside of DTLS which will share this registry.)

=== NITS FOLLOW ===

- Section 3.1, "application layer specific" => "application-specific" or
"application-layer" should be sufficient

- Figure 7, '*' appears in the key but nowhere in the figure. I assume this is
copied from other similar figures which use it, but it can be omitted here.

- Section 7, "our" => "this"

- Section 11.1, "entry to" => "entry in"; remove comma after "registry"



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's No Objection on draft-ietf-tls-dtls-rrc-18: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-dtls-rrc-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/



--
COMMENT:
--

Thank you for addressing my previous DISCUSS and COMMENTs [1].

1 - https://mailarchive.ietf.org/arch/msg/tls/SpdzidiIh2IBCmuNLp7bihX_zAQ/



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's No Objection on draft-ietf-tls-rfc8447bis-13: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-rfc8447bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/



--
COMMENT:
--

Thanks for your work on this. I think this will make the distinction between
"types" of N clearer in the TLS registries. Two minor suggestions:

First, pointers to the IANA registries in each section would be appreciated.

Second, the abstract asserts that "This document updates the following RFCs:
3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447." However, the header
states only that it updates RFC8447. I suspect the logic is that this document
is updating the updates made by 8447, so that the "updated" 8447 makes
different changes to the older documents. That seems needlessly complex; the
header should reflect the documents to which this will make changes in practice.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's Yes on draft-ietf-tls-keylogfile-04: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-keylogfile-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/



--
COMMENT:
--

Thanks for the work to document this widely used de facto standard. My only
comments are minor, and mostly nits.

In Section 2, "Including this field allows..." sounds like an argument for
including it, but it's not an optional field. Consider a more declarative
phrasing, such as "This field is used to correlate..."

===NITS FOLLOW===

Abstract, "supports the logging information" => "supports logging information"
or "supports the logging of information" Section 2.2, "An implementation ...
use" => "An implementation ... uses" or "Implementations ... use" Section 4.2,
"in depth" => "in-depth"



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Mike Bishop's No Objection on draft-ietf-tls-deprecate-obsolete-kex-06: (with COMMENT)

[Mike Bishop via Datatracker]

Mike Bishop has entered the following ballot position for
draft-ietf-tls-deprecate-obsolete-kex-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/



--
COMMENT:
--

I don't see that this document explicitly states the updates made to RFCs 4346,
5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487,
6655, and 7905 "to remediate the above problems." Presumably the cipher suites
in question are removed from some list or requirements on acceptable cipher
suites are amended; please state the changes explicitly.

===NITS FOLLOW===
- Section 5, s/registry/registry/



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org