Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Steven Valdez]

We might also want to mark 40 similarly given the ExtendedRandom collision
that caused issues with key_share.

On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk  wrote:

> I think there's also some room to just mark 26 as "Reserved - unauthorized
> use has rendered this value unsuitable for official allocation".
>
> -Ben
>
> On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote:
> > Based on this, I propose that IANA allocates a new !26 Early Data code
> > point for compressed certificates (that's mechanical).
> >
> > As noted earlier, it's premature for TLS-LTS to request a code point
> > because the enabling document has not yet been published, so we can defer
> > the question of its use of 26 for a bit.
> >
> > The QUIC TLS extension should also change to a new code point, but I'm
> not
> > sure it meets the criteria for an early code point assignment. MT
> proposed
> > just squatting on a random code point. Having a really unique code point
> is
> > less important here because this extension will only appear inside of
> QUIC
> > and not on ordinarily TLS connections, though of course it must have a
> > unique code point from other extensions used with QUIC. So it's not
> > entirely clear how best to handle this,
> >
> > -Ekr
> >
> >
> > On Thu, May 31, 2018 at 7:42 AM, David Benjamin 
> > wrote:
> >
> > > I probed a bunch of servers yesterday and found evidence of yet another
> > > collision at 26! It's possible these are TLS-LTS implementations, but
> a lot
> > > of them additionally only support RSA decryption ciphers, which makes
> this
> > > seem unlikely. These servers do not appear to do anything with the
> > > extension, as far as I could tell, including even echoing it back, but
> > > they  send decode_error if the extension includes a non-empty body.
> (It's
> > > possible their TLS implementation supports TLS-LTS, unconditionally
> parses
> > > the extension, but does not actually enable it by default.)
> > >
> > > I didn't repeat the probe with 27, but playing with a couple of the
> > > servers showed they tolerate other numbers fine, including 27. It's
> just
> > > that they appear to have squatted on 26 for something.
> > >
> > > It's frustrating that allocating code points is complicated, but given
> the
> > > other deployment problems TLS has seen lately, were this the worst of
> our
> > > problems, I would be quite happy.
> > >
> > > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey 
> wrote:
> > >
> > >> I agree we should use a different number than 26 for certificate
> > >> compression.  I don't see a problem with assigning 27 and reserving
> 26 for
> > >> now.
> > >>
> > >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley  >
> > >> wrote:
> > >>
> > >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton 
> > >>> wrote:
> > >>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> > >>> > working group for their smart locks last year. I have no idea how
> much
> > >>> > of the code they are going to reuse (if any at all).
> > >>>
> > >>> Chrome / Google is blocked on code-point assignment for deploying
> > >>> certificate compression. It appears that 26 is not a good pick and we
> > >>> thus wait in anticipation for a replacement.
> > >>>
> > >>> (The extensions space is effectively infinite: if we get close to
> > >>> running out, we can assign an "extended extensions" code point, which
> > >>> would contain a nested extensions block with 32-bit numbers instead.
> > >>> Therefore effort and delays resulting from treating it as a scarce
> > >>> resource are saddening. Speaking in a personal capacity, it looks
> like
> > >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
> > >>> randomly to avoid issues with concurrent applications and I offer
> > >>> 0xbb31 as a high-quality, random number. Since we had a triple
> > >>> collision in this case, random-assignment's virtues are currently
> > >>> particularly clear.)
> > >>>
> > >>> --
> > >>> Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
> > >>>
> > >>
> > >> ___
> > >> 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
>


-- 

Steven Valdez |  Chrome Networking |  sval...@google.com |  210-692-4742
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing Protocol Invariants

[Steven Valdez]

This scheme probably isn't sufficient by itself, since a middlebox just has
to be aware of the anti-ossification extension and can parse the server's
response by decrypting it with the known mapping (either from the RFC or
fetching the latest updated mapping), and then ossifying on the contents of
the 'real' ServerHello. To keep the ServerHello from ossifying, you'll need
to change the serialization and codepoints of the ServerHello at each
rolling version.

On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekritz  wrote:

> I think there may be lower overhead ways (that don’t require frequent TLS
> library code changes) to prevent ossification of the ServerHello using a
> mechanism similar to the cleartext cipher in quic. For example, a client
> could offer an “anti-ossification” extension containing an identifier that
> corresponds to a particular key. The identifier->key mapping can be
> established using a couple of mechanisms, depending on the level of defense
> desired against implementations that know about this extension:
> * static mapping defined in RFC
> * periodically updated mapping shared among implementations
> * negotiated on a previous connection to the server, similar to a PSK
> This key can then be used to “encrypt” the ServerHello such that it is
> impossible for a middlebox without the key to read (though would not add
> actual confidentiality and would probably involve aead nonce-reuse).
> There’s a couple of options to do this:
> * Simply replace the plaintext record layer for the ServerHello with an
> encrypted record layer, using this key (this would not be compatible with
> existing middleboxes that have caused us trouble)
> * Put a “real” encrypted ServerHello in an extension in the “outer”
> plaintext ServerHello
> * Send a fake ServerHello (similar to how we encapsulate HelloRetryRequest
> in a ServerHello), and then send a real ServerHello in a following
> encrypted record
> All of these would allow a server to either use this mechanism or
> negotiate standard TLS 1.3 (and the client to easily tell which one is in
> use).
>
> With the small exception of potentially updating the identifier->key
> mapping, this would not require any TLS library changes (once implemented
> in the first place), and I believe would still provide almost all of the
> benefits.
>
> *From:* TLS  *On Behalf Of *David Benjamin
> *Sent:* Tuesday, June 12, 2018 12:28 PM
> *To:*  
> *Subject:* [TLS] Enforcing Protocol Invariants
>
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the
> ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else’s ServerHellos,
> so the protocol was further hacked to weave through their many defects.
>
> I think I can speak for the working group that we do not want to repeat
> this adventure again. In general, I think the response to ossification is
> two-fold:
>
> 1. It’s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
>
> The workarounds only answer the first question. For the second, TLS 1.3
> has a section which spells out a few *protocol invariants*
> .
> It is all corollaries of existing TLS specification text, but hopefully
> documenting it explicitly will help. But experience has shown specification
> text is only necessary, not sufficient.
>
> For extensibility problems in servers, we have *GREASE*
> .
> This enforces the key rule in ClientHello processing: ignore unrecognized
> parameters. GREASE enforces this by filling the ecosystem with them. TLS
> 1.3’s middlebox woes were different. The key rule is: if you did not
> produce a ClientHello, you cannot assume that you can parse the response.
> Analogously, we should fill the ecosystem with such responses. We have an
> idea, but it is more involved than GREASE, so we are very interested in the
> TLS community’s feedback.
>
> In short, we plan to regularly mint new TLS versions (and likely other
> sensitive parameters such as extensions), roughly every six weeks matching
> Chrome’s release cycle. Chrome, Google servers, and any other deployment
> that wishes to participate, would support two (or more) vers

Re: [TLS] TLSv1.3 - purpose of _0 in {client, server}_application_traffic_secret_0

[Steven Valdez]

They indicate that those are the initial client/server application traffic
secrets, which are then updated via KeyUpdates (section 7.2,
https://tools.ietf.org/html/draft-ietf-tls-tls13#section-7.2).

On Tue, Apr 2, 2019 at 12:20 PM M K Saravanan  wrote:

> Hi,
>
> In TLSv1.3, what is the purpose of _0 suffix in the following:
>
> client_application_traffic_secret_0
> server_application_traffic_secret_0
>
> with regards,
> Saravanan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Steven Valdez |  Chrome Networking |  sval...@google.com |  210-692-4742
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Steven Valdez]

Maintaining my hum from the meeting, I prefer keeping TLS 1.3 over
renaming, primarily because there's now a good amount of
documentation/implementation in the wild that refers to TLS 1.3, and we'll
need to keep around the new equivalence of TLS 2 (or 4)=TLS 1.3.


On Sat, Nov 19, 2016, 8:31 AM Ira McDonald  wrote:

> Hi,
>
> I think that the presumption that most tech people (or even security
> people)
> won't have any trouble with the future version numbering of TLS is wrong.
>
> Yesterday morning, on an SAE Vehicle Electrical Systems Security call with
> some 40 auto security professionals present, I mentioned that TLS 1.3 was
> wrapping up and was asked "What's TLS?"  Usual explanation about SSL
> being succeeded by IETF TLS 17 years ago.  Several responses that were
> the equivalent of blank stares.  And finally, "Then why is the library
> still
> called OpenSSL?"
>
> Rich has highlighted that the tech community goes right on conflating SSL
> with TLS on web sites.
>
> I change my two cents to "TLS 4" but am unsure about "4" or "4.0" because
> the tech community has been trained to care about major.minor.
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmu...@gmail.com
> Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
> May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
> On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Walton 
> wrote:
>
> On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner  wrote:
> > At IETF 97, the chairs lead a discussion to resolve whether the WG
> should rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf
> .
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to
> not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this
> decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.
>
> Please forgive my ignorance...
>
> Who are you targeting for the versioning scheme? Regular users? Mom
> and pop shops with a web presence? Tech guys and gals? Security folks?
>
> For most tech people and security folks, I don't think it matters
> much. However, how many regular users would have clung to SSLv3 and
> TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
> TLS 1999 (given TLS 2008 or TLS 2010 was available)?
>
> (Sorry to violate the Hum restriction).
>
> Jeff
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

[Steven Valdez]

Being able to send supported_groups does allow a server to choose to make a
tradeoff between an extra round trip on the current connection and its own
group preferences. One example where a server might want to do this is
where it believes that X25519 is likely a more future-proof group and would
prefer that, but still believes the client's choice of P256 is suitable for
this connection. Always requiring an extra round trip might end up being
expensive depending on the situation so some servers might prefer to avoid
sending an HRR for a slightly more preferred group.

I think that requiring the client to maintain state from the
supported_groups puts undue requirements on the client, since not all
clients keep state between connections, and those that do usually only keep
session state for resumption.

On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = HRR and supported groups cache =
>
> In 4.2.4 (P.41), a server can send a supported_groups extension to
> "update the client's view of its preference" in its ServerHello.
> Since this behaviour is completely left to the client's discretion, it
> does not seem a very relevant policy from the server: either the
> server accepts one of the proposed groups, or it sends an HRR.  We do
> not think the middle ground (OK for this group, but I would prefer
> this other one) is relevant, so the sentence should be removed.
>
> Moreover, as far as I could understand, there is no indication in the
> specification that a client should remember the preference of the
> server in case it receives a HRR, which there would definitely make
> sense.  Such text could go in 4.1.4.
>
> I can propose a PR for this point.
>
>
> Olivier Levillain
>
> ___
> 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: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Steven Valdez]

On Fri, Jul 26, 2024 at 3:25 AM Bob Beck 
wrote:

>
>
> On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho  40zscaler@dmarc.ietf.org> wrote:
>
>> Thank you for the feedback, Andrei.
>>
>> Yes, it is intended to stay on the informational track as an extension
>> to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the
>> keylogfile draft - for instance in the applicability statement it is worded
>> that "this mechanism MUST NOT be used in a production system". Happy to add
>> stronger wording if that helps.
>>
>
> No matter what your opinion on standardizing SSLKEYLOGFILE,
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not
> contain this MUST NOT guidance as in this draft.
>
> This guidance does appear to be included in the base draft under "1.1
Applicability Statement".


> MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality
> that is not present for the rest of specification calls into question how
> an application developer shipping SSLKEYLOGFILE functionality in an
> application is supposed to follow this guidance. Is only this portion of
> the functionality supposed to be removed in "production"
>
> It seems to me like if this is what the IETF wants to advise, This advice
> is being given in the wrong draft.
>
> -Bob
>
>
>>
>> The ultimate goal is to simplify adoption of ECH for both developers of
>> TLS software and implementers. Without a standard approach to
>> troubleshooting every developer has to build an individual set of bespoke
>> troubleshooting tools. Ability to inspect ECH negotiation in off the shelf
>> tools such as Wireshark during development or tests would significantly
>> help adoption.
>>
>>
>> Best Regards,
>> Yaroslav
>>
>> On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov > 40microsoft@dmarc.ietf.org> wrote:
>>
>>> I do not support adoption, because I believe the IETF should not
>>> standardize tools and techniques for decrypting TLS-protected data.
>>> It is harder for a TLS implementer to reject requests for IETF-blessed
>>> functionality.
>>>
>>> (As long as this remains on the Informational track, I believe it's
>>> somewhat less harmful.)
>>>
>>> Cheers,
>>>
>>> Andrei
>>>
>>> -Original Message-
>>> From: Sean Turner 
>>> Sent: Thursday, July 25, 2024 9:16 AM
>>> To: TLS List 
>>> Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file for
>>> ECH
>>>
>>> At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG
>>> Extension file for ECH I-D (
>>> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/).
>>> This message starts a two-weekl call for adoption. 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 8 August 2024.
>>>
>>> Thanks,
>>> Sean
>>> ___
>>> 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 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
>


-- 

 Steven Valdez |  Chrome Privacy Sandbox |  sval...@google.com |  Cambridge,
MA
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org