Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Yoav Nir]

> On 8 Nov 2023, at 8:34, Loganaden Velvindron  wrote:
> 
> I support moving forward with hybrids as a proactively safe deployment
> option. I think that supporting
> only Kyber for KEX  is not enough. It would make sense to have more options.
> 
> Google uses NTRU HRSS internally:
> https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms
> 
> If Google decides to use this externally, how easy would it be to get
> a codepoint for TLS ?

As easy as writing it up in a stable document (may or may not be an 
Internet-draft) and asking IANA for a code point assignment.

It can be done in days, if needed.

Yoav

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

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Yoav Nir]

For signatures or keys in something like a certificate, I understand how you 
would want to have both the PQ and classical keys/sigs in the same structure, 
so satisfy those who want the classical algorithm and those who prefer the 
post-quantum.

For key exchange? For the most part a negotiation is good enough, no?  To 
justify a hybrid key exchange you need people who are both worried about 
quantum computers and worried about cryptanalysis or the new algorithms, but 
are willing to bet that those things won’t happen at the same time. Or at 
least, within the time where the generated key still matters.

I’m sure it’s not an empty set of people, but is it sizable?


> On 7 Nov 2023, at 10:29, Scott Fluhrer (sfluhrer) 
>  wrote:
> 
> The problem with the argument “X trusts Kyber, so we don’t need hybrid” 
> (where X can be “NIST” or “the speaker”) is that trust, like beauty, is in 
> the eye of the beholder.  Just because NIST (or any other third party) is 
> comfortable with just using Kyber (or Dilithium) does not mean that everyone 
> does.
>  
> As long as there are a number of users that don’t quite trust fairly new 
> algorithms, there will be a valid demand for using those new algorithms with 
> older ones (which aren’t postquantum, but we are moderately confident that 
> are resistant to conventional cryptanalysis).
>  
> From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
> Watson Ladd
> Sent: Monday, November 6, 2023 2:44 PM
> To: Kris Kwiatkowski mailto:k...@amongbytes.com>>
> Cc: Bas Westerbaan  >; TLS List  >
> Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
>  
> Why do we need FIPS hybrids? The argument for hybrids is that we don't trust 
> the code/algorithms that's new. FIPS certification supposedly removes that 
> concern so can just use the approved PQ implementation.
>  
> ___
> 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] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

[Yoav Nir]

> On 7 Nov 2023, at 0:29, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Do we want rfc describing the final NIST standards? And for which? I'm ok 
> with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
>  
> Probably yes, and in the order you described.

Sure, as long as by “describe” we mean “reference”.  NIST do a great job of 
describing algorithms. We don’t need to replicate that effort, only to show 
encoding in a particular protocol and choose when several options are available.
 
> For which algorithms do we want to assign codepoints once the NIST standards 
> are out? Codepoints are cheap and use cases/rules are different, but 
> especially with the hybrids, I'd encourage us to try to be disciplined and 
> keep the list as short as we can for now, so that early adopters for which it 
> doesn't matter, all choose the same thing. The DNS mechanism of 
> draft-davidben-tls-key-share-prediction helps on the performance side, but it 
> doesn't solve the duplicate engineering/validation if there are a dozen 
> essentially equivalent KEMs.
>  
> Leaving this question alone, at least for now.
>  
> Do we want to standardise non-hybrid KEMs for TLS? I don't care for them yet, 
> but others might.
>  
> Absolutely yes.

Yes. They're that end goal mentioned upthread. 

> Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
> could be convinced otherwise.
>  
> I don’t need/want them, but can’t/won’t forbid others from using them. They 
> still don’t make sense to me.

Signatures generally follow from what’s in the certificate. So if certificates 
are going to have hybrid keys, it makes sense for the protocol to have hybrid 
signatures.
It’s still an open question if certificates are going to have hybrid keys. 
LAMPS has not spoken beyond not adopting a draft.

> What is the future of AuthKEM? That's definitely a different e-mail thread.
>  
> I hope it becomes a mainstream standard.
>  
> Concretely, after ML-KEM is finished, I was planning to update 
> draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint 
> for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.
>  
> Great!
>  
> Thanks 
>  
> On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
>  > wrote:
>> Hi,
>> 
>> NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
>> standards are expected in Q1 2024.
>> https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
>>  
>> I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
>> ML-DSA (all security levels standardized by NIST) as soon as possible after 
>> the final NIST standards are ready. 3GPP is relying almost exclusively on 
>> IETF RFCs for uses of public key cryptography (the exception is ECIES for 
>> IMSI encryption but that will likely use HPKE with ML-KEM in the future).
>>  
>> Looking at the TLS document list, it seems severely lacking when it comes to 
>> ML-KEM, ML-DSA…
>>  
>> The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with 
>> the pre-standard Kyber. 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>> 
>> AuthKEM is a quite big change to TLS
>> https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/
>>  
>> This is not adopted, informal, and dealing with the pre-standard Kyber.
>> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
>>  
>> What is the TLS WG plan for quantum-resistant algorithms? My current view is 
>> that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
>> and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and 
>> X448 are the only options that make sense. For hybrid signing, ECDSA, EdDSA, 
>> and RSA could all make sense.
>>  
>> Cheers,
>> John
>>  
>> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
>> internet-dra...@ietf.org  
>> mailto:internet-dra...@ietf.org>>
>> Date: Friday, 8 September 2023 at 02:48
>> To: i-d-annou...@ietf.org  
>> mailto:i-d-annou...@ietf.org>>
>> Cc: tls@ietf.org  mailto:tls@ietf.org>>
>> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
>> 
>> Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is a
>> work item of the Transport Layer Security (TLS) WG of the IETF.
>> 
>>Title:   Hybrid key exchange in TLS 1.3
>>Authors: Douglas Stebila
>> Scott Fluhrer
>> Shay Gueron
>>Name:draft-ietf-tls-hybrid-design-09.txt
>>Pages:   23
>>Dates:   2023-09-07
>> 
>> Abstract:
>> 
>>Hybrid key exchange refers to using multiple key exchange algorithms
>>simultaneously and combining the result with the goal of providing
>>security even if all but one of the component algorithms is broken.
>>It is motivated by transition to post-quantum cryptography.  This
>>document provides a construction 

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Yoav Nir]

> On 6 Nov 2023, at 21:44, Watson Ladd  wrote:
> 
> 
> 
> On Mon, Nov 6, 2023, 10:07 AM Kris Kwiatkowski  > wrote:
>> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186 
>> does not impact the curves permitted under SP 800-56Arev3. Curves that are 
>> included in SP 800-186 but not included in SP 800-56Arev3 are not approved 
>> for key agreement. E.g., the ECDH X25519 and X448 key agreement schemes 
>> (defined in RFC 7748) that use Curve25519 and Curve448, respectively, are 
>> not compliant to SP 800-56Arev3…”. This may potentially be a problem, right?
>> 
>> I think to support FIPS requirements properly, we need both shares to be 
>> generated by FIPS approved methods.
> 
> 
> Why do we need FIPS hybrids? The argument for hybrids is that we don't trust 
> the code/algorithms that's new. FIPS certification supposedly removes that 
> concern so can just use the approved PQ implementation.

I don’t know that we need hybrids, but NIST certification alone does not 
obviate the concern about them. They’re just new and different and we have 
(relatively) little experience with them.

That said, protocols that can negotiate algorithms, like TLS or IKE or SSH can 
support several algorithms and avoid broken ones through configuration. This is 
not some long-term signature thing.

Yoav


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

Re: [TLS] Can flags be responded to with an extension?

[Yoav Nir]

Hi.

Here’s a PR to codify that an extension with content is NOT a proper response 
to a flag.  I’m not merging this for now. It’s proposed text to gauge WG 
consensus.

Yoav

https://github.com/tlswg/tls-flags/pull/22 
<https://github.com/tlswg/tls-flags/pull/22>


> On 9 May 2022, at 19:21, Benjamin Kaduk  wrote:
> 
> Hi Ekr,
> 
> On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote:
>> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk > 40akamai@dmarc.ietf.org> wrote:
>> 
>>> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
>>>> 
>>>> 
>>>>> On 14 Apr 2022, at 1:51, Benjamin Kaduk >> 40akamai@dmarc.ietf.org> wrote:
>>>>> 
>>>>> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
>>>>>> Consider the case where the client wants to offer some capability that
>>>>>> the server then responds to with real data, rather than just an
>>>>>> acknowledgement.
>>>>>> 
>>>>>> For instance, supposing the SCT extension from RFC 6962 did not exist,
>>>>>> the client would want to indicate support in CH and the server would
>>>>>> send the SCT in CERT, but this extension would need to be non-empty
>>>>>> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
>>>>>> uncelar on this point (unless I'm missing it) but I think we
>>>>>> should explicitly allow it.
>>>>> 
>>>>> In my head this was already disallowed. I couldn't swear to whether
>>>>> we actually talked about it previously or not, though.
>>>> 
>>>> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
>>> room). In my head it’s also disallowed. In the text, it’s not explicitly
>>> disallowed, but the text does talk about response flags that are in flag
>>> extensions, not about responses that are in other extensions or other
>>> messages. So implicitly disallowed?
>>> 
>>> I think the description in the abstract of the target class of extension as
>>> those "that carry no interesting information except the 1-bit indication
>>> that a
>>> certain optional feature is supported" also implicitly disallows response
>>> bodies.
>>> 
>> 
>> Hmm... I don't think this is really the right approach at this stage.
>> 
>> The situation here is that the explicit text is ambiguous. If this were
>> already an RFC, we would need to try to determine what it meant so that we
>> could agree how implementations ought to be behaving. In that case, yes, we
>> would look at this kind of language to attempt to resolve the ambiguity.
>> 
>> However, this is not an RFC and so our task is to make the specification as
>> unambiguous as possible. At this stage, we should be asking what the
>> *right* answer is, not what the one that most closely matches the current
>> ambiguous text. My argument is that the right answer is the one that most
> 
> Yes. You've convinced me that we need to be (more) explicit one way or the 
> other.
> 
> Please treat my remark as a contribution to enumerating places in the document
> that would need to change if we were to allow responses outside of the flags
> extension.
> 
> -Ben
> 
>> closely embodies the broader goal of saving bandwidth for low-information
>> signals, in this case the signal that the client could process a given
>> server extension. So, yes, the client's extension contains no interesting
>> information but the server's does, which, I think, is consistent with this
>> text, even if, arguably, it's not the better reading.
>> 
>> I can certainly see arguments against forbidding this practice for
>> technical reasons (e.g., simplicity), but, again, then the specification
>> should just say so.
>> 
>> -Ekr

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

Re: [TLS] Can flags be responded to with an extension?

[Yoav Nir]

> On 14 Apr 2022, at 1:51, Benjamin Kaduk  
> wrote:
> 
> On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
>> Consider the case where the client wants to offer some capability that
>> the server then responds to with real data, rather than just an
>> acknowledgement.
>> 
>> For instance, supposing the SCT extension from RFC 6962 did not exist,
>> the client would want to indicate support in CH and the server would
>> send the SCT in CERT, but this extension would need to be non-empty
>> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
>> uncelar on this point (unless I'm missing it) but I think we
>> should explicitly allow it.
> 
> In my head this was already disallowed.  I couldn't swear to whether
> we actually talked about it previously or not, though.

I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the room).  
In my head it’s also disallowed.  In the text, it’s not explicitly disallowed, 
but the text does talk about response flags that are in flag extensions, not 
about responses that are in other extensions or other messages.  So implicitly 
disallowed?

Yoav

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

Re: [TLS] tlsflags and "responses"

[Yoav Nir]

Hi.

I have merged the PR following review and proposed changes by Chris and Martin 
Thomson.

The only point that remains open is Ekr’a suggestion to allow (require?) 
sending the extension when empty.

Yoav

> On 22 Feb 2022, at 7:35, Yoav Nir  wrote:
> 
> I have just submitted PR #20 to allow unacknowledged flags.  It is a rewrite 
> of section 3 (rules)
> 
> https://github.com/tlswg/tls-flags/pull/20 
> <https://github.com/tlswg/tls-flags/pull/20>
> 
> It still requires that the flag extension not be sent when empty.  Let me 
> know if that’s a problem as well.
> 
> Yoav
> 
>> On 21 Feb 2022, at 2:21, Martin Thomson > <mailto:m...@lowentropy.net>> wrote:
>> 
>> I missed this text in draft-ietf-tls-tlsflags:
>> 
>>   A server that supports this extension and also supports at least one
>>   of the flag-type features that use this extension and that were
>>   declared by the ClientHello extension SHALL send this extension with
>>   the intersection of the flags it supports with the flags declared by
>>   the client.  
>> 
>> While sloppy on my part [1], I want to make it clear that this is a 
>> show-stopper for me. Requiring an echo prevents a flag extension from 
>> attaching semantics to a "response".
>> 
>> I agree with Ilari's earlier point that these should work just like 
>> extensions.  If the server has no need to echo a flag, it should not be 
>> required to do that.  That allows the flag value in a "response" to carry 
>> semantics.
>> 
>> Cheers,
>> Martin
>> 
>> [1] I missed this in the second WGLC, though in my defense, I don't think 
>> the resolution and changes resulting from the first WGLC were very clearly 
>> communicated.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org <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] tlsflags and "responses"

[Yoav Nir]

I have just submitted PR #20 to allow unacknowledged flags.  It is a rewrite of 
section 3 (rules)

https://github.com/tlswg/tls-flags/pull/20 


It still requires that the flag extension not be sent when empty.  Let me know 
if that’s a problem as well.

Yoav

> On 21 Feb 2022, at 2:21, Martin Thomson  wrote:
> 
> I missed this text in draft-ietf-tls-tlsflags:
> 
>   A server that supports this extension and also supports at least one
>   of the flag-type features that use this extension and that were
>   declared by the ClientHello extension SHALL send this extension with
>   the intersection of the flags it supports with the flags declared by
>   the client.  
> 
> While sloppy on my part [1], I want to make it clear that this is a 
> show-stopper for me. Requiring an echo prevents a flag extension from 
> attaching semantics to a "response".
> 
> I agree with Ilari's earlier point that these should work just like 
> extensions.  If the server has no need to echo a flag, it should not be 
> required to do that.  That allows the flag value in a "response" to carry 
> semantics.
> 
> Cheers,
> Martin
> 
> [1] I missed this in the second WGLC, though in my defense, I don't think the 
> resolution and changes resulting from the first WGLC were very clearly 
> communicated.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] IANA Registry for TLS-Flags

[Yoav Nir]

So now that that is settled, publish a new draft?

> On 13 Dec 2021, at 21:19, Martin Thomson  wrote:
> 
> 
> 
> On Tue, Dec 14, 2021, at 01:47, Salz, Rich wrote:
>>>   How about we split the difference and go with the first 0-15 flags for 
>>> standards action? We can keep the initial value of 8 for 
>>> cross-sni-resumption since that document is going through the process. (We 
>>> could also make it 7 or lower so we're not wasting an empty octet for this 
>>> flag, should folks want to go that route.)
>> 
>> Works for me.
> 
> Two bytes it is.  PR updated.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] IANA Registry for TLS-Flags

[Yoav Nir]

Well, that’s two voices for Martin’s PR and just me liking the convoluted text 
that I wrote.

Chairs, care to call consensus?

Yoav

> On 7 Dec 2021, at 23:21, Yoav Nir  wrote:
> 
> Hi.
> 
> We have one outstanding issue about the TLS-Flags draft. It’s about the IANA 
> registry. The way the extension is defined, low identifiers for flags result 
> in shorter extension encoding. For this reason, we want the most popular 
> flags to have low numbers. This is especially true for flags that everyone 
> will use (think RI)
> 
> So the current text says this:
> 
> 4.1.  Guidance for IANA Experts
> 
>This extension allows up to 2040 flags.  However, they are not all
>the same, because the length of the extension is determined by the
>highest set bit.
> 
>We would like to allocate the flags in such a way that the typical
>extension is as short as possible.  The scenario we want to guard
>against is that in a few years some extension is defined that all
>implementations need to support and that is assigned a high number
>because all of the lower numbers have already been allocated.  An
>example of such an extension is the Renegotiation Indication
>Extension defined in [RFC5746].
> 
>For this reason, the IANA experts should allocate the flags as
>follows:
> 
>*  Flags 0-7 are reserved for documents coming out of the TLS working
>   group with a specific request to assign a low number.
> 
>*  Flags 8-31 are for standards-track documents that the experts
>   believe will see wide adoption among either all users of TLS or a
>   significant group of TLS users.  For example, an extension that
>   will be used by all web clients or all smart objects.  The only
>   entry in the initial registry is from this range.
> 
>*  Flags 32-63 are for other documents, including experimental, that
>   are likely to see significant adoption.
> 
>*  Flags 64-79 are not to be allocated.  They are for reserved for
>   private use.
> 
>*  Flags 80-2039 can be used for temporary allocation in experiments,
>   for flags that are likely to see use only in very specific
>   environments, for national and corporate extensions, and as
>   overflow, in case one of the previous categories has been
>   exhausted.
> 
> 
> Quite verbose. Martin Thomson suggests a shorter version that only reserves 
> flags 0-7 for standards action and leaves everything else for “specification 
> required”. No reservation for special request. No private use reserve. No 
> experimental or judgment based on the likelihood of wide adoption:
> 
> https://github.com/tlswg/tls-flags/pull/14/files 
> <https://github.com/tlswg/tls-flags/pull/14/files>
> 
> Please comment.
> 
> Yoav
> 

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

[TLS] IANA Registry for TLS-Flags

[Yoav Nir]

Hi.

We have one outstanding issue about the TLS-Flags draft. It’s about the IANA 
registry. The way the extension is defined, low identifiers for flags result in 
shorter extension encoding. For this reason, we want the most popular flags to 
have low numbers. This is especially true for flags that everyone will use 
(think RI)

So the current text says this:

4.1.  Guidance for IANA Experts

   This extension allows up to 2040 flags.  However, they are not all
   the same, because the length of the extension is determined by the
   highest set bit.

   We would like to allocate the flags in such a way that the typical
   extension is as short as possible.  The scenario we want to guard
   against is that in a few years some extension is defined that all
   implementations need to support and that is assigned a high number
   because all of the lower numbers have already been allocated.  An
   example of such an extension is the Renegotiation Indication
   Extension defined in [RFC5746].

   For this reason, the IANA experts should allocate the flags as
   follows:

   *  Flags 0-7 are reserved for documents coming out of the TLS working
  group with a specific request to assign a low number.

   *  Flags 8-31 are for standards-track documents that the experts
  believe will see wide adoption among either all users of TLS or a
  significant group of TLS users.  For example, an extension that
  will be used by all web clients or all smart objects.  The only
  entry in the initial registry is from this range.

   *  Flags 32-63 are for other documents, including experimental, that
  are likely to see significant adoption.

   *  Flags 64-79 are not to be allocated.  They are for reserved for
  private use.

   *  Flags 80-2039 can be used for temporary allocation in experiments,
  for flags that are likely to see use only in very specific
  environments, for national and corporate extensions, and as
  overflow, in case one of the previous categories has been
  exhausted.


Quite verbose. Martin Thomson suggests a shorter version that only reserves 
flags 0-7 for standards action and leaves everything else for “specification 
required”. No reservation for special request. No private use reserve. No 
experimental or judgment based on the likelihood of wide adoption:

https://github.com/tlswg/tls-flags/pull/14/files 


Please comment.

Yoav

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

Re: [TLS] tls-flags: abort on malformed extension

[Yoav Nir]

Hi.

I updated the PR.  If there are no further objections, I will commit and submit 
a new version in time for the submission deadline.

Yoav


> On 7 Oct 2021, at 21:37, Yoav Nir  wrote:
> 
> Since I prefer to have the discussion in a single place, I’m copying below a 
> comment by David Benjamin from GitHub:
> 
>> On 28 Aug 2021, at 23:36, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> Hi.
>> 
>> To address Michael StJohns comment from 19-July, I submitted PR #12:
>> 
>> https://github.com/tlswg/tls-flags/pull/12 
>> <https://github.com/tlswg/tls-flags/pull/12>
>> 
>> What is says is that any implementation receiving a malformed tls_flags 
>> extensions should abort the handshake. The text provides a list (which I 
>> hope is comprehensive) of all the ways this specific extension can be 
>> malformed. 
>> 
>> Please comment here or on the PR is this makes sense to everybody.
> 
> 
> My proposed text:
> 
>>An implementation that receives an invalid tls_flags extension MUST 
>>terminate the TLS handshake with a fatal illegal_parameter alert. 
>>Such invalid tls_flags extensions include: 
>> * zero-length extension
>> * Multiple tls_flags extensions for the same message
>> * A flag set in the tls_flags extension of the wrong message, as 
>>   specified in the document for that flag 
> 
> 
> 
> David’s comment about the zero-length extension:
>> If we want this to be invalid, we can put it in the TLS presentation 
>> language. Change FlagExtensions to:
>> 
>>   struct {
>>  opaque flags<1..255>;
>>   } FlagExtensions;
> 
> 
> David’s comment about the multiple extensions:
>> RFC8446 already prohibits this on the sender. We don't do a good job of 
>> defining the rules for the receiver, but that should probably be done 
>> uniformly across all extensions, rather than just in this one
> 
> 
> David’s comment about the flag on the wrong message:
>> This seems unimplementable. If I receive a message with a flag I don't 
>> recognize, I have no idea whether the flag is allowed in the message or not. 
>> Yet this text says I MUST enforce this rule. (There's probably some 
>> corresponding wording in RFC8446 we can borrow.)
>> 
>> Nit: It also seems better to phrase this in terms of the registry, rather 
>> than the document. We might have multiple documents for the flag if we have 
>> to update it.
> 
> OK, so now my response:
> 
> I agree with the first and second comments. About the third, what I meant was 
> that a supported flag that is supposed to appear only in CH appears instead 
> and CR, or more likely, a flag that should appear in EE apears in SH instead.
> 
> But I think the best way to resolve the issue is to remove the bullet point 
> list and the last sentence before them, IOW: remove the examples.
> 
> If this is agreeable to everyone, I will modify it in my PR.
> 
> Yoav

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

Re: [TLS] tls-flags: abort on malformed extension

[Yoav Nir]

Since I prefer to have the discussion in a single place, I’m copying below a 
comment by David Benjamin from GitHub:

> On 28 Aug 2021, at 23:36, Yoav Nir  wrote:
> 
> Hi.
> 
> To address Michael StJohns comment from 19-July, I submitted PR #12:
> 
> https://github.com/tlswg/tls-flags/pull/12 
> <https://github.com/tlswg/tls-flags/pull/12>
> 
> What is says is that any implementation receiving a malformed tls_flags 
> extensions should abort the handshake. The text provides a list (which I hope 
> is comprehensive) of all the ways this specific extension can be malformed. 
> 
> Please comment here or on the PR is this makes sense to everybody.


My proposed text:

>An implementation that receives an invalid tls_flags extension MUST 
>terminate the TLS handshake with a fatal illegal_parameter alert. 
>Such invalid tls_flags extensions include: 
> * zero-length extension
> * Multiple tls_flags extensions for the same message
> * A flag set in the tls_flags extension of the wrong message, as 
>   specified in the document for that flag 



David’s comment about the zero-length extension:
> If we want this to be invalid, we can put it in the TLS presentation 
> language. Change FlagExtensions to:
> 
>   struct {
>  opaque flags<1..255>;
>   } FlagExtensions;


David’s comment about the multiple extensions:
> RFC8446 already prohibits this on the sender. We don't do a good job of 
> defining the rules for the receiver, but that should probably be done 
> uniformly across all extensions, rather than just in this one


David’s comment about the flag on the wrong message:
> This seems unimplementable. If I receive a message with a flag I don't 
> recognize, I have no idea whether the flag is allowed in the message or not. 
> Yet this text says I MUST enforce this rule. (There's probably some 
> corresponding wording in RFC8446 we can borrow.)
> 
> Nit: It also seems better to phrase this in terms of the registry, rather 
> than the document. We might have multiple documents for the flag if we have 
> to update it.

OK, so now my response:

I agree with the first and second comments. About the third, what I meant was 
that a supported flag that is supposed to appear only in CH appears instead and 
CR, or more likely, a flag that should appear in EE apears in SH instead.

But I think the best way to resolve the issue is to remove the bullet point 
list and the last sentence before them, IOW: remove the examples.

If this is agreeable to everyone, I will modify it in my PR.

Yoav


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

[TLS] tls-flags: abort on malformed extension

[Yoav Nir]

Hi.

To address Michael StJohns comment from 19-July, I submitted PR #12:

https://github.com/tlswg/tls-flags/pull/12 


What is says is that any implementation receiving a malformed tls_flags 
extensions should abort the handshake. The text provides a list (which I hope 
is comprehensive) of all the ways this specific extension can be malformed. 

Please comment here or on the PR is this makes sense to everybody.

Yoav

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

Re: [TLS] WGLC for draft-ietf-tls-flags

[Yoav Nir]

Thanks for the review. Comments inline.

> On 19 Jul 2021, at 2:26, Michael StJohns  wrote:
> 
> On 7/16/2021 7:55 PM, Christopher Wood wrote:
>> This is the second working group last call for the "A Flags Extension for 
>> TLS 1.3" draft, available here:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>> 
>> Please review this document and send your comments to the list by July 30, 
>> 2021. The GitHub repository for this draft is available here:
>> 
>> https://github.com/tlswg/tls-flags
>> 
>> Thanks,
>> Chris, on behalf of the chairs
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> Hi - I have not followed the discussion of this document on the mailing list 
> so this review is only against the document itself. It's possible that these 
> concerns have already been discussed.
> 
> 
> Section 2 requires  (MUST) the generation of fatal illegal_parameter alert 
> upon reception of a mal-encoded extension (e.g. any trailing zero bytes), but 
> compare and contrast this with section 3 which is full of MUST and MUST NOT 
> declarations but with no concrete actions to be taken.  E.g. if I (server or 
> client) send 0x01 0x10, and receive 0x01 0x11 from the client or server, 
> wouldn't that be an illegal value as I've added a bit not sent to me?   
> Should that cause the same fatal illegal_parameter alert? Alternately, 
> "receiver MUST ignore received bits that weren't sent" language could clean 
> this up.

I prefer the hard error, but this should be discussed in the WG. Perhaps a PR 
is in order?

> 
> Section 4 is a bit painful to read in that it took me three read-throughs to 
> understand that what the document is asking for is a monolithic registry 
> which requires "expert review" for all registrations, but where the experts 
> are responsible for the sub range determinations.   Usually, that's not the 
> way the IANA works.  If a registry has distinct set of ranges, each range 
> normally has a specific registration procedure that the IANA follows before 
> placing a parameter in that registry.
> 

The way it works with all the TLS registries is that IANA asks the expert for 
advice on which numbers to assign regardless of how the registry is segmented.  
So it’s up to the experts anyway.

Yoav

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

Re: [TLS] WGLC for draft-ietf-tls-flags

[Yoav Nir]

> On 22 Jul 2021, at 21:35, Viktor Dukhovni  wrote:
> 
> On Fri, Jul 16, 2021 at 04:55:49PM -0700, Christopher Wood wrote:
> 
>> This is the second working group last call for the "A Flags Extension for 
>> TLS 1.3" draft, available here:
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>> 
>> Please review this document and send your comments to the list by July 30, 
>> 2021. The GitHub repository for this draft is available here:
>> 
>>https://github.com/tlswg/tls-flags
> 
> Just one editorial comment, I think that the initial registration code
> point of 0x8 (hex) is potentially confusing, is it the 8th bit, or the
> or bit 3?  The bit positions range from 0 to 2047 and are easier to
> understand in decimal, especially with the registration ranges given
> in decimal.  So in this document, and in the IANA registry, the code
> points should be decimal.
> 

Makes sense. Created a pull request:

https://github.com/tlswg/tls-flags/pull/7

Yoav

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

Re: [TLS] Flags extension and announcing support

[Yoav Nir]

OK. I think we have as much consensus as we’re likely to get.

I’ve updated the patch branch and PR to reflect this.

Yoav

> On 22 Jan 2021, at 7:45, Martin Thomson  wrote:
> 
> On Fri, Jan 22, 2021, at 16:16, Yoav Nir wrote:
>> See this PR: https://github.com/tlswg/tls-flags/pull/5
> 
> It looks like there is lots of disagreement there.  I'm going to disagree 
> with others too.
> 
>> All except the first are Server-side.
> 
> Certificate is client-side too.
> 
>> The controversy is about unsolicited flags. An unsolicited flag is a 
>> flag that is set in a Flags extension in a server-side message without 
>> having been first declared in the ClientHello extension.
> 
> So I think that you need to separate requests from responses.  Because 
> Certificate contains response to ClientHello or CertificateRequest, my view 
> is that CertificateRequest can contain any flag (provided that the definition 
> of that flag permits it or you don't know whether it does) and Certificate 
> can only contain flags that CertificateRequest did.  
> 
> This is part of what Ekr seems to have objected to, and I agree with him 
> there.  A server should be able to use any flag in NewSessionTicket or 
> CertificateRequest because those are the messages that initiate an exchange 
> (NST doesn't generate any response, so it's an exchange with one flight, but 
> that's immaterial).
> 
> To review:
> ClientHello is answered by HelloRetryRequest, ServerHello, 
> EncryptedExtensions, and (server) Certificate.
> CertificateRequest is answered by (client) Certificate.
> NewSessionTicket is not answered (which is totally fine).
> 
> Those three first messages above can include new flags.  They can contain the 
> extension or not at the discretion of the entity that sends the message.  
> Those messages that are in response can only contain the extension if the 
> initiating message contained the extension.  Furthermore, the extension can 
> only contain a specific flag if the initiating message contained that flag.
> 
> In other words, each flag is treated just like an empty extension: you can 
> initiate an exchange with it, but you can only answer with it if it was 
> initiated with it.
> 
> This differs a little from Chris who suggests that only NewSessionTicket can 
> include a flag that was previously not indicated.
> 
> ___
> 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] Flags extension and announcing support

[Yoav Nir]

Hi.

See this PR: https://github.com/tlswg/tls-flags/pull/5 


The PR is for clarifying what TLS messages may carry the flags extension.  So 
any message that can carry an extension, can carry a flags extension (if there 
are flags defined for that message). These are:
ClientHello
ServerHello
EncryptedExtensions
Certificate
CertificateRequest
HelloRetryRequest
NewSessionTicket

All except the first are Server-side.

The controversy is about unsolicited flags. An unsolicited flag is a flag that 
is set in a Flags extension in a server-side message without having been first 
declared in the ClientHello extension.

There is no controversy about flags in ServerHello and EncryptedExtensions. 
Those cannot have unsolicited flags, because both messages are responses to the 
ClientHello. 

The question is about the other messages. especially the NST and CR.

What do other think?

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

Re: [TLS] TLS Flags Open Question

[Yoav Nir]

As all (OK, both) of the responses have been supportive, I have created a pull 
request:

https://github.com/tlswg/tls-flags/pull/5 
<https://github.com/tlswg/tls-flags/pull/5>

Yoav

> On 5 Dec 2020, at 17:04, Yoav Nir  wrote:
> 
> Hi.
> 
> At IETF 108 a question was raised about The TLS Flags extension.  What  
> payloads on the server side can include this extension?
> 
> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and 
> NewSessionTicket.
> 
> The only one that is controversial here (I think) is ServerHello, because it 
> is not encrypted.  Looking at the current list of extensions, I see that only 
> 6 can go in ServerHello:
> password_salt
> tls_cert_with_extern_psk
> supported_ekt_ciphers
> pre_shared_key
> supported_versions
> key_share
> 
> Of those, only one would be (if it hadn’t already been standardized) a 
> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC 
> describes it with “The “tls_cert_with_extern_psk" extension is essentially a 
> flag to use the external PSK in the key schedule”.  I don’t think it’s 
> unreasonable to think that at some point there’s going to be another 
> flag-like extension that will need to be signalled in ServerHello.
> 
> So the question for the group is, do we allow the flags extension (and the 
> flags themselves) to be in ServerHello, or do we prohibit them for now, and 
> if ever an extension does need to signal in ServerHello, it can update the 
> TLS-Flags RFC at that time?
> 
> My vote would be to allow it in all places, and trust the process not to 
> place flags that should be encrypted in payloads that aren’t, but either way, 
> we need working group consensus.
> 
> Thanks
> 
> Yoav
> 

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

[TLS] TLS Flags Open Question

[Yoav Nir]

Hi.

At IETF 108 a question was raised about The TLS Flags extension.  What  
payloads on the server side can include this extension?

The “candidates” are ServerHello, EncryptedExtensions, Certificate, and 
NewSessionTicket.

The only one that is controversial here (I think) is ServerHello, because it is 
not encrypted.  Looking at the current list of extensions, I see that only 6 
can go in ServerHello:
password_salt
tls_cert_with_extern_psk
supported_ekt_ciphers
pre_shared_key
supported_versions
key_share

Of those, only one would be (if it hadn’t already been standardized) a 
candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC 
describes it with “The “tls_cert_with_extern_psk" extension is essentially a 
flag to use the external PSK in the key schedule”.  I don’t think it’s 
unreasonable to think that at some point there’s going to be another flag-like 
extension that will need to be signalled in ServerHello.

So the question for the group is, do we allow the flags extension (and the 
flags themselves) to be in ServerHello, or do we prohibit them for now, and if 
ever an extension does need to signal in ServerHello, it can update the 
TLS-Flags RFC at that time?

My vote would be to allow it in all places, and trust the process not to place 
flags that should be encrypted in payloads that aren’t, but either way, we need 
working group consensus.

Thanks

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed change in TLS-Flags

[Yoav Nir]

I don’t know. There already is an extension for this.

We haven’t discussed whether we want to “cover” semantics that already exist in 
other extensions.

If that’s something the group wants, we can add it, but it’s not generally a 
good thing for a protocol to have two ways of expressing the same thing.

Yoav

> On 1 Jul 2020, at 19:00, Hannes Tschofenig  wrote:
> 
> One question: Wouldn’t you want to register a flag for "Post-Handshake Client 
> Authentication" in this document?
> 
> Ciao
> Hannes
> 
> 
> From: TLS  On Behalf Of Hannes Tschofenig
> Sent: Wednesday, July 1, 2020 5:55 PM
> To: Yoav Nir ;  
> Subject: Re: [TLS] Proposed change in TLS-Flags
> 
> Yoav,
> 
> I looked at the draft and the PR. I am fine with the proposed changes.
> This is a short and useful draft.
> 
> Ciao
> Hannes
> 
> From: TLS  On Behalf Of Yoav Nir
> Sent: Monday, June 29, 2020 11:34 PM
> To:  
> Subject: [TLS] Proposed change in TLS-Flags
> 
> Hi
> 
> I’ve just submitted the following PR:
> 
> https://github.com/tlswg/tls-flags/pull/4
> 
> Three changes:
> • It is no longer allowed to send an empty flags extension.  If you don’t 
> support any flags, don’t send the extension.
> • The server is no longer allowed to respond with flag types that the client 
> didn’t indicate support for first.
> • I’ve split the extension description section into a format section and a 
> rules section
> 
> Please comment. Barring any objections, I’ll merge the PR just before the 
> submission deadline.
> 
> Yoav
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

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

Re: [TLS] Proposed change in TLS-Flags

[Yoav Nir]

Yeah, the thread that Nick mentioned.

Also, since there are no such extensions defined in the base TLS 1.3 spec, the 
server can’t assume that the client knows what either the specific flag means, 
or the entire flags extension means. 

So suppose we invent some new client authentication scheme for TLS, it does 
make sense for the server to signal that it supports this so that the client 
can do. But I don’t think it’s too onerous to require that the client indicate 
support first.

Yoav

> On 1 Jul 2020, at 2:30, David Schinazi  wrote:
> 
> Hi Yoav,
> 
> Could you elaborate on the rationale for this change please?
> I was assuming that the ability for servers to send extensions not requested 
> by clients was useful.
> 
> Thanks,
> David
> 
> On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> Hi
> 
> I’ve just submitted the following PR:
> 
> https://github.com/tlswg/tls-flags/pull/4 
> <https://github.com/tlswg/tls-flags/pull/4>
> 
> Three changes:
> It is no longer allowed to send an empty flags extension.  If you don’t 
> support any flags, don’t send the extension.
> The server is no longer allowed to respond with flag types that the client 
> didn’t indicate support for first.
> I’ve split the extension description section into a format section and a 
> rules section
> 
> Please comment. Barring any objections, I’ll merge the PR just before the 
> submission deadline.
> 
> Yoav
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls 
> <https://www.ietf.org/mailman/listinfo/tls>

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

[TLS] Consultation About Assignment of ExtensionTypes

[Yoav Nir]

Hi.

I’m posting this on behalf of the IANA experts for the TLS registries. The IANA 
experts function is described in RFC  8447 [1].

We’ve received a request from ETSI to assign three ExtensionType values from 
the ExtensionType registry [2]. ETSI is the European Telecommunications 
Standards Institute [3]. Ordinarily requests from other standards organizations 
are approved as long as they’re not in conflict with current work within the 
IETF, and for the ExtensionType registry the policy is “Specification 
Required”.  The reason we are consulting this time is that we can foresee some 
objections should these assignments appear in the IANA registry.

So the request is for a part 2 of the Middlebox Security Protocol [4].  You can 
read it all, but the gist is a protocol between a TLS endpoint and a TLS 
middlebox that allows the middlebox read, read+delete, or read+delete+write 
access to the data stream. If this idea is giving you déjà vu, then yes, the 
TLS working group has considered proposals in that domain in the past, and to 
put in mildly, did not choose to take them up.

To re-iterate, the policy for the registry is “Specification Required” and a 
specification is available. Unless we hear convincing arguments to the 
contrary, we will approve this allocation. We just prefer to have the kerfuffle 
before the assignment rather than afterwards.

Thanks

Yoav
(with the IANA expert hat on)


[1] https://tools.ietf.org/html/rfc8447 
[2] 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
 

[3] https://www.etsi.org/about 
[4] 
https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf
 



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

Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

[Yoav Nir]

See below.

I think the next thing to do is to get a signal from the working group about 
whether we do or don’t want to allow unsolicited server flags, because 
prohibiting it will require a significant change in the draft.

I’m happy to make such a change, because I still can’t come up with such a flag.

> On 23 Apr 2020, at 3:07, Martin Thomson  wrote:
> 
> On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote:
>>> Third, more substantially, and invalidating the above, I don't think that 
>>> we should make flags introduce a new style of negotiation just because it 
>>> can.  I would strongly prefer that this function as close as possible to 
>>> "empty ClientHello extension; empty EncryptedExtensions extension".  Aside 
>>> from that, the utility of an advertisement from the server that a client 
>>> cannot respond to is pretty marginal.
>> 
>> If this is what the group prefers, I’m fine with it, but then there’s 
>> never any point in sending an empty extension, either from the client 
>> of form the server. The absence of an individual flag is always implied 
>> from the absence of the extension.
> 
> When you say "empty extension" here, do you mean "empty flags extension" or 
> are you speaking more generally?
> 
> If the server can't add flags, then I agree that having the client send an 
> empty flags extension has little value.  Same for the server sending an empty 
> flags extension in that case.

I mean the flags extension. An empty extension conveys just that the sender 
supports the extension. An empty CH flags extension just says the client 
supports the flags extension. Unless the server is allowed to send unsolicited 
flags, an empty flags extension in CH does not convey any useful information.
> 
>>> Are we confident that sending the same extension in both places is safe?  I 
>>> know that clients have to implement this and so should be able to test that 
>>> this works, but it seems awkward.  And it might not be necessary.  It's 
>>> also not sufficient, as we currently allow responses to ClientHello 
>>> extensions to appear in Certificate (and for CertificateRequest to carry 
>>> "requests" in the other direction).
>> 
>> I don’t think the two extensions ever carry the same flags. Each server 
>> side flag should be one of three: serverHello, encrpytedExtensions, or 
>> neither (if we are not expecting a response)
> 
> So the intersection of flags in different responses must be zero?  i.e. 
> flags[ServerHello] & flags[EncryptedExtensions] == 0 (and the same for any 
> combination that we allow, including Certificate and NewSessionTicket, I 
> guess).

I can’t think of any flag that will have a different meaning when sent in SH or 
EE so that you might want to send both. Just in case, the flag registry should 
have a field similar to the extension registry which says where the field is 
valid.

> 
>> As for Certificate, I don’t see why we’d need to add bit responses to 
>> Certificate. They can safely be sent in either serverHello or 
>> encryptedExtensions.
> 
> The obvious thing here is when the extension applies on a per-certificate 
> basis as opposed to the entire chain.  But I don't have an example you can 
> use; see below.
> 
>> I’m trying to come up with key exchange bits that might be useful.  
>> Perhaps a new, improved alternative to HKDF?  Support for Quantum Key 
>> Exchange?
> 
> This might require an understanding of the overall strategy.  If the goal is 
> to provide an analogue of a generic "empty extension", then sure, put it in 
> ServerHello.  But put it in Certificate and NewSessionTicket too.  But if you 
> make this more narrowly applicable and say that you have a different flags 
> extension for each type of exchange (ClientHello -> ServerHello, ClientHello 
> -> EncryptedExtensions, ClientHello -> NewSessionTicket, 
> ClientHello/CertificateRequest -> Certificate), then you might avoid 
> answering this question for now.
> 
> Right now, it seems like the obvious use here is for EncryptedExtensions, so 
> we could decide to defer that architectural question by saying that it is 
> limited to EncryptedExtensions for now.  Then we can either expand the one 
> flags extensions to allow it in NewSessionTicket when we need to, or define a 
> new one.

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

Re: [TLS] WGLC for "A Flags Extension for TLS 1.3"

[Yoav Nir]

Inline...

> On 7 Apr 2020, at 1:39, Martin Thomson  wrote:
> 
> I like this work, but I don't believe this to be ready yet.
> 
> S1
>   None of the current proposed extensions are such that the server
>   indicates support without the client first indicating support.  So as
>   not to preclude future extensions that are so defined, this
>   specification allows the client to send an empty extension,
>   indicating support for TLS flags in general (and presumably some
>   unspecified features in particular).
> 
> First, for clarification, the distinction between empty and all-zero-valued 
> is perhaps worth drawing on.

I think the description of the extension in section 2 is clear. An extension 
without any flags set is empty, It’s not all zero-valued.  A FlagsExtensions 
field with a length of 1 and the one byte being zero is an invalid encoding of 
the extension as its length is the minimal length possible. So only an empty 
extension is meaningful.

>  Second, more seriously, if this is the goal, the text needs to acknowledge 
> that the possibility exists on a *per-flag* basis.

Can you suggest text?

> 
> Third, more substantially, and invalidating the above, I don't think that we 
> should make flags introduce a new style of negotiation just because it can.  
> I would strongly prefer that this function as close as possible to "empty 
> ClientHello extension; empty EncryptedExtensions extension".  Aside from 
> that, the utility of an advertisement from the server that a client cannot 
> respond to is pretty marginal.

If this is what the group prefers, I’m fine with it, but then there’s never any 
point in sending an empty extension, either from the client of form the server. 
The absence of an individual flag is always implied from the absence of the 
extension.

> Fourth, this conflicts with the following text in S2:
> 
>   A server that supports this extension and also supports at least one
>   of the flag-type features that use this extension and that were
>   declared by the ClientHello extension SHALL send this extension with
>   the intersection of the flags it supports with the flags declared by
>   the client.

Agree. So either we abolish “silent client - server declares” extensions (let’s 
call them unsolicited), or we rephrase the above something along the lines of:

A server that supports the extension and also supports at least one flag 
that was either present in the ClientHello extension or is allowed to be sent 
unsolicited, SHALL send this extension with all of the flags it is configured 
to support except those that are not allowed to be sent unsolicited and that 
were not present in the ClientHello extension

> Nit here: this isn't about support alone, it is the flags that the server 
> *chooses* to support.

“configured to support” ?


> S2
>   The server may need to send two tls_flags extensions,
>   one in the ServerHello and the other in the EncryptedExtensions
>   message.  
> 
> Are we confident that sending the same extension in both places is safe?  I 
> know that clients have to implement this and so should be able to test that 
> this works, but it seems awkward.  And it might not be necessary.  It's also 
> not sufficient, as we currently allow responses to ClientHello extensions to 
> appear in Certificate (and for CertificateRequest to carry "requests" in the 
> other direction).

I don’t think the two extensions ever carry the same flags. Each server side 
flag should be one of three: serverHello, encrpytedExtensions, or neither (if 
we are not expecting a response)

I think this requires another field in the IANA registry.

As for Certificate, I don’t see why we’d need to add bit responses to 
Certificate. They can safely be sent in either serverHello or 
encryptedExtensions.

> Perhaps we might avoid this problem entirely.  ServerHello extensions are 
> limited to key exchange.  If we say that flags are limited (today) to 
> functional properties that don't affect key exchange, my thought is that we 
> don't lose much (if anything) by only allowing this extension in 
> EncryptedExtensions.

I’m trying to come up with key exchange bits that might be useful.  Perhaps a 
new, improved alternative to HKDF?  Support for Quantum Key Exchange?

> I don't know what I think about Certificate extensions.  This seems to have a 
> clear use there.
> 
> Editorial:
> 
> S1
> It might be better to draw examples from the canon of published RFCs than to 
> refer to things that might not get published.

I support I cna mention RI earlier.

> 
> On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote:
>> This is the working group last call for the "A Flags Extension for TLS 
>> 1.3" draft, available at:
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>> 
>> Please review the document and send your comments to the list by April 
>> 20, 2020. The GitHub repository for this draft is available at:
>> 
>>https://github.com/tlswg/tls-flags
>> 
>> Thanks,
>> 

[TLS] tls-flags Guidance on Allocating Bits

[Yoav Nir]

Hi

Following the discussion last month, especially my message from 31-Jan [1], 
I’ve submitted a PR [2] for guidance on allocating the TLS flags with the goal 
to minimize the size of the typical extension.

Please comment here or in github.

Yoav Nir

[1] https://mailarchive.ietf.org/arch/msg/tls/ld2rY9px71wrxlWfzXhey02vPcc 
<https://mailarchive.ietf.org/arch/msg/tls/ld2rY9px71wrxlWfzXhey02vPcc>
[2] https://github.com/tlswg/tls-flags/pull/3 
<https://github.com/tlswg/tls-flags/pull/3>


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

Re: [TLS] New direction for TLS?

[Yoav Nir]

> On 14 Feb 2020, at 22:03, Benjamin Kaduk  wrote:
> 
> Hi Mike,
> 
> On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote:
>> Hi,
>> 
>> It's been a long time since I posted to this list but saw that the charter 
>> is being updated and wanted to share an idea I had a while ago but have not 
>> found the time to work on.  The TL;DR is to deprecate TLS and rebuild 
>> security on top of DTLS. With DTLS, you have encrypted packets, so think of 
>> them as the new IP and build TCP on top of that.  It'd be like making the 
>> internet run on TCP/DTLS instead of TCP/IP, so most of the work is already 
>> done.  I think this is all I need to say to get the idea across, but I can 
>> add detail if needed.
> 
> This sounds really similar to QUIC

If it’s TCP (rather than HTTP) on top of the encryption layer, it sounds more 
like transport-mode IPsec. That gives you encrypted packets.

The difference is whether the authentication and encryption is part of the 
service provided by the OS (like IP) or part of the application.

Yoav

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

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

[Yoav Nir]

> On 31 Jan 2020, at 14:26, Hubert Kario  wrote:
> 
> On Thursday, 30 January 2020 21:08:39 CET, Stephen Farrell wrote:
>> 
>> On 30/01/2020 17:57, Yoav Nir wrote:
>>> Hi folks.
>>> In case you’re not following GitHub, there was an issue with a brief
>>> discussion ([1]) and a resulting pull request ([2]).
>>> If there are no objections by late next week, I will merge the PR.
>> 
>> Allowing 2040 flags seems a bit mad and a possible
>> foot-gun - with a specification required rule that
>> could end up worse than the ciphersuites registry!
>> 
>> Given it's possible to define a tls_flags2 extension
>> if this one runs out, I'd argue to constrain this to a
>> much smaller number of flags - 63 should be plenty
>> I'd say.
>> 
>> That said, it's not that huge a deal since I have
>> a hard time seeing implementers even trying to code
>> for 2040 flags and specification required is the
>> same rule as for extensions.
> 
> well, if the specification says that it can include 2040 flags, an 
> implementation
> must be able to process such an extension
> 
> if the idea of this extension is to reduce the size of ClientHello (the 
> utility
> of which I find questionable), then I don't see a situation where we will 
> really
> need to send old and new extensions at the same time as likely – I expect that
> if we do allow 2040 flags, the extension in 10 or 20 years will commonly 
> include
> just few set bits and plenty of zeros – wasting bandwidth again

An implementation need only support up to the last bit that is meaningful to 
it.  If the last feature it supports is number 30, there’s no need to read any 
of the octets beyond the fourth

I think that we can help the situation by partitioning the space as follows:
 - First octet is for standards-track documents coming out of TLS where the 
draft specifically requests such assignment.  Like if we ever need a 
renegotiation_info again.
 - Octets 2-4 are for other standards-track documents.
 - Octets 5-7 are for experimental drafts. They don’t get re-assigned if they 
later become standards track
 - Octets 8 are reserved-private
 - Octets beyond that are in case we need more.

With some luck and some care, most ClientHellos will need no more than the 
first 4 bytes.

Yoav

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

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

[Yoav Nir]

> On 30 Jan 2020, at 22:08, Stephen Farrell  wrote:
> 
> 
> 
> On 30/01/2020 17:57, Yoav Nir wrote:
>> Hi folks.
>> 
>> In case you’re not following GitHub, there was an issue with a brief
>> discussion ([1]) and a resulting pull request ([2]).
>> 
>> If there are no objections by late next week, I will merge the PR.
> 
> Allowing 2040 flags seems a bit mad and a possible
> foot-gun - with a specification required rule that
> could end up worse than the ciphersuites registry!
> 
> Given it's possible to define a tls_flags2 extension
> if this one runs out, I'd argue to constrain this to a
> much smaller number of flags - 63 should be plenty
> I'd say.
> 
> That said, it's not that huge a deal since I have
> a hard time seeing implementers even trying to code
> for 2040 flags and specification required is the
> same rule as for extensions.
> 
> Cheers,
> S.

The format allows 2040 bits. I think we should never define that many bits. I 
think we should never define even 60 bits. But I also think it should be left 
up to the TLS chairs and the IANA experts to serve as gatekeepers rather than 
tying their hands in the specification.


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

Re: [TLS] Feedback on draft-ietf-tls-tlsflags

[Yoav Nir]

Hi folks.

In case you’re not following GitHub, there was an issue with a brief discussion 
([1]) and a resulting pull request ([2]).

If there are no objections by late next week, I will merge the PR.

Yoav

[1] https://github.com/tlswg/tls-flags/issues/1
[2] https://github.com/tlswg/tls-flags/pull/2

> On 25 Jan 2020, at 7:07, Christopher Wood  wrote:
> 
> We'd like to move draft-ietf-tls-tlsflags [1] along. To that end, we ask that 
> interested parties please review the document and send feedback to the list. 
> You may also send feedback to the document repository [2]. 
> 
> Assuming no substantial or controversial issues arise, we'll start WGLC 
> shortly thereafter, aiming to finish before IETF 107.
> 
> Thanks,
> Chris, on behalf of the chairs
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> [2] https://github.com/tlswg/tls-flags
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

[Yoav Nir]

> On 12 Aug 2019, at 21:25, Ilari Liusvaara  wrote:
> 
> On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-dra...@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>> 
>>Title   : A Flags Extension for TLS 1.3
>>Author  : Yoav Nir
>>  Filename: draft-ietf-tls-tlsflags-00.txt
>>  Pages   : 6
>>  Date: 2019-08-12
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00
> 
> Two things:
> 
> 
> 1) uint8 flags<0..31>;
> 
> That adds an extra byte that is not technically necressary (because
> extensions have lengths anyway) and limits number of flags to 248
> (which might be enough).

I hope 248 is enough...

> And I do not think the length of flags field can be 0 (if it would
> be, one could just omit the extension).

There could be a future flag that the server sends unsolicited 
(client-auth-required?).  It’s important for the client to show support for the 
flags extension to make sure that it understands what the server is sending.

Depends on how we define the semantics in the draft.

> 
> 
> 2) I think the bit order within octets should be reversed
> 
> That is, pack flags so that 0 is LSB of first octet, 7 is MSB of
> first octet, 8 is LSB of second octet and so on.
> 
> Then one can read status flags by index with code like:
> 
> fn read_flag(flags: &[u8], idx: usize) -> bool
> {
>*flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0
> }
> 
> (That code will also happily handle out-of-array flags by reading
> them as false.)

Makes sense. I get caught up in visualizing computer memory and protocol 
messages as a string of bits written from left to right.

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

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

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

[Yoav Nir]

Hi.

This is an almost exact copy of draft-nir-tls-tlsflags-02.  Since that is the 
draft that was adopted, I submitted at as the -00 version.

I will reply to comments that came up during the adoption call later today or 
tomorrow, but feel free to comment some more.

Yoav

> On 12 Aug 2019, at 20:48, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
>Title   : A Flags Extension for TLS 1.3
>        Author  : Yoav Nir
>   Filename: draft-ietf-tls-tlsflags-00.txt
>   Pages   : 6
>   Date: 2019-08-12
> 
> Abstract:
>   A number of extensions are proposed in the TLS working group that
>   carry no interesting information except the 1-bit indication that a
>   certain optional feature is supported.  Such extensions take 4 octets
>   each.  This document defines a flags extension that can provide such
>   indications at an average marginal cost of 1 bit each.  More
>   precisely, it provides as many flag extensions as needed at 4 + the
>   order of the last set bit divided by 8.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

[TLS] Fwd: New Version Notification for draft-nir-tls-tlsflags-02.txt

[Yoav Nir]

Hi.

Following today’s session, I’ve updated and submitted the draft.

It contains the proposal from slide #5 in my presentation.

It does not contain any fancy way of reserving bits for future popular 
extensions.

It uses a single numbering of the flags, not the more efficient separate 
numbering per context (CH, SH, EE, CH-in-CTLS)

I believe such bikeshedding can be done after adoption. Just so long as we 
don’t make it of asbestos. [1]

Yoav

[1] It was never about the color of the bike shed, but about the material: 
https://en.wikipedia.org/wiki/Law_of_triviality#Examples 
<https://en.wikipedia.org/wiki/Law_of_triviality#Examples>


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-nir-tls-tlsflags-02.txt
> Date: 23 July 2019 at 23:22:50 GMT-4
> To: "Yoav Nir" 
> 
> 
> A new version of I-D, draft-nir-tls-tlsflags-02.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name: draft-nir-tls-tlsflags
> Revision: 02
> Title:A Flags Extension for TLS 1.3
> Document date:2019-07-22
> Group:Individual Submission
> Pages:6
> URL:
> https://www.ietf.org/internet-drafts/draft-nir-tls-tlsflags-02.txt
> Status: https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/
> Htmlized:   https://tools.ietf.org/html/draft-nir-tls-tlsflags-02
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-02
> 
> Abstract:
>   A number of extensions are proposed in the TLS working group that
>   carry no interesting information except the 1-bit indication that a
>   certain optional feature is supported.  Such extensions take 4 octets
>   each.  This document defines a flags extension that can provide such
>   indications at an average marginal cost of 1 bit each.  More
>   precisely, it provides as many flag extensions as needed at 4 + the
>   order of the last set bit divided by 8.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [TLS] A flags extension

[Yoav Nir]

I think I only allow the server to set bits that had been set by the client.

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


> On 29 Mar 2019, at 22:30, Martin Thomson  wrote:
> 
> In addition to this, the document would seem to allow a server to set bit k 
> if the client did not set that bit. (Or more generally, the responder can set 
> bits the initiator did not set. )
> 
> In fitting with the TLS model, I would recommend allowing a responder to set 
> only bits that the initiator sets. Other bits being set would be an error. 
> 
> On Fri, Mar 29, 2019, at 19:59, John Mattsson wrote:
>> Hi,
>> 
>> The document only talks about use in ClientHello, ServerHello, and 
>> EncryptedExtensions. I think it should also discuss usage in 
>> CertificateRequest, Certificate from the server, and Certificate from 
>> the client. It should likely be left to the document that specifies a 
>> specific feature to determine where it can be used. 
>> draft-thomson-tls-sic-00 uses the tls_flags extension in 
>> CertificateRequest.
>> 
>> Cheers,
>> John
>> 
>> 
>> ___
>> 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] A flags extension

[Yoav Nir]

> On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor  wrote:
> 
> On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
>> Right. What about defining a set of extensions (e.g., 2 extensions) of
>> flags as:
>> 
>> struct {
>>   uint64 flags;
>> } Flags;
> 
> If we're going to be doing this kind of bit-shaving, this is the way to
> go, starting with a single CommonFlags extension -- and maybe even a
> uint32 or uint16, with the bitfield registry under tight WG control.  If
> we exhaust that space, then we just define a CommonFlags2 extension.
> 
> If someone wants an experimental boolean extension to play with, they
> can always use an empty extension.  They can apply for a bit in
> CommonFlags if they find that the compactness is warranted.
> 

OK. You got me convinced.

In the spirit of revising quickly and revising often, I’ve uploaded version -01:

HTML: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags 

DIFF: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-01 


Yoav

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

Re: [TLS] A flags extension

[Yoav Nir]

> On 26 Mar 2019, at 18:49, Hubert Kario  wrote:
> 
> On Tuesday, 26 March 2019 16:38:11 CET Yoav Nir wrote:
>>> On 26 Mar 2019, at 14:45, Hubert Kario  wrote:
>>> 
>>> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
>>>> Hi.  Today at the TLS meeting, there was a discussion at the mic about
>>>> 1-bit extensions that only serve to indicate support for an optional
>>>> feature. EKR commented that such extensions take 4 bytes each and that
>>>> maybe we need to replace them with a flags extension.
>>>> 
>>>> So I threw together a quick -00 draft with an extension that does just
>>>> that
>>>> [1].
>>>> 
>>>> Comments are welcome.
>>> 
>>> I don't think that "penny-pinching" the 4 bytes necessary to send a flag
>>> is
>>> worth the interoperability problems, and increased complexing of parsing
>>> Client Hello. Especially if we go the route of actual bit flags.
>> 
>> Right. Which is why I went with a 1-byte encoding rather than a bitstring.
>> 
>>> I think the likelihood of bugs in that code over the possible bytes saved
>>> makes it a net negative.
>> 
>> I don’t think so. My encoding is not all that complex.
>> 
>>> yes, TLS is quite chatty protocol, it could encode values much more
>>> tightly, but I think we all remember the bugs related to ASN.1 parsing
>>> from inside of PKCS#1 v1.5 signatures
>> 
>> Complexity is on a spectrum.  DER encoding is pretty far on this spectrum. 
>> A list of 1-octet identifiers is on the other end. A bitstring is more
>> complex than the identifier list, but not anywhere near DER.
> 
> 1-octet identifiers may not be considered extensible enough
> (yes, you can add another extension, but the first extension to use it will 
> be 
> paying an additional price of 2 bytes on top of the extension overhead; same 
> if you just need to use only one flag, then you are paying the same price for 
> every connection)
> 
> 2-octet identifiers asymptotically approach 2-octet saved per flag, which is 
> about 50% saved per flag, I don't see it as much
> 
> to approach it from another way: while I think we will, sometime in the 
> future, reach a situation when we have few hundred flag extensions *defined* 
> , 
> I do not see a future in which we will need to *use* more than few dozen flag 
> extensions in any real world client. So we are talking about a possible 
> saving 
> of around 100 bytes in ClientHello (36 extensions * 3 bytes saved) in this 
> proposal

A few dozen?  I was thinking under 10 in a typical client.

> won't this be completely erased by any post-quantum key share?

I think implementing (or not) draft-ietf-tls-certificate-compression would have 
a much more significant effect than anything we save here.

Yoav

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

Re: [TLS] A flags extension

[Yoav Nir]

> On 26 Mar 2019, at 14:45, Hubert Kario  wrote:
> 
> On Monday, 25 March 2019 22:09:35 CET Yoav Nir wrote:
>> Hi.  Today at the TLS meeting, there was a discussion at the mic about 1-bit
>> extensions that only serve to indicate support for an optional feature. EKR
>> commented that such extensions take 4 bytes each and that maybe we need to
>> replace them with a flags extension.
>> 
>> So I threw together a quick -00 draft with an extension that does just that
>> [1].
>> 
>> Comments are welcome.
> 
> I don't think that "penny-pinching" the 4 bytes necessary to send a flag is 
> worth the interoperability problems, and increased complexing of parsing 
> Client Hello. Especially if we go the route of actual bit flags.

Right. Which is why I went with a 1-byte encoding rather than a bitstring.

> I think the likelihood of bugs in that code over the possible bytes saved 
> makes it a net negative.

I don’t think so. My encoding is not all that complex.

> yes, TLS is quite chatty protocol, it could encode values much more tightly, 
> but I think we all remember the bugs related to ASN.1 parsing from inside of 
> PKCS#1 v1.5 signatures

Complexity is on a spectrum.  DER encoding is pretty far on this spectrum.  A 
list of 1-octet identifiers is on the other end. A bitstring is more complex 
than the identifier list, but not anywhere near DER.

I don’t think we should project the failings of DER parsing to the parsing of 
much simpler structures.

Yoav



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

Re: [TLS] A flags extension

[Yoav Nir]

> On 26 Mar 2019, at 12:05, Peter Gutmann  wrote:
> 
> Yoav Nir  writes:
> 
>> Are we really worried that we’re going to have more than 255 optional
>> features for TLS?
> 
> You're new here aren't you?
> 

No, but I’m looking at the TLS registries ( 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xml 
<https://www.iana.org/assignments/tls-parameters/tls-parameters.xml> ) and the 
only one that has that many entires is the ciphersuites.



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

Re: [TLS] A flags extension

[Yoav Nir]

> On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos  wrote:
> 
> On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
>>> On 26 Mar 2019, at 9:06, Martin Thomson  wrote:
>>> 
>>> This needs more space for each flag.  8 bits is a pretty small
>>> space.  If you are concerned with the size of the result, we have
>>> some variable-length integer encodings you could try.
>> 
>> Ah, the beautiful variable length encodings.  Like:
>> 
>> - 0x00 - 0xBF - for standards-action allocations
>> - 0xC0,0x00 - 0xEF,0xFF - for non-standards track
>> - 0xF0,0x00 - 0xFF,0xFF - for private use among consenting parties.
>> Are we really worried that we’re going to have more than 255 optional
>> features for TLS?
> 
> Given that adding an extended flags extension which can hold even more
> flags is also easy, the 255-optional features do not seem so limited. 
> 
> Going into the extension itself, the array FlagExtensionType seems to
> be the TLS-way to define such variable, but flags are easier, more
> efficient to parse, and take less space if they are bits on an integer
> value (32-bit or 64-bit). Have you considered a simpler structure like
> that?
> 
> struct {
>   uint64 flags;
>   uint64 ext_flags1;
>   uint64 ext_flags2;
>   uint24 ext_flags3;
>   uint16 priv_flags;
> } Flags;
> 
> The advantage is that it can carry the same information with much less
> bytes on the wire and it is easier to parse in low level languages.
> 
> The disadvantage is that an extension flag would now need to specify
> the bit it occupies _and_ the particular element it is set to.

I thought about that. I guess it depends on how many of these optional features 
we expect to be declared at the same time. 

With the current way the draft is written, if the client supports 12 such 
extensions, the extension takes 16 bytes.  With a bitstring, it’s always the 
same length. so we’d need 36 bytes for a 256-bit space. If the client supports 
100 extensions, my encoding takes 104 bytes while the bitstring is still 36 
bytes.

The question is which is more likely?

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

Re: [TLS] A flags extension

[Yoav Nir]

> On 26 Mar 2019, at 9:06, Martin Thomson  wrote:
> 
> This needs more space for each flag.  8 bits is a pretty small space.  If you 
> are concerned with the size of the result, we have some variable-length 
> integer encodings you could try.

Ah, the beautiful variable length encodings.  Like:

 - 0x00 - 0xBF - for standards-action allocations
 - 0xC0,0x00 - 0xEF,0xFF - for non-standards track
- 0xF0,0x00 - 0xFF,0xFF - for private use among consenting parties.

Are we really worried that we’re going to have more than 255 optional features 
for TLS?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] A flags extension

[Yoav Nir]

Hi.  Today at the TLS meeting, there was a discussion at the mic about 1-bit 
extensions that only serve to indicate support for an optional feature. EKR 
commented that such extensions take 4 bytes each and that maybe we need to 
replace them with a flags extension.

So I threw together a quick -00 draft with an extension that does just that [1].

Comments are welcome.

Yoav

[1] https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/ 



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

[TLS] Review of draft-ietf-tls-tls13-cert-with-extern-psk-00

[Yoav Nir]

Hi.

I’ve read this draft. For the most part it seems fine, but I have a few 
editorial nits:


Abstract:
I realize that all of section 3 is dedicated to motivation, but there really 
needs to be something in the abstract. Otherwise, I’m reading “authenticate 
with a combination of a certificate and an external pre-shared key” and 
wondering why you would want to use a certificate at all if you’ve managed to 
get a PSK between the client and the server.  It needs at least something like 
“... in order to facilitate post-quantum forward secrecy.” at the end.


Section 1 (Introduction):
The Introduction contains the following text: "The TLS 1.3 ... provides two 
mutually exclusive forms of server authentication... Second, the server can be 
authenticated by demonstrating that it possesses a pre-shared key (PSK) that 
was established by a previous handshake.”
This flatly says that all PSKs in TLS 1.3 are established by a previous 
handshake, and that is not true. The very next sentence calls these “resumption 
PSKs” and describes other PSKs called “external PSKs”.  So these external PSKs 
are part of TLS 1.3, so the above sentence is incorrect.


Section 3 (Motivation and Design Rationale):
The section describes the threat to forward secrecy of a future large-scale 
quantum computer.  Then the third paragraph says this:
"In the near-term, this document describes [a] TLS 1.3 extension to protect 
today's communications from the future invention of a large-scale quantum 
computer by providing a strong external PSK as an input to the TLS 1.3 key 
schedule while preserving the authentication provided by the existing 
certificate and digital signature mechanisms.”

It is not obvious to me that adding an external PSK to the TLS 1.3 key schedule 
protects against a large-scale quantum computer.  The IPsecME draft specifying 
the same thing ( https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2 ) has 
such rationale in the Introduction, in the Security Considerations section, and 
in Appendix A. I think this document needs some similar text as well.


Section 5 (Certificate with External PSK Extension):
There’s a lot of stuff repeated here from RFC 8446: 
The extensions structure, including its fields
The rules for a server responding with an extension (only if the ClientHello 
contained it)
The rules for a repeated ClientHello following a HelloRetryRequest
The PreSharedKeyExtension from RFC 8446.
The rules for handling an extension that appears in the wrong message.
I don’t believe repeating this information adds clarity.


Section 7 (Security Considerations):
The fifth paragraph says the following:
   Implementations must choose external PSKs with a secure key
   management technique, such as pseudo-random generation of the key or
   derivation of the key from one or more other secure keys.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate
   external PSKs can result in little or no security.  An attacker may
   find it much easier to reproduce the PRNG environment that produced
   the external PSKs and searching the resulting small set of
   possibilities, rather than brute force searching the whole key space.
   The generation of quality random numbers is difficult.  [RFC4086]
   offers important guidance in this area.
That’s fine, but I’m missing the required length of such a PSK.  I believe the 
text should say “at least 256 randomly-generated bits”

Yoav

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

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

[Yoav Nir]

> On 25 Mar 2019, at 19:38, Hubert Kario  wrote:
> 
> On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
>>> On 25 Mar 2019, at 19:23, Hubert Kario  wrote:
>>> 
>>> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
>>>> Yeah, so this looks very much like the IKE mechanism (the draft even says
>>>> so)
>>>> 
>>>> In IKE the reason for this is to detect NAT because IPsec does not
>>>> traverse
>>>> NAT. We need to detect the NAT so as to choose an IPsec variant that
>>>> traverses NAT.  If the server (or IKE Responder) lies, you might use the
>>>> NAT Traversing method when it’s not required, or if the server is really
>>>> good at lying, you might not use NAT Traversal when you should.
>>>> 
>>>> With the proposed TLS extension, I would like to see a better analysis
>>>> for
>>>> what happens if the server lies.  What happens if the client uses the
>>>> answer to do geolocation?  We can easily take this to a “gay kid in
>>>> Uganda”
>>>> scenario.
>>>> 
>>>> But I think the more interesting question is why do it at this layer? 
>>>> Why
>>>> not use some web service such as the API version of
>>>> https://www.whatismyip.com <https://www.whatismyip.com/>
>>>> <https://www.whatismyip.com/ <https://www.whatismyip.com/> 
>>>> <https://www.whatismyip.com/ <https://www.whatismyip.com/>>> ?  The
>>>> answer is a property of the device, not to the socket.  We might as well
>>>> have the device figure this out.
>>> 
>>> how is it property of device? at best, it's a property of a LAN. And a LAN
>>> may have multiple Internet uplinks, every other connection may end up
>>> with a different IP (albeit from a small pool), so a public IP of any
>>> particular connection does not reliably indicate public IP of subsequent
>>> connections.
>> It’s perhaps a property of the device at the current connection
>> configuration. Pretty much any consumer device will have a preferred
>> network where the default route is. Any phone with a metered and a
>> non-metered connection will prefer the non-metered connection, and PCs will
>> use the link where the default route is.  It is a reasonable approximation
>> to assume that the web service connection to whatismyip will follow the
>> same path as your other TLS connection.
>> 
>> Servers may have more complicated routing tables, where the “regular” TLS
>> connection might be using a dedicated link while the connection to
>> whatismyip is going to the “Internet”.  I don’t think this is the scenario
>> that this draft is working on.
>> 
>> An interesting twist even for consumer devices may be where one of the two
>> connections chooses IPv4 while the other chooses IPv6.  In that case, they
>> might end up on different links if, for example, the metered connection
>> offers IPv6 while the non-metered connection does not, or vice versa.
> 
> I already gave you an example of situation where that's not the case.
> 
> You can have a router with two Internet links that routes the connections to 
> a 
> different ISP either based on a round-robin fashion or as a fallback when a 
> connection dies.
> 
> Neither of which would be visible to the device connected to a WiFi behind 
> such a router. The client in the context of this I-D.

True.  As far as NAT detection, the answer would be the same — such a client is 
behind NAT regardless of which Internet link the router chooses, so keepalives 
are necessary anyway.  For the other use cases, I’m not so sure.  If a client 
has two “real” IP addresses, what is it supposed to do about identifying ASNs?  
Deciding whether to reuse connections to DNS is directly related to the 
presence of a NAT, so it’s the same as NAT detection. 


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

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

[Yoav Nir]

> On 25 Mar 2019, at 19:23, Hubert Kario  wrote:
> 
> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
>> Yeah, so this looks very much like the IKE mechanism (the draft even says
>> so)
>> 
>> In IKE the reason for this is to detect NAT because IPsec does not traverse
>> NAT. We need to detect the NAT so as to choose an IPsec variant that
>> traverses NAT.  If the server (or IKE Responder) lies, you might use the
>> NAT Traversing method when it’s not required, or if the server is really
>> good at lying, you might not use NAT Traversal when you should.
>> 
>> With the proposed TLS extension, I would like to see a better analysis for
>> what happens if the server lies.  What happens if the client uses the
>> answer to do geolocation?  We can easily take this to a “gay kid in Uganda”
>> scenario.
>> 
>> But I think the more interesting question is why do it at this layer?  Why
>> not use some web service such as the API version of
>> https://www.whatismyip.com <https://www.whatismyip.com/> 
>> <https://www.whatismyip.com/ <https://www.whatismyip.com/>> ?  The answer is 
>> a
>> property of the device, not to the socket.  We might as well have the
>> device figure this out.
> 
> how is it property of device? at best, it's a property of a LAN. And a LAN 
> may 
> have multiple Internet uplinks, every other connection may end up with a 
> different IP (albeit from a small pool), so a public IP of any particular 
> connection does not reliably indicate public IP of subsequent connections.

It’s perhaps a property of the device at the current connection configuration. 
Pretty much any consumer device will have a preferred network where the default 
route is. Any phone with a metered and a non-metered connection will prefer the 
non-metered connection, and PCs will use the link where the default route is.  
It is a reasonable approximation to assume that the web service connection to 
whatismyip will follow the same path as your other TLS connection. 

Servers may have more complicated routing tables, where the “regular” TLS 
connection might be using a dedicated link while the connection to whatismyip 
is going to the “Internet”.  I don’t think this is the scenario that this draft 
is working on.

An interesting twist even for consumer devices may be where one of the two 
connections chooses IPv4 while the other chooses IPv6.  In that case, they 
might end up on different links if, for example, the metered connection offers 
IPv6 while the non-metered connection does not, or vice versa.

Yoav

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

Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

[Yoav Nir]

Yeah, so this looks very much like the IKE mechanism (the draft even says so)

In IKE the reason for this is to detect NAT because IPsec does not traverse 
NAT. We need to detect the NAT so as to choose an IPsec variant that traverses 
NAT.  If the server (or IKE Responder) lies, you might use the NAT Traversing 
method when it’s not required, or if the server is really good at lying, you 
might not use NAT Traversal when you should.

With the proposed TLS extension, I would like to see a better analysis for what 
happens if the server lies.  What happens if the client uses the answer to do 
geolocation?  We can easily take this to a “gay kid in Uganda” scenario.

But I think the more interesting question is why do it at this layer?  Why not 
use some web service such as the API version of https://www.whatismyip.com 
 ?  The answer is a property of the device, not to 
the socket.  We might as well have the device figure this out.

Yoav

> On 25 Mar 2019, at 12:24, David Schinazi  wrote:
> 
> Hi Tommy, thanks for the presentation.
> 
> I do not think the draft succeeds at addressing its goals. The mechanism is a 
> fine way for the client to receive its public address (assuming the server is 
> honest) but I can't see anything useful the client can do with that 
> information.
> 
> 1) Keepalives
> The client cannot adjust its keep alive timeouts based on this 
> information because the network could contain stateful firewalls that require 
> keepalives similar to NATs but are not detectable this way because they do 
> not change addresses.
> 
> 2) Unique Identifiers
> The presence of a NAT does not provide client privacy guarantees. It is 
> trivial for network operators to deploy NATs that still allows 1-to-1 mapping 
> of public address+port to private address+port. The most common example is 
> NPT66. Therefore you cannot use this information to decide whether to reuse 
> DoT connections.
> 
> 3) ASN
> If the goal is for the client to find its ASN, you might as well build a 
> mechanism for the server to send the ASN to the client instead of its 
> address. Otherwise you will need to save the entire database of 
> address-to-ASN mappings on all clients which isn't feasible on smartphones.
> 
> Thanks,
> David
> ___
> 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] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Yoav Nir]

> On 9 Nov 2018, at 13:40, Viktor Dukhovni  wrote:
> 
>> On Nov 9, 2018, at 1:19 AM, Peter Gutmann  wrote:
>> 
>>> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be
>>> used for encryption with ECIES.
>> 
>> Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS
>> (despite actively looking for one,
> 
> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into
> TLS was a mistake, and glad to see them gone in TLS 1.3.

FWIW RFC 8422 also deprecates them for TLS 1.2 and earlier.

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

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

Hi, Daniel

Inline...

> On 19 Mar 2018, at 7:32, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> 
> On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote:
>>> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue <ila...@s21sec.com> wrote:
>>> 
>>> I fail to see how the current draft can be used to provide visibility
>>> to an IPS system in order to detect bots that are inside the bank…
>>> 
>>> On the one hand, the bot would never opt-in for visibility if it’s
>>> trying to exfiltrate data…
>> 
>> The presumption is that any legitimate application would opt-in, so
>> the IPS blocks any TLS connection that does not opt in.
> 
> Thanks for clarifying the bigger picture here, Yoav.
> 
> So if this technology were deployed on a network where not all parties
> are mutually trusting, it would offer network users a choice between
> surveillance by the network on the one hand (opt-in) and censorship on
> the other (opt-out and be blocked).  Is that right?

I see it a little differently. Your computer or my computer, both of which are 
not configured to opt-in, should not be on such networks. In the corporate 
world, there could be a production network that enforces this and has access to 
corporate resources. There will usually also be a “guest” network with 
unfiltered connectivity, but no access to internal databases. This is where 
visitors go, but also where employee phones connect.

Of course the government of Elbonia might require all networks to have this 
feature, and then you’ll have to decide if you want to configure your laptop to 
opt-in.  I would prefer to stay off-line while I’m in Elbonia in that case.

> Designing mechanism for the Internet that allows/facilitates/encourages
> the network operator to force this choice on the user seems problematic.
> Why do we want this for a protocol like TLS that is intended to be used
> across potentially adversarial networks?

This is for hosts using network owned by the same entity that owns the hosts. 
When such hosts communicate outside this network, it’s for the leg of the 
connection that is within this network. I don’t see any use for it across an 
adversarial network.  If you trust it enough to give it your keys, it’s not 
adversarial.

> datacenter operators who want access to the cleartext passing through
> machines they already control already have mechanisms at their disposal
> to do this (whether they can do so at scale safely without exposing
> their customers' data to further risks is maybe an open question,
> regardless of mechanism).

I don’t think these mechanisms are currently available.  That’s a good subject 
for discussion.  If such mechanisms can be written without extending TLS, 
that’s obviously better.
> 
> Mechanisms that increase "visibility" of the cleartext run counter to
> the goals of TLS as an end-to-end two-party secure communications
> protocol.
> 
> Regards,
> 
> --dkg



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

[Yoav Nir]

Yeah, as log as we know who we’re shipping it to and the user intends for us to 
send it to this entity.

For the debugging case that we were talking about in Prague, sending the keys 
out-of-band should work fine.

For some middlebox that needs to decrypt the traffic online, it needs the keys 
before the first data record goes out. I don’t see how we can do that without 
interleaving it with the handshake.



> On 16 Mar 2018, at 0:42, Salz, Rich <rs...@akamai.com> wrote:
> 
> I think if we ship the keys over some kind of secure socket layer we should 
> be okay, right?
> 
> 
> From: Yoav Nir <ynir.i...@gmail.com>
> Date: Thursday, March 15, 2018 at 6:41 PM
> To: Richard Barnes <r...@ipv.sx>
> Cc: Rich Salz <rs...@akamai.com>, Hubert Kario <hka...@redhat.com>, 
> "tls@ietf.org" <tls@ietf.org>
> Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
> 
> IIUC not quite. There is an API, so the application that uses the library can 
> get the keys. The application can then save it to a file, send it to a 
> central repository, send it to the government, or whatever else it might want 
> to do. <>
> 
> There is no built-in setting where OpenSSL writes the keys to a file, nor do 
> applications such as web servers do this AFAIK.
> 
> It should not be difficult to write, but is not provided in off-the-shelf 
> software.
> 
> Making the library send this in-band in some protocol extension is a far 
> bigger endeavor. It’s also a dangerous switch to leave lying around.
> 
> 
>> On 16 Mar 2018, at 0:16, Richard Barnes <r...@ipv.sx <mailto:r...@ipv.sx>> 
>> wrote:
>> 
>> Just to confirm that I understand the scope of the discussion here:
>> 
>> - TLS libraries have facilities to export keys from the library
>> - Obviously, it's possible to ship these exported keys elsewhere (`tail -f 
>> $SSLKEYLOGFILE | nc $LOGBOX`)
>> 
>> So all we're really talking about is whether to define a way to do the 
>> shipment of the exported keys in-band to the TLS session.
>> 
>> 
>> On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich <rs...@akamai.com 
>> <mailto:rs...@akamai.com>> wrote:
>>> This is what OpenSSL provides:
>>> 
>>> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html
>>>  
>>> <https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html>
>>> 
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls 
>>> <https://www.ietf.org/mailman/listinfo/tls>


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue  wrote:
> 
> I fail to see how the current draft can be used to provide visibility to an 
> IPS system in order to detect bots that are inside the bank…
> 
> On the one hand, the bot would never opt-in for visibility if it’s trying to 
> exfiltrate data…

The presumption is that any legitimate application would opt-in, so the IPS 
blocks any TLS connection that does not opt in.




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

[Yoav Nir]

So what’s the flag in openssl.conf that makes it generate a file with all the 
keys?  There isn’t one.  I guess the presumption is that if there was an RFC it 
would be easier to get the powers that be to make it happen. It likely needs to 
be in the main branch to be ubiquitous, because many products come with their 
own OpenSSL package.

TBH I don’t think an RFC would have that effect. Not every RFC gets implemented.


> On 15 Mar 2018, at 13:38, Hubert Kario <hka...@redhat.com> wrote:
> 
> On Thursday, 15 March 2018 05:51:31 CET Yoav Nir wrote:
>> At the risk of stating the obvious, it’s because server owners want to use
>> the same OpenSSL, NSS, SChannel, or whatever you call the Java library that
>> everybody else uses. They’re all widely used, actively maintained, and
>> essentially free.
>> 
>> None of these libraries support any of this functionality.
> 
> huh? Sure, it is not nicely packaged in to allow integration with 3rd party
> systems, and sometimes disabled by default, but it's hardly missing...
> 
> https://github.com/openssl/openssl/pull/1646 
> <https://github.com/openssl/openssl/pull/1646>
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format 
> <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format>
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=393477 
> <https://bugs.chromium.org/p/chromium/issues/detail?id=393477>
> 
>>> On 15 Mar 2018, at 2:16, Watson Ladd <watsonbl...@gmail.com> wrote:
>>> 
>>> One can either use a static DH share, save the ephemerals on the
>>> servers and export them, or log all the data on the servers.
>>> 
>>> These options don't require any change to the wire protocol: they just
>>> require vendors supporting them. Why don't they meet the needs cited?
>>> 
>>> Sincerely,
>>> Watson
>>> 
>>> ___
>>> TLS mailing list
>>> 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 
>> <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com <http://www.cz.redhat.com/>
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

Hi, Rich.

You are conflating customers and users. The customer that may be protected by 
breaking TLS in a bank’s server farm is the bank itself. An IPS system with 
visibility into the traffic may detect bots that are there to steal data or 
mine cryptocurrencies or whatever.

If the customers of the bank are protected, it’s a happy side effect 
(collateral benefit?). The object is to protect the system integrity and the 
data.

Yoav

> On 15 Mar 2018, at 5:29, Salz, Rich  wrote:
> 
> Some on this list have said that they need to break into TLS in order to 
> protect customers.
> 
> The thing customers seem to need the most protection is having their personal 
> data stolen.  It seems to happen with amazing and disappointing regularity on 
> astounding scales.  Some examples include
> retailer Target, presumably subject to PCI-DSS rules
> Anthem health insurance, presumably a regulated industry
> Equifax, a financial-business organization (but apparently not regulated)
> Yahoo, a company created on and by and for the Internet (one would think they 
> know better)
> We could, of course, go on and on and on.
> 
> NONE of those organizations are using TLS 1.3.
> 
> So what kind of “protect the customer” requires breaking TLS?  And what 
> benefits and increased protection will customers see?
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

[Yoav Nir]

At the risk of stating the obvious, it’s because server owners want to use the 
same OpenSSL, NSS, SChannel, or whatever you call the Java library that 
everybody else uses. They’re all widely used, actively maintained, and 
essentially free.

None of these libraries support any of this functionality.

> On 15 Mar 2018, at 2:16, Watson Ladd  wrote:
> 
> One can either use a static DH share, save the ephemerals on the
> servers and export them, or log all the data on the servers.
> 
> These options don't require any change to the wire protocol: they just
> require vendors supporting them. Why don't they meet the needs cited?
> 
> Sincerely,
> Watson
> 
> ___
> 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] A question for TLS middle-box/middleware vendors/implementers

[Yoav Nir]

Hi, Thomas

Inline

> On 28 Jan 2018, at 12:19, Fossati, Thomas (Nokia - GB/Cambridge, UK) 
> <thomas.foss...@nokia.com> wrote:
> 
> Hi Yoav,
> 
> Thanks for the answers - much appreciated.
> 
> On 27/01/2018, 19:31, "Yoav Nir" <ynir.i...@gmail.com> wrote:
>> The length field is byte-aligned. So any implementation of a TLS
>> parser or TLS proxy will do one of two things:
>> 
>> 1. Consider the MSB to be a must-be-zero bit and drop any length field
>> that has it set as faulty.
>> 
>> 2. Ignore text about limits on length and assume the record is that
>> big. Depending on what field that is, this may cause a drop on some
>> other sanity check.
>> 
>> As always there’s option #3 (crash), but the industry is getting
>> better at avoiding that.
>> 
>> You seem to want the behaviour that the middlebox masks out the
>> must-be-zero bits and considers only the relevant length bits. I don’t
>> think that would pass code review at my former employer.
> 
> What I was thinking was rather "once handshake is done and client has
> successfully passed the SNI checks, just blindly copy the byte stream
> across." I had this specific mental model (that of an HTTPS filter) in
> my head, which of course is just one of many.

When middleboxes just classify and route (at Check Point we called that 
“passive inspection” as opposed to “active inspection” which was a TLS proxy) 
then yes - as soon as the data becomes encrypted you either drop it or let it 
through. As this is much higher performance (a given piece of hardware can 
handle much more passive inspection that it can active inspection), it was 
preferred for domains that were considered low-risk. 

TLS 1.3 means that a passive proxy needs to make the decision earlier.

> If the use case is "check for data exfiltration or covert channels",
> then the box is probably going to be a fully-fledged interception proxy.
> In that case the parser can't be sloppy, and the bit will not go through
> unnoticed (as you correctly note above).
> 
> But - pardon a naive mind -  these look like the kind of boxes that you
> can't just switch on and forget about.  Instead, I'd imagine you need to
> keep their release cycle aligned with that of the endpoints, especially
> browsers, which tends to be pretty aggressive.  (But yes, one thing is
> the vendor release cycle, and a completely different one is the network
> operator's upgrade schedule…)

Vendors release updates at a good pace, some through software upgrades and some 
through updating data files. An upgrade from supporting TLS 1.2 to supporting 
TLS 1.3 as a proxy usually requires a software upgrade. But the changes for 
passive proxy can be done through issuing an update to some regular expression 
or other rule. Typically customers buy a piece of software and subscribe to 
updates. 

The Internet is full of old versions because the administrators don’t don’t 
want to rock the boat or are content with a good, stable release, the same way 
that Windows 7 is still so popular. In some cases the middlebox vendor has gone 
out of business.

The Internet is also full of middleboxes where the subscription was allowed to 
lapse. It seems like carelessness. 

> Since you are here, and you have amassed a considerable amount of wisdom
> in this space, I have a further question: Is, in your opinion, DTLS in a
> better spot than TLS WRT the use of that bit?

With a firewall that doesn’t know about DTLS, there are three choices:
1. Allow all the DTLS
2. Block all the DTLS
3. Write a regular expression (or equivalent) that will check the DTLS 
handshake for sanity.

If DTLS becomes popular, newer versions of firewalls will be able to handle 
them the same as they do TLS. For now, DTLS is seeing little use.

Yoav

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

Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Yoav Nir]

> On 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) 
>  wrote:
> 
> Hi TLS middle-box/middleware folks,
> 
> If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
> set, how does your software react?
> 
> Is it going to drop the session/record or not bothering at all?
> 
> I'm trying to understand a bit better whether and when it'd be safe to
> grab that bit and give it new semantics (e.g., for signalling the
> presence of a DTLS connection-id, an ext-header, or anything else
> really) and your answers would help shedding some (*) light on the
> matter.
> 
> Based on previous experience on similar (but not identical) changes to
> the record format, Adam ([1], [2]) suggested that this bit is likely to
> have already ossified in TLS, whereas DTLS might be still OK.  So, I'm
> curious to hear from those who own the boxes' logics if they share the
> same opinion - in particular if DTLS is in better shape than TLS?
> 
> Thanks in advance for your time.
> 
> (*) I'm pretty sure not every TLS middle-box vendor on earth is
> subscribed to this list and, even among those who are, not everyone
> might be willing or able to share this information with the wider
> community.  This is to say that I'm aware of the limited value a poll
> like this has, but I'm not in a position to do a large-scale measurement
> campaign at the moment, so better start from somewhere... OTOH, I think
> there is a valuable discussion to be had in cases like this with folks
> that don't own the endpoints but are going to (or have already) put
> their logics on the e2e path, so hopefully I'm not wasting everyone's
> time :-)
> 
> cheers, t
> 
> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html
> [2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html 
> 

Hi, Thomas.

I don’t work for a middlebox vendor anymore, although I did only 8 months ago. 
This answer is not based on recently looking at code.

The length field is byte-aligned. So any implementation of a TLS parser or TLS 
proxy will do one of two things:

1. Consider the MSB to be a must-be-zero bit and drop any length field that has 
it set as faulty.

2. Ignore text about limits on length and assume the record is that big. 
Depending on what field that is, this may cause a drop on some other sanity 
check.

As always there’s option #3 (crash), but the industry is getting better at 
avoiding that.

You seem to want the behaviour that the middlebox masks out the must-be-zero 
bits and considers only the relevant length bits. I don’t think that would pass 
code review at my former employer.

HTH

Yoav

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

Re: [TLS] TLS 1.3 : small fragments attack

[Yoav Nir]

> On 30 Dec 2017, at 7:03, Peter Gutmann  wrote:
> 
> Jitendra Lulla  writes:
> 
>> The client can have a rogue TLS implementation with the following intentional
>> changes:
>> 
>> 0. Choose CBC with AES256-SHA56 or any other heavier (in terms of processing
>> power requirements) and non paralleliz'able  cipher suite.
>> 
>> 1. After the handshake, always send all the TLS records (Application Data)
>> plain text fragment size which is no greater than 1 Byte.
>> 
>> 2. Always send a padding of max possible or big size (eg 256 Bytes)
> 
> Apart from (2), that looks like interactive terminal traffic over TLS.  The
> large padding may also be natually sent by an implementation that's trying a
> bit too hard to hide typing/traffic patterns.

Right. If you really want to hide typing patterns, you should send a big record 
every tenth of a second. Most of those would be zero-length fragments, but 
that’s OK.

In fact, the rogue client can do even better by just sending a bunch of 
zero-length records.

Yoav

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

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

[Yoav Nir]

> On 15 Dec 2017, at 3:05, Colm MacCárthaigh  wrote:
> 
> 
> 
> On Thu, Dec 14, 2017 at 5:01 PM, Hanno Böck  > wrote:
> On Thu, 14 Dec 2017 16:45:57 -0800
> Colm MacCárthaigh > wrote:
> 
> > But what would that look like? What would we do now, in advance, to
> > make it easy to turn off AES? For example.
> 
> I think this is the wrong way to look at it.
> 
> >From what I'm aware nobody is really concerned about the security of
> AES. I don't think that there's any need to prepare for turning off AES.
> 
> Well, DJB is a notable concerned critic of AES and its safety in some 
> respects ... but I was using AES as kind of a worst-case scenario since so 
> many things do depend on it and it's especially hard to leave. I'm not aware 
> of some ground-breaking cryptanalysis :) But I do think the question is worth 
> having an answer for. I think we *do* need to prepare for turning off AES, 
> there's always a chance we might have to.

I think that was the point of standardizing ChaCha20-Poly1305.  In fact, that’s 
what is says in the second paragraph of the introduction in RFC 7539:

https://tools.ietf.org/html/rfc7539#section-1 


Yoav


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Tonight's Encrypted SNI Hangout Session

[Yoav Nir]

> On 14 Nov 2017, at 0:00, Tom Ritter  wrote:
> 
> Are you also interested in collecting reports of where SNI is used to
> censor? Or the list of network vendors that support filtering and
> manipulating traffic based on the value?

I don’t think naming and shaming is a goal here.

> In general, the bad uses of SNI are harder to enumerate because people
> aren't willing to come to the WG and explain how they use SNI to
> selectively break or censor the internet for their citizens/users.

I don’t think that’s true. I used to work for a vendor of a network firewall, 
and I can explain how this is done.

Inspecting the ClientHello to find the SNI for filtering is a weak way to do 
filtering. It’s also a light-weight way.  So if I want to filter Wikipedia, I 
match SNIs to "*.wikipedia.org” and I have my filtering. Depending on how many 
cycles I can spare, this is a cost-effective method. We have evidence that it’s 
been used for filtering, but sophisticated users can circumvent this - they can 
configure the browser to use TLS 1.0 and not send SNI at all.

More modern firewalls make a probing connection to the server, sending a 
ClientHello that is almost identical to the one sent by the real client and 
checking the returned certificate.  The names specified in that certificate are 
used for the filtering. That information is cached so that not every real 
ClientHello has to wait for a probing connection.  I don’t know if any vendor 
has made this scale to filter an entire country’s browsing, but this is 
considered to be more reliable than filtering by SNI.

> We
> have a few confirmed cases, anecdotal evidence, and lots of evidence
> of censors being technically applied by whatever means is available.
> 
> But when you pile up all the administrators who will come to the WG
> and say "This really frustrates me and makes my job harder" you're
> going to have a much bigger pile than the users (or even technical
> advocates like myself) we can bring in and say "Plaintext SNI is
> harming the Internet”.

IMO the real game-changer will be having an encrypted part to the ClientHello. 
If all ClientHellos are different, this defeats caching.

> 
>> Side question, it feels like this effort could represent a lot of work and
>> require a lot of dedicated cycles. Does it make sense to continue this
>> effort inside of the TLS WG?  If it does, will the WG give us the time,
>> mindshare, and cycles to focus on it (just asking the hard question)?
> 
> In August we adopted the draft, so the answer is "Yes".
> 
> -tom



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 8 Nov 2017, at 2:25, Watson Ladd  wrote:
> 
> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar  wrote:
>> FWIW: In my experience middleboxes don't ossify based on what the spec says,
>> they ossify based on what they see on the wire. So, if common
>> implementations send CCS in a particular way, that's what will get --- and,
>> I'll argue, what has gotten --- ossified. I also agree with David and Eric
>> that compatibility mode shouldn't be required because QUIC doesn't need it.
> 
> What does compatibility mode mean here? If we end up with having two
> slightly different versions of TLS 1.3, one that looks more like TLS
> 1.2 and the other that does not, that doesn't seem like a good thing
> to me.

So you’d prefer that we just make this compatibility mode mandatory and always 
use it?  Despite the wasted bits, I think I’m with you on that.

Yoav

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

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

[Yoav Nir]

> On 8 Nov 2017, at 2:32, Salz, Rich  wrote:
> 
> ➢ Given that we're almost there, and that only really browsers are
> asking for these hacks, and that even some of those were almost ready
> to ship without these hacks, I don't think that this is entirely
> unrealistic as an aspiration.
> 
> The Internet is more than just a couple of browser executables.
> 
> Does nobody think of the servers?
>  
> I do, but I don't really see how they're relevant for this question. Don't 
> the servers control the middleboxes they are behind?
>  
> The smiley got lost.  But smiley isn’t quite the right emoticon either. 

Maybe we need a resigned to the harsh reality emoticon. Oh wait, there is one 
[1]

> But to answer your question: no, the often don’t.  And it’s not just the 
> middleboxes they are behind, but all those along the way.

The server-side middleboxes tend to be somewhat higher quality and get more 
regular updates. There are also fewer vendors, so the problem is more 
manageable.

>  
> To say that only browsers were asking for these hacks is also a little 
> disingenuous.  It was a self-selected design group (to be charitable) that 
> mostly worked by themselves without the whole WG being involved.  I’m glad we 
> seem to be ending up with something that works, with the only thing being 
> lost is some nerd esthetics, but let’s not forget the (to me, disappointing) 
> way the whole thing went down: a collaboration among, and only among, Google, 
> Mozilla, and Facebook.

Sure. Whatever applies to browsers applies to every app or library that uses a 
web service. So wget, cURL, any of the libraries for Java, whatever you call 
the libraries behind apps on the various mobile platforms. 

Yoav 

[1] https://www.urbandictionary.com/define.php?term=%F0%9F%98%8C


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

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Yoav Nir]

Hi, Hannes.

I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot 
perform a MitM attack against the internal TLS. This can be achieved by having 
separate trust anchors for the application vs the ones used for HTTPS, 
specifically not including any “proxy CA certificate”.

Yoav

> On 7 Nov 2017, at 17:15, Hannes Tschofenig  wrote:
> 
> FWIW: I can tell you what the threat model was with the layered TLS work.
> 
> Let me give you a very specific example. Imagine a Bluetooth Low Energy
> device that communicates via a phone to a cloud-based service. The
> communication from the phone to the cloud uses HTTPS. The communication
> from the BLE device to the phone uses ordinary BLE
> services/characteristics.
> 
> The Layered TLS/application layer TLS would in this case run from the
> BLE device all the way to the cloud-based service at the application layer.
> 
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
> 
> Does this make sense?
> 
> Ciao
> Hannes
> 
> 
> On 11/07/2017 10:21 AM, Alex C wrote:
>> What exactly is the threat model here?
>> 
>> Are you trying to hide a connection from a reverse proxy at the server
>> end? If so, the server operator should not have deployed a reverse proxy
>> in the first place.
>> 
>> Are you trying to hide from a MITM proxy that supplies its own
>> certificate? If so, then what prevents the proxy from doing the same to
>> the tunnelled session?
>> When MITM proxies learn to do that, will we create another tunnelling
>> protocol inside this one?
>> 
>> This is a cat-and-mouse game with middleboxes (much like the version
>> negotiation problem, but in a different way). Keep playing and everyone
>> loses.
>> 
>> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > >> wrote:
>> 
>>Hey TLS folks,
>> 
>>Owen, Max, and I have been kicking around some ideas for how to make
>>secure connections in environments where HTTPS is subject to MitM /
>>proxying.
>> 
>>The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
>>creating a channel you could use when you really need things to be
>>private, even from the local MitM.
>> 
>>Feedback obviously very welcome.  Interested in whether folks think
>>this is a useful area in which to develop an RFC, and any thoughts
>>on how to do this better.
>> 
>>Thanks,
>>--Richard
>> 
>> 
>>On Mon, Oct 30, 2017 at 3:47 PM, > 
>>>> 
>> wrote:
>> 
>> 
>>A new version of I-D, draft-friel-tls-over-http-00.txt
>>has been successfully submitted by Owen Friel and posted to the
>>IETF repository.
>> 
>>Name:   draft-friel-tls-over-http
>>Revision:   00
>>Title:  Application-Layer TLS
>>Document date:  2017-10-30
>>Group:  Individual Submission
>>Pages:  20
>>URL:
>>https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt 
>> 
>>
>> > >
>>Status:
>> https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ 
>> 
>>> >
>>Htmlized:
>> https://tools.ietf.org/html/draft-friel-tls-over-http-00 
>> 
>>> >
>>Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 
>> 
>>> >
>> 
>> 
>>Abstract:
>>   Many clients need to establish secure connections to application
>>   services but face challenges establishing these connections
>>due to
>>   the presence of middleboxes that terminate TLS connections
>>from the
>>   client and restablish new TLS connections to the service.  This
>>   document defines a mechanism for transporting TLS records in HTTP
>>   message bodies between clients and services.  This enables
>>clients
>>   and services to establish secure connections using TLS at the
>> 

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

[Yoav Nir]

> On 24 Oct 2017, at 22:54, David A. Cooper  wrote:
> 
> Why would these schools settle for a half measure that only allows them to 
> snoop on traffic between their students and servers provide the keys to their 
> Internet traffic to the schools? If a school wants to snoop on its students' 
> traffic, it would do so in a much easier way than using 
> draft-rhrd-tls-tls13-visibility, in the same way that some enterprises today 
> use middleboxes to inspect all outgoing traffic.

Yeah. I used to write such middleboxes. They’re a nightmare to deploy in all 
but the most orderly of enterprises. You need to have all clients trust the 
middlebox CA. Fine, so the Windows computers get that installed through SMS or 
GPO or whatever the central configuration feature is called these days. The 
people with Macs have to figure it out for themselves, and the same goes for 
people with phones. Oh, and also for people who use Firefox, because that 
browser comes with its own trust store. The people on this list can probably 
figure it out with a little web search. A school with a thousand students all 
bringing their own devices? Good luck.

> This browser that students would be required to use would be one that has a 
> CA controlled by the middlebox installed as a trust anchor. Whenever one of 
> the students' clients tries to connect to an external secure site, the 
> middlebox-controlled CA issues a certificate for that site so that the 
> connection can be terminated at the middlebox. The middlebox then establishes 
> a secure connection with the end server, thus setting up the middlebox as a 
> MiTM.

It’s one thing to say that SchoolBrowser (conveniently located in the app 
stores of all phone and computer OS-es) works in this school (and all the 
others).  It’s a totally different thing to fill the app stores with 
“GrizzlyBrowser for Logan High School students” and “MustangBrowser for 
Mountain Crest High School students"

> There are already middleboxes on the market today that do this. They work for 
> all outgoing connections and don't require any cooperation whatsoever from 
> the outside servers that the clients are trying to connect to, and only 
> expert users would notice the presence of the MiTM.

Unless they had to configure their browser themselves.  The support costs of 
these is tremendous.


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

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

[Yoav Nir]

> On 24 Oct 2017, at 22:27, Ralph Droms  wrote:
> 
> 
>> On Oct 24, 2017, at 3:23 PM, Salz, Rich  wrote:
>> 
>> I use an airplane as an example of a “captive” population, substitute any 
>> similar group you want.
>> 
>>  • Yes, any box that sits between the client and the server can drop 
>> traffic for whatever reason it wants. Such a box could today drop any 
>> traffic that is protected using TLS.
>> 
>> True, but that’s not the point.  The point is by adding this extension into 
>> the clientHello, we are providing middleboxes with another knob to control 
>> traffic.  I think we want to avoid that. And keep in mind it’s not just 
>> HTTP, but *any* TLS-using traffic, such as many VPN’s.  It wouldn’t 
>> necessarily enable spying, but it could be used to guarantee that all 
>> traffic is amenable to spying.
>> 
>> As for how would such clients get promulgated?  Some simple scenarious 
>> include “surf for free on your flight, but use our Chromium-based browser to 
>> do so, available for free here.”How many people on the plane would click 
>> and download?
> 
> Just to make sure I understand, in this scenario the special-purpose browser 
> could just as easily, today, be a browser with no TLS at all?   That is, I 
> don't see why this scenario is specific to the visibility extension.

Think of the children.

We can’t just let them loose on the Internet, there’s predators out there. So 
we will snoop on their traffic.  To do that, we block all traffic that isn’t 
snoopable, and we do it at the edge router in schools.  All schools in our 
state are required by law to install a firewall that does this. And we get the 
mobile operators to do so as well (only for handsets in schools).

Now either the mobile OS vendors make a browser that works in schools (at least 
with a setting), or the school recommends a third party browser that works in 
school. And best of all, this is *more secure* than regular TLS 1.3, because it 
also protects your children from Internet predators. Think of the children.

You can’t make a claim like that for an HTTP-only browser, and worse still, it 
won’t work on much of today’s Internet.

Yoav

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

Re: [TLS] editorial error in draft-ietf-tls-rfc4492bis-17

[Yoav Nir]

Thanks, Martin. This is correct.

So there are two ways to fix this:
As Martin suggests, make TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA one of the MTI 
instead of the current, or
Add 0xC0,0x23 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256) to the list of 
ciphersuites.

The first seems more consistent to me.

Chairs: guidance?  Note that the document is in the RFC editor queue so we’ll 
need AD approval for the change at this late date. 

Thanks

Yoav

> On 24 Oct 2017, at 16:22, Martin Rex  wrote:
> 
> I just noticed a strange inconsistency in section 6 of
> draft-ietf-tls-rfc4492bis-17
> 
>https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-17#section-6
> 
> The last of the "must implement 1 of these 4" list of cipher suites at
> the end of section 6 is not contained in the table at the beginning of
> section 6 above it (instead, it appears in rfc5289 only).
> 
> I believe that the last ciphersuites should be changed (which will
> provide consistence with the second list entry (the TLSv1.2 MTI cipher suite).
> 
> 
> -Martin
> 
> 
>   +-++
>   | CipherSuite | Identifier |
>   +-++
>   | TLS_ECDHE_ECDSA_WITH_NULL_SHA   | { 0xC0, 0x06 } |
>   | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA   | { 0xC0, 0x08 } |
>   | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA| { 0xC0, 0x09 } |
>   | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA| { 0xC0, 0x0A } |
>   | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } |
>   | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } |
>   | ||
>   | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |
>   | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
>   | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA  | { 0xC0, 0x13 } |
>   | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA  | { 0xC0, 0x14 } |
>   | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   | { 0xC0, 0x2F } |
>   | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   | { 0xC0, 0x30 } |
>   | ||
>   | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
>   | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
>   | TLS_ECDH_anon_WITH_AES_128_CBC_SHA  | { 0xC0, 0x18 } |
>   | TLS_ECDH_anon_WITH_AES_256_CBC_SHA  | { 0xC0, 0x19 } |
>   +-++
> 
> 
>   Server implementations SHOULD support all of the following cipher
>   suites, and client implementations SHOULD support at least one of
>   them:
> 
>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> +  o  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
> -  o  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> 
> ___
> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Yoav Nir]

> On 22 Oct 2017, at 21:40, Ted Lemon  wrote:
> 
> On Oct 22, 2017, at 1:54 PM, Russ Housley  > wrote:
>> No one is requiring TLS 1.3 that I know about.  However, there are places 
>> that require visibility into TLS.  I will let one of the people that works 
>> in a regulated industry offer pointers to the documents.
> 
> What they require is visibility into contents of the flow that they are using 
> encryption to protect.   Right now, the protocol they are using is TLS 1.1 or 
> TLS 1.2.   The right thing for them to do if they continue to need this 
> visibility and are no longer permitted to use TLS 1.2 is to use IPsec+IKE,

Right, and shamelessly plugging my working group, I2NSF has recently adopted a 
draft ([1]) that is aimed at enabling and automating the deployment of 
IKE/IPsec in the datacenter.

> or some protocol that is designed for this use case, not to take a protocol 
> designed specifically for securing flows from on-path eavesdropping and 
> create a mode where it is easier to wiretap.
> 
> There is no reason other than momentum for them to switch to TLS 1.3 when it 
> doesn't address their use case.

[1] https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Yoav Nir]

> On 7 Oct 2017, at 17:17, Nick Sullivan  wrote:
> 
> Yoav,
> 
> Let me make a correction to your scenario:. Instead of:
> "You’ll need it for Chrome to work with Google."
> it's:
> "You’ll need it for Chrome to work with Google, Facebook, and most of the 10% 
> of Alexa top million sites that are using Cloudflare.”

What part of “not making any configuration changes until the second week of 
January” is not clear to you?

Seriously, I’ve had this conversation with administrators.

Because if they go to their bosses, they get asked if they can guarantee that 
the update will cause no outage. Of course they can’t.

Then they get asked if Edge has the same problem. Let’s assume the answer is 
yes.

Then they get asked if they can turn off TLS 1.3 in Edge using GPO (or whatever 
the remote configuration of Microsoft Windows is called these days). In all 
likelihood, the answer is yes.

Problem sovled, no?

But, they’ll protest, more than half our employees use Chrome.

So tell them not to use Chrome, says the manager.

Because for the manager the decision to update the middlebox is all risk with 
no rewards.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Yoav Nir]

> On 7 Oct 2017, at 4:01, Salz, Rich  wrote:
> 
> Thanks very much for the update.
> 
> There is a third option, name the devices which are known to cause problems, 
> and move forward with the draft as-is.

+1.  I like this third option.

> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customers,

Vendor: Hello customer. We have an update for you that will make TLS 1.3 work.

Customer: No way. We’re in the middle of the year-end processing. We’re not 
making any configuration changes until the second week of January.

Vendor: But it’s a simple fix. It will make things work better. You’ll need it 
for Chrome to work with Google.

Customer: What part of “not making any configuration changes” was not clear to 
you!?


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Should CCM_8 CSs be Recommended?

[Yoav Nir]

> On 4 Oct 2017, at 16:29, Russ Housley <hous...@vigilsec.com> wrote:
> 
> 
>> On Oct 4, 2017, at 3:30 AM, Yoav Nir <ynir.i...@gmail.com 
>> <mailto:ynir.i...@gmail.com>> wrote:
>> 
>>(IoT) - This requirement is for interoperability with IoT.  Only
>>128-bit keys are at the given level.
> If the IoT environment is willing to accept lower integrity protection in 
> order to save a few bits on the wire/ether, I do not see why the 
> specification also forces them from using a larger key size.
> 
> Russ
> 

Maybe to save a few cycles in addition to the few bits?  They claimed that the 
one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, because that was 
all that their hardware supports.

What we are saying is that if you want your (in that case IPsec, but it’s no 
different for TLS) to work with IoT devices, you need that AEAD cipher.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Should CCM_8 CSs be Recommended?

[Yoav Nir]

What we did in IPsec in RFC-tp-be 8221 is the following.  This (including the 
IoT marker) is also going to appear in the IANA registry:
+-++-++
| Name| Status | AEAD| Comment|
+-++-++
| ENCR_DES_IV64   | MUST NOT   | No  | UNSPECIFIED|
| ENCR_DES| MUST NOT   | No  | [RFC2405]  |
| ENCR_3DES   | SHOULD NOT | No  | [RFC2451]  |
| ENCR_BLOWFISH   | MUST NOT   | No  | [RFC2451]  |
| ENCR_3IDEA  | MUST NOT   | No  | UNSPECIFIED|
| ENCR_DES_IV32   | MUST NOT   | No  | UNSPECIFIED|
| ENCR_NULL   | MUST   | No  | [RFC2410]  |
| ENCR_AES_CBC| MUST   | No  | [RFC3602][1]   |
| ENCR_AES_CCM_8  | SHOULD | Yes | [RFC4309](IoT) |
| ENCR_AES_GCM_16 | MUST   | Yes | [RFC4106][1]   |
| ENCR_CHACHA20_POLY1305  | SHOULD | Yes | [RFC7634]  |
+-++-++

   [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit
   keys remain at the MAY level.

   (IoT) - This requirement is for interoperability with IoT.  Only
   128-bit keys are at the given level.

   IPsec sessions may have very long lifetime and carry multiple
   packets, so there is a need to move to 256-bit keys in the long term.

> On 4 Oct 2017, at 5:54, Eric Rescorla  wrote:
> 
> Generally I tend to agree we should remove these, but as Jim said, there are 
> reasons where I guess they make sense. Could we add a "Special Circumstances" 
> marking?
> 
> -Ekr
> 
> 
> On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner  > wrote:
> In the IANA registries draft 
> (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates 
> ), we’ve added 
> a recommended column to the Cipher Suites (CSs) registry (and some others).  
> Right now, the criteria for getting a recommended mark is AEAD ciphers with 
> strong authentication standards track ciphers.  While that’s great generally, 
> the list we’ve got five CSs that gave Joe and I pause:
> 
> TLS_DHE_RSA_WITH_AES_128_CCM_8
> TLS_DHE_RSA_WITH_AES_256_CCM_8
> TLS_PSK_DHE_WITH_AES_128_CCM_8
> TLS_PSK_DHE_WITH_AES_256_CCM_8
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
> 
> The CCM_8 CSs have a significantly truncated authentication tag that 
> represents a security trade-off that may not be appropriate for general 
> environment.  In other words, this might be great for some IoT device but we 
> should not generally be recommending these.
> 
> We’re recommending that these five suites be dropped from the recommended 
> list.  Please let us know what you think.
> 
> J
> (editor hats on)
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Is there a way forward after today's hum?

[Yoav Nir]

> On 20 Jul 2017, at 8:01, Russ Housley  wrote:
> 
> Ted, if we use a new extension, then the server cannot include it unless the 
> client offered it first.  I am thinking of an approach where the server would 
> include information needed by the decryptor in the response.  So, if the 
> client did not offer the extension, it would be a TLS protocol violation for 
> the server to include it.
> 

So we also add an alert called “key-export-needed” in case the client does not 
include it.

That way a browser (as an example) can show the user why the connection was 
broken (“server requires wiretapping to be enabled. Go to about:config 
 if that is OK and change the allow-wiretap setting to True”)





signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 19 Jul 2017, at 17:07, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
 This is exactly right.   We have a real problem here.   We should really 
 solve it.
 We should do the math.   :)
>>> 
>>> Is there appetite to do this work? If we restrict this to two paths, one of 
>>> which is
>>> spending years designing and implementing a new multi-party security 
>>> protocol,
>>> the other of which is silently and undetectably (at least on private 
>>> networks) modifying
>>> the standardized protocol for which lots of well-tested code already 
>>> exists...
>>> my money is on the latter happening.
>> 
>> There is a good chance that this "cheaper" solution is what will happen.
> 
> Sure. The point is that IETF *must not* support such “undetectable 
> modifications of a standard protocol”.
> The fact that crime invariably happens does not imply that we should become 
> criminals. ;-)
> 
>> However the multi-party protocol may be a safer and better approach and may 
>> even
>> forced in by some regulators when it exists as an implemented alternative.
> 
> IETF is supposed to be about designing and (until a decade or so ago) 
> implementing the *right* solutions. In this case multi-party protocol  
> appears to be “it”.
> 
> So let those who need this capability spearhead the design, with 
> cryptographers and academia helping that work or at least auditing the 
> results.
> 
>>> In every decision we make with respect to the static DH approach, we have 
>>> to keep
>>> in mind that this change can be implemented unilaterally, i.e., without any 
>>> modifications
>>> for interop. Consequently, I think the work we really need to do is to 
>>> design and implement
>>> a FS-breakage detector so we can at least tell when this is happening on 
>>> the public internet.
> 
> I agree. Though I don’t know off-hand if this is technically possible. 
> Because as you pointed out, an end-point can always choose to leak its part 
> out-of-band, and there’s nothing his communicating peer can do about it 
> (AFAIK). (We can at least make sure that the official implementations such as 
> OpenSSL and GnuTLS do not include such “extensions”.)
> 
> Still, a multi-party protocol that makes the presence or absence of such 
> monitoring explicit, would be the best option, IMHO.

At the very least, a standards-track multi-party protocol like that can be 
something that standards like PCI, HIPAA and others can latch on to and say “Do 
TLS 1.3 without backdoors unless you really need to and in that case use 
*this*”.

That is better guidance than “Do TLS 1.3 without backdoors, unless you really 
need to and in that case do whatever works for you"


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 17:06, Roland Dobbins  wrote:
> 
> On 16 Jul 2017, at 11:19, Salz, Rich wrote:
> 
>> The key point here is Within the enterprise.
> 
> +1

It’s an illusion that inside the enterprise uses different technologies than 
outside the enterprise. IP was for outside, and yet it’s all over the inside.

In the end, either this is in OpenSSL (perhaps plus a patch) or it’s not. 
Either it’s in SChannel or it’s not. Either F5 have it or they don’t.

If it’s not, it will be impossible to deploy in the enterprise network. They’re 
not all going to implement it themselves. And if it is, then it’s on the open 
Internet, and then at least some people will have it turned on. The border 
between the enterprise and the non-enterprise is pretty blurry.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 16:20, Roland Dobbins <rdobb...@arbor.net> wrote:
> 
> On 17 Jul 2017, at 16:15, Yoav Nir wrote:
> 
>> Obligatory XKCD link:
> 
> This one is actually more relevant, IMHO:
> 
> <https://xkcd.com/538/>

ISTM that this is a great argument *against* allowing the administrators in the 
data center to be able to access the plaintext.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 17 Jul 2017, at 13:48, Salz, Rich  wrote:
> 
>>> DDoS mitigation can be done at endpoints
>> 
>> Not at scale.  That's why it isn't done that way.
> 
> Sometimes it is.
> 
> Can we stop making definitive declarations like this?
> 
> There are more things in the world, Horatio, then are dreamt of in your 
> philosophy.

Obligatory XKCD link:

https://xkcd.com/1737/ 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 15 Jul 2017, at 9:12, Daniel Kahn Gillmor  wrote:
> 
> On Sat 2017-07-15 05:58:31 +, Salz, Rich wrote:
>> Unless I missed the reply, I did not see any answer to my question as
>> to why it must be opt-in.  Do we think evildoers will tell the truth
>> about what they are doing?
> 
> Because presumably the people who do *not* want to do evil want to avoid
> specifying a mechanism that will be widely implemented that could leak
> into use outside of the intended scenario.  right?
> 
> As far as i can tell, we're all in agreement here that:
> 
> * This proposed TLS variant is *never* acceptable for use on the public
>   Internet.  At most it's acceptable only between two endpoints within
>   a datacenter under a single zone of administrative control.

This TLS variant is only about using the same key share for a while. This is 
already done for optimization (as in “use the same key share for 1 minute 
before generating a new one”) although I guess for decryption a key would be 
used for longer than a minute.

The one difference between reusing a key share for optimization and reusing a 
key share for decryption is whether or not the server dumps this key share to 
disk. That is not a difference in TLS. In fact these two are indistinguishable. 
And that brings us back to Rich’s question: Do we expect evildoers to signal 
that they’re doing this?


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall  wrote:
> 
> Just want to +1 the notion that this should be opt-in for both sides and in 
> an extension!

It’s a good notion, but “we have to change one side” usually wins over “we have 
to change both sides”




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Yoav Nir]

> On 12 Jul 2017, at 0:21, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> 
> 
> 
> On 11/07/17 22:10, Yoav Nir wrote:
>> If one of the parties to a conversation cooperates with the wiretap,
>> this isn’t an attack.
> Lemme try on this one again from a different angle.
> 
> In classic telephony wiretaps the carrier does the
> tap. There are similar situations with TLS...
> 
> In hosted platforms (e.g. wordpress.com and many
> others) where the senders and receivers (or publishers
> & readers) have read and write access via PHP code
> and not via a shell, and cannot therefore control web
> or TLS configuration, the platform would be doing a
> wiretap if it turned this on, whilst colluding with
> or being coerced by some other entity that collects
> and later decrypts the ciphertext and packets.
> 
> Are we agreed that that use-case is wiretapping via
> this mechanism?
> 
> There are many millions of people who use such
> constrained hosted environments.

Wordpress.com <http://wordpress.com/> is a party to the session. It has access 
to the plaintext and could deliver it to whatever third party whenever they 
wanted. This draft may be an optimization, but the plaintext was always theirs 
to give.

I might be deluding myself that I’m sending this email to you over TLS. In fact 
I’m only uploading it to gmail.com <http://gmail.com/> who will forward it to 
TCD’s server. Both servers will have access to the plaintext. Both servers can 
send it to a third party, or share session keys or share ECDHE private keys.

Whether one party to a conversation (phone or IP) has the right to share 
private contents with a third party is a legal matter that varies from country 
to country and from state to state. I only claim that this draft does not 
change the fact that is true for PFS suites in TLS 1.x and for all suites in 
TLS 1.3, that it’s impossible to decrypt a recorded session without cooperation 
from either party, and that cooperation has to start *before*  the session is 
recorded.

That is not the case for POTS wiretap or for the RSA key exchange.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Yoav Nir]

> On 11 Jul 2017, at 23:54, Christian Huitema  wrote:
> 
> On 7/11/2017 1:31 PM, Stephen Farrell wrote:
> 
>> PS: There are also genuine performance reasons why the same
>> DH public might be re-used in some cases, so there would be
>> false positives in a survey to consider as well.
> 
> Well, yes. The classic argument is performance. Saving the cost of
> exponentiation, computing G^X once for many session instead of once per
> session. But you reap most of the benefits of that optimization with a
> fairly small number of repetitions. Performance alone is not a good
> reason to use the key over extended period, not to share the exact same
> key between all servers in a farm. The fact is that wide reuse of the
> same (EC)DH private key does compromise the security of TLS -- including
> an obvious issue with forward secrecy.

I don’t think the number of times (within reason) a key is used matters that 
much. It only matters whether or not it is exportable. If a server 
implementations generates a fresh key for every session and then stores it in a 
database that maps public key to private key, then that database can trivially 
be used to decrypt all traffic. Conversely, an implementation could generate a 
key in memory and use it until reboot and as long as it’s not exported, nothing 
happens.

I once implemented an ECDHE TLS server with an in-memory key that was rotated 
every 10 seconds. Since it was never written to disk (or even paged out) this 
practice did not compromise forward secrecy.

The draft also recommends rotating the keys, but I guess that would be far less 
often than once every 10 seconds. But that is not the crucial difference. The 
crucial difference is that these keys get exported.

Note, however, that the reason RSA ciphersuites were deprecated is that we are 
afraid that a stolen or coerced private key will compromise past sessions. If 
the session between us is recorded today and someone steals or demands my 
private key tomorrow, than they can decrypt our conversation from today.

This is not the case in (EC)DHE  ciphersuites in TLS 1.2 or 1.3. Any session 
that happens before this mechanism is turned on, is safe. Sessions can only be 
compromised after the server has enabled this feature, which is equivalent to 
handing over the RSA private key in RSA ciphersuites. That is not the forward 
secrecy issue that we wanted to solve by removing RSA ciphersuites.  If one of 
the parties to a conversation cooperates with the wiretap, this isn’t an attack.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Yoav Nir]

> On 10 Jul 2017, at 17:16, Stephen Farrell  wrote:
> 
> 
>> 2.  this proposal offers
>> significantly better security properties than current practice
>> (central distribution of static RSA keys)
> 
> I fail to see any relevant difference in security properties
> between those two, never mind a significant improvement.

I can see one way in which it is worse.

With static RSA keys, you can configure the server to use only PFS ciphesuites 
(ECDHE-RSA or DHE-RSA). If you want to enable the non-FS, you need to switch to 
RSA ciphersuites, and that would be obvious to any client.  In fact, I think 
today a server would stick out if it only supported RSA ciphersuites.

There is no way to know that a server is doing what it says in the draft. It’s 
completely opaque to the client.

However, in both cases the server does get FS. As long as the server has not 
enabled RSA ciphersuites or exportable private key shares, any recorded TLS 
stream is safe even if the attacker later gets the private key.

Yoav


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Yoav Nir]

> On 8 Jul 2017, at 18:39, Tony Arcieri  wrote:
> 
> I was one of the people arguing my hardest against the BITS Security proposal 
> to continue to (ab)use RSA static keys to allow passive MitM, even though TLS 
> 1.3 had already moved forward on what I would call a more modern protocol 
> design of the sort I believe payments companies should embrace to improve 
> their security.
> 
> That said, if people do want to MitM themselves, I would rather there be a 
> single, easily detectable and very explicit way of doing so, as opposed to 
> sketchy, incompatible, ad hoc mechanisms.

But all the MITM solutions, whether proxies or static DH are not easily 
detectable. Client-side proxies - the kind deployed by enterprises - are 
visible to clients (by the CA signing the proxy certificates) but not to the 
servers. This is implemented on the server, but is invisible to the client.  
Even if the client rapid-fires several handshakes to see if the public key does 
not change, this is indistinguishable from the optimization of using the same 
key-pair for several seconds (without saving the private key).

> Furthermore, it would be nice to have a clear answer for these users, less 
> they continue to make (bad) arguments that there is something fundamentally 
> wrong with the design of TLS 1.3 that makes it incompatible with "industry 
> requirements".
> 
> Clearly there are echoes of the scary protocols of yesteryear, i.e. 
> Clipper/LEAP. I think if you visit Matt Green's Twitter page and check the 
> image header you will discover he is quite familiar with these things, and my 
> personal presumption would be he is not displaying this image to show his 
> undying love of the Clipper chip, although perhaps he's an especially crafty 
> and duplicitous NSA sleeper agent.

It’s not about the reputations or motivations of the impressive list of 
authors. It’s about having the capability built into widely used products and 
libraries.

Suppose you have an Internet-facing server with TLS 1.2 and an ECDSA 
certificate and all supported ciphersuites are ECDHE-ECDSA.Suppose further that 
your server is using the ever popular Apache/modssl/openssl stack.

If you want to disable forward secrecy you have to either replace the 
certificate with an RSA certificate and move to all static RSA ciphersuites, or 
you need to replace your stack with something that does what this draft 
describes.

With this draft widely implemented it’s just a matter of turning the capability 
on.

We can’t really stop people implementing it, It’s not detectable by the client 
and an implementation would seem to be fully compliant with TLS 1.3.  And I 
don’t know how to implement this in such a way that it would work for “good” 
purposes but not for “bad” purposes, however one defines good and bad here.


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 8 Jul 2017, at 6:18, Timothy Jackson  wrote:
> 
> As an earlier poster asked, what advantage does this approach have over 
> TLS-inspecting proxies? Every IPS/IDS/next gen firewall with which I am 
> familiar is able to terminate at TLS connection, inspect/copy/filter, and 
> then encrypt on a new TLS sessions.
> 
> For high performance customers, the SSL accelerators can be sandwiched around 
> the filter so all the crypto is done in hardware.
> 
> The ways to prevent TLS inspection are cert pinning and client cert auth. If 
> this is only within one's data center, then those features can be disabled if 
> necessary, no?
> 
> What use case am I missing that can't be achieved better by other means than 
> static keys?

They would like to store traffic captures encrypted and be able to decrypt them 
a little later if that is necessary. Storing plaintext is something that 
auditors (rightfully!) don’t like.

They also don’t want to install TLS proxies all over the place.  That’s a large 
extra expense for them.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Separate APIs for 0-RTT

[Yoav Nir]

> On 23 Jun 2017, at 5:10, Timothy Jackson  wrote:
> 
> +1 and a preference for MUST, just so people understand the importance.
> 
> Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same 
> security properties once the handshake completes, it seems to me, unless I've 
> missed something, that a lot of protocols will accept 0-RTT but withhold the 
> response until after the handshake completes. I expect this massively 
> simplifies the analysis the for the app developers.
> 
> Clientdata = readData()
> Reply = CreateReply(client data); //time intensive operation (e.g. Database, 
> CDN cache lookup)
> 
> While(!clientFinished())
> Wait(); //do nothing until 1-RTT finished
> 
> Send(reply)

This assumes that CreateReply() has no side effects. It’s valid as long as all 
actions done by the server in response to the client data is getting stuff from 
a database.

> 
> This has the benefit of allowing slow lookups/processing to happen against 
> 0-RTT, while delaying the "risky actions" until after 1-RTT. If I'm not 
> mistaken, it would also make timing attacks harder since any cache misses 
> would be at least partly masked by the time required for the 1-RTT handshake.
> 
> Dual streams seems to just add complexity here. What I really care about as a 
> developer is whether I can fully trust the 0-RTT data, which is determined by 
> whether the handshake is finished.
> 
> Cheers,
> 
> Tim
> --
> Tim Jackson
> 
> Senior Product Security Architect, MobileIron Inc.
> 
> 
> From: "Martin Thomson"  >
> Date: Thursday, June 15, 2017 at 5:16:29 PM
> To: "David Benjamin" >
> Cc: "tls@ietf.org" >
> Subject: Re: [TLS] Separate APIs for 0-RTT
> 
> On 15 June 2017 at 08:23, David Benjamin  wrote:
> > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a
> > way for the application to determine if the client Finished has been
> > processed.
> 
> 
> I'm going to throw my support behind this distinction.  Though I would
> phrase this more simply as "the handshake is complete".
> 
> ___
> 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 
> 


signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 5 Jun 2017, at 6:06, Bill Cox  wrote:
> 
> On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk  > wrote:
> 
> Do we have a good example of why a non-safe HTTP request in 0-RTT would lose 
> specific properties required for security?  If so, that seems like a good 
> thing to include in the TLS 1.3 spec as an example of what can go wrong.
> 
> -Ben
> 
> I like the example of a POST request saying "send Alice $10".  It is a 
> request that sophisticated web services will avoid, yet many smaller and less 
> security savvy sites will continue to support requests like this, so I think 
> it is worth considering.
> 

I once saw a router with an HTTPS administration UI that would respond as you’d 
expect to:

GET mainpage.html?action=rebootDevice

Worse. The router was a firewall and this worked:

GET mainpage.html?action=disablePolicy

Yes.  GET. POST also worked, but for some reason the WebUI generated POSTs.

Of course, it was really secure because the GET was accompanied by a cookie, 
but I guess the cookie would fit in the early data. Not sure if it would 
survive a reboot, though.

Yoav





signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AD Review of draft-ietf-tls-tls13

[Yoav Nir]

> On 22 May 2017, at 20:27, Benjamin Kaduk  wrote:
> 
> On 05/22/2017 12:17 PM, Viktor Dukhovni wrote:
>>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk  
>>>  wrote:
>>> 
>>> Given the apparent strength of opinion against removing these supposed 
>>> restrictions entirely, it seems like this text (or something similar) is 
>>> probably the best we can do.
>> Perhaps so, but I saw only one strong objection from Dave Garrett.  Is that
> 
> There was also some discussion when this text was originally going in, IIRC.  
> But I do not remember well enough to say who/how many people wanted it.

This came up in one of the F2F meetings. I believe I argued that we shouldn’t 
have PKIX policy in a TLS document, because if signing certificates with SHA-1 
is bad, it’s bad for all users of certificates, and should be prohibited by a 
PKIX document, not a TLS document.

The room was against me then. So it may look now like it’s just Dave (and now 
Rich), there was more support for this at the time.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Yoav Nir]

Hi.

Draft-17 submitted.

Yoav

> On 4 May 2017, at 23:09, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> 
> wrote:
> 
> Yoav,
> 
> On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> On 4 May 2017, at 16:09, Kathleen Moriarty
>> <kathleen.moriarty.i...@gmail.com> wrote:
>> 
>> I haven't approved it yet as I noticed there was no response (that I saw) to
>> Alexey's comment and no change in the draft as a result of his comments.
>> 
>> 
>> 
>> You mean these comments?
>> https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0
>> 
>> I’ll quote them here:
>> 
>> 0) There is some general awkwardness in text talking about allowed points
>> formats, considering that only uncompressed form is now allowed. I don't
>> have recommendations about improving text, other than the following:
>> 
>> If no future formats are expected, it feels almost better to recommend
>> against inclusion of the Point formats extension, as lack of it means
>> uncompressed format anyway.
>> 
>> So this was addressed in draft -16:
>> 
>> OLD:
>> 
>>  Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  For
>>   backwards compatibility purposes, the point format list extension
>>   MUST still be included, and contain exactly one value: the
>>   uncompressed point format (0).
>> 
>> 
>> NEW:
>> 
>>  Implementations of this document MUST support the
>>   uncompressed format for all of their supported curves, and MUST NOT
>>   support other formats for curves defined in this specification.  For
>>   backwards compatibility purposes, the point format list extension MAY
>>   still be included, and contain exactly one value: the uncompressed
>>   point format (0).  RFC 4492 specified that if this extension is
>>   missing, it means that only the uncompressed point format is
>>   supported, so interoperability with implementations that support the
>>   uncompressed format should work with or without the extension.
>> 
>> 
>> 
>> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
>> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
>> moved to section 2.
>> 
>> 
>> The content of the last paragraph was moved to a new section:
>> 
>> 2.4.  Algorithms in Certificate Chains
>> 
>>   This specification does not impose restrictions on signature schemes
>>   used anywhere in the certificate chain.  The previous version of this
>>   document required the signatures to match, but this restriction,
>>   originating in previous TLS versions is lifted here as it had been in
>>   RFC 5246.
>> 
>> 
>> 
>> 2) In Section 6:
>> 
>>   Server implementations SHOULD support all of the following cipher
>>   suites, and client implementations SHOULD support at least one of
>>   them:
>> 
>>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
>> 
>> GCM ciphers are not listed in the table earlier in the same section. They
>> are defined in RFC 5289. This document doesn't have any reference to RFC
>> 5289 and GCM ciphers are not discussed anywhere else in the document.
>> 
>> 
>> Seems like I missed this one.
> 
> Thanks, let me know when the update is ready.
> 
>> 
>> Yoav
>> 
>> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Yoav Nir]

Thanks!  That would have been an embarrassing erratum.


> On 5 May 2017, at 14:31, Hubert Kario <hka...@redhat.com> wrote:
> 
> On Thursday, 4 May 2017 19:59:29 CEST Yoav Nir wrote:
>>> 2) In Section 6:
>>>   Server implementations SHOULD support all of the following cipher
>>>   suites, and client implementations SHOULD support at least one of
>>>   them:
>>> 
>>>   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> 
> 
> looks like an "E" is missing here
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

[Yoav Nir]

> On 4 May 2017, at 16:09, Kathleen Moriarty  
> wrote:
> 
> I haven't approved it yet as I noticed there was no response (that I saw) to 
> Alexey's comment and no change in the draft as a result of his comments.


You mean these comments?
https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0 


I’ll quote them here:

> 0) There is some general awkwardness in text talking about allowed points
> formats, considering that only uncompressed form is now allowed. I don't
> have recommendations about improving text, other than the following:
> 
> If no future formats are expected, it feels almost better to recommend
> against inclusion of the Point formats extension, as lack of it means
> uncompressed format anyway.
So this was addressed in draft -16:

OLD:
  Implementations of this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension
   MUST still be included, and contain exactly one value: the
   uncompressed point format (0).

NEW:
  Implementations of this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension MAY
   still be included, and contain exactly one value: the uncompressed
   point format (0).  RFC 4492  specified 
that if this extension is
   missing, it means that only the uncompressed point format is
   supported, so interoperability with implementations that support the
   uncompressed format should work with or without the extension.


> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
> moved to section 2.

The content of the last paragraph was moved to a new section:
2.4 .  
Algorithms in Certificate Chains

   This specification does not impose restrictions on signature schemes
   used anywhere in the certificate chain.  The previous version of this
   document required the signatures to match, but this restriction,
   originating in previous TLS versions is lifted here as it had been in
   RFC 5246 .

> 
> 2) In Section 6:
> 
>Server implementations SHOULD support all of the following cipher
>suites, and client implementations SHOULD support at least one of
>them:
> 
>o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> 
> GCM ciphers are not listed in the table earlier in the same section. They
> are defined in RFC 5289. This document doesn't have any reference to RFC
> 5289 and GCM ciphers are not discussed anywhere else in the document.

Seems like I missed this one.

Yoav




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

[Yoav Nir]

Hi.

So I’ve just submitted PR #931 to resolve this.

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


Yoav

> On 28 Mar 2017, at 23:31, Dave Garrett  wrote:
> 
> On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote:
>> I didn’t bring this up in the meeting this morning, but I’d like to see 
>> section 1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to 
>> list the changes at each draft. Instead, only the major difference from RFC 
>> 5246, et al., should be included. It’s difficult to wade through this 
>> section as written.
>> 
>> I refer to RFC5246, section 1.2 as an appropriate (and useful) example.
> 
> Yeah, this has come up a few times, also in another post here very recently. 
> It's always been on a vague todo list to fixup. I've filed an issue just for 
> this so we have it actually tracked.
> 
> https://github.com/tlswg/tls13-spec/issues/923
> 
> 
> Dave
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Updated Code Execution Draft

[Yoav Nir]

Cute. But these documents are supposed to be sent to either the RFC editor or 
the ISE directly, and no later than early March.

> On 1 Apr 2017, at 20:03, Yolo Crypto  wrote:
> 
> Hello all,
> 
> I have just revised my draft which describes how to extend TLS with a general 
> purpose code execution feature.
> 
> I think this feature could provide a general solution to a number of 
> outstanding, unsolved problems within the TLS ecosystem. This feature has a 
> long history of vendor-specific implementations and I think it's time for a 
> single, standard approach that can be implemented by all TLS stacks.
> 
> Comments welcome!
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

[Yoav Nir]

> On 21 Mar 2017, at 11:04, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> 
> 
> Thanks Yoav,
> 
> On 21/03/17 07:44, Yoav Nir wrote:
>> Some that are not addressed, I’ve answered below.  Let me know if you
>> want me to merge and submit.
> 
> I'd say give it a chance for one round of comments from Eric
> and/or others, and then submit. Or, submit before you head
> for an airport on your way to Chicago if that happens first.
> If we're left with an RFC editor note being needed, that's
> ok so long as it's simple enough.

OK, so how is that technically done?  The Upload page is defunct until Monday.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

[Yoav Nir]

> On 21 Mar 2017, at 14:28, Sean Turner  wrote:
> 
> 
>> On Mar 21, 2017, at 08:02, Eric Rescorla  wrote:
>> 
>> What we probably should actually do is make this depend on the IANA draft 
>> and then mark
>> these Not Recommended.
> 
> That is an option as none of the 3DES suites are marked as Recommended in the 
> IANA draft.
> 

Which to me sounds like an argument for leaving the text as is.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

[Yoav Nir]

Hi

This pull request addresses most of these comments.   
https://github.com/tlswg/rfc4492bis/pull/39 
  There is some discussion on that 
PR

Some that are not addressed, I’ve answered below.  Let me know if you want me 
to merge and submit.

Yoav

On 15 Mar 2017, at 16:44, Eric Rescorla  wrote


> Sorry for the late review of this document. I just got to it this
> week. I'm sending this as comments rather than issues/PR due to
> how late it is in the proces.
> 
> I have two high-level comments:
> 
> - This document seems to still have a bunch of material about
>   static DH (especially static DH authentication). I thought we
>   had agreed to remove that.
> 
> - You are inconsistent about using capital 2119 language
>   and I expect you want to be consistent.
> 
> 
> DETAILED
> S 2.
>All of these key exchange algorithms provide forward secrecy.
> 
> This is actually only true if each side generates fresh ephemerals
> which does not seem to be required by the spec.
> 
> Do we really want to promote ECDH_anon to standards track?

It’s the EC version of DH_anon, which is on the standards-track. I don’t expect 
to convert the web to use DH_anon, but its security is very much like what you 
get with a self-issued certificate, with many less bytes on the wire. Anyway, I 
don’t think this effort is the place to deprecate what is a pretty good 
mechanism for opportunistic security if nothing else.

> 
> Nit: you want a line break between the last line of Figure 1
> and the legend explaining the message types.
> 
> 
> S 2.3.
>This specification does not impose restrictions on signature schemes
>used anywhere in the certificate chain.  The previous version of this
>document required the signatures to match, but this restriction,
>originating in previous TLS versions is lifted here as it had been in
>RFC 5246.
> 
> This section is about ECDH_anon, so maybe this text belongs in S 2.1 or 2.2.?
> 
> 
> S 3.
> You have a bunch of lower case 2119 key words here.
> 
>If these conditions are not met, the client should send a client
>Certificate message containing no certificates.  In this case, the
>ClientKeyExchange should be sent as described in Section 2, and the
>CertificateVerify should not be sent.  If the server requires client
>authentication, it may respond with a fatal handshake failure alert.
> 
> Actually, this "should not be sent" is a MUST NOT, because if you send
> an empty certificate, you're forbidden to send CertificateVerify.
> 
> 
> S 4.
>choice of curves and compression techniques specified by the client.
> 
> s/compression techniques/point formats/?

Since we’re deprecating all point formats other than uncompressed, I just 
removed the “and” and left it as choice of curves.

> S 5.1.1.
> Do you want to rename elliptic_curve_list to named_curve_list?

Yes

> S 5.1.2.
> 
>Three point formats were included in the definition of ECPointFormat
>above.  This specification deprecates all but the uncompressed point
>format.  Implementations of this document MUST support the
>uncompressed format for all of their supported curves, and MUST NOT
>support other formats for curves defined in this specification.  For
>backwards compatibility purposes, the point format list extension
>MUST still be included, and contain exactly one value: the
>uncompressed point format (0).
> 
> This implies that you have to send supported point formats, but in
> S 5.1, this is a SHOULD. I believe what you may be trying to say
> here is that if you send the extension, it must be non-empty.
> 
> Also, maybe I'm missing it, but where do you say that the default
> is to assume that the other side supports uncompressed if it doesn't
> do so. This is a backwards compat issue.
> 
> 
> S 5.3.
> You don't define what "authorized for signatures" is, but I suspect
> you're talking about KeyUsage, etc.? If so, don't you need to say
> this about ECDHE_ECDSA as well.
> 
> S 5.4.
>The value named_curve indicates that a named curve is used.  This
>option SHOULD be used when applicable.
> 
> When would you not?
> 
> S 5.5.
> This defines:
>  rsa_fixed_ecdh(65),
>  ecdsa_fixed_ecdh(66),
> 
> But the specification doesn't actually support this. Note that
> the fixed_DH authentication mechanism are specified as having
> the client's cert be on the same curve as the long-term
> ECDH key, but you've deprecated those KE mechanisms, so as far
> as I can tell, static DH auth is impossible
> 
> Also:
> 1. Why isn't the ECDSA cert required to be signing capable.
> 2. You probably should standardize on ECDSA_sign or ecdsa_sign.
> 
> S 5.7.
> More text about static DH auth. Also "implicit" can probably go away.
> 
>The client selects an ephemeral ECDH public key corresponding to the
>parameters it received from the server according to the ECKAS-DH1
>scheme from IEEE 1363.  It 

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Yoav Nir]

> On 16 Mar 2017, at 22:52, Nitin Shrivastav <nitin.shrivas...@broadcom.com> 
> wrote:
> 
> Thanks Yoav. I am assuming it is true for TLS1.2 also?

RFC 5246 *is* TLS 1.2.  But it’s true for previous versions and for 1.3 as well.
> 
> It would be nice to provide a mechanism for servers to do this as we are 
> trying to run a web server in a constrained IoT end-points with only tens of 
> KBytes of RAM and SSL/TLS based connection is important..

I don’t get if you mean that the constrained end-point is the client or the 
server. But either way, both sides can be configured to use small records. You 
only really need this extension when you both have large amounts of data (so 
large records would be used without this extension) and the server is a generic 
web server that responds to both constrained and non-constrained devices.

But even in that case, adding the extension to the ClientHello should not be 
infeasible.

Yoav

> On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
> Hi, Nitin.
> 
> In section 7.4.1.4 of RFC 5246 it says:
> 
>An extension type MUST NOT appear in the ServerHello unless the same
>extension type appeared in the corresponding ClientHello.
> 
> So the answer is no. Only the client may request this.
> 
> Yoav
> 
>> On 16 Mar 2017, at 21:12, Nitin Shrivastav <nitin.shrivas...@broadcom.com 
>> <mailto:nitin.shrivas...@broadcom.com>> wrote:
>> 
>> Hello,
>> 
>> This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question 
>> on RFC 6066 Maximum Fragment Length Negotiation section
>> 
>> The question i have is whether it is possible for a server to initiate the 
>> Max fragment length negotiation. The RFC describes a scenario where a 
>> constrained client can initiate this but in our product the server is very 
>> tightly constrained on memory and we want to reduce the memory used for SSL 
>> connections by forcing the clients to use reduce fragment length. We don't 
>> have control over the clients in our scenario which are basically the 
>> browsers like Chrome, IE etc.
>> 
>> Thanks,
>> Nitin
>> ___
>> TLS mailing list
>> TLS@ietf.org <mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls 
>> <https://www.ietf.org/mailman/listinfo/tls>
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC 6066 - Max fragment length negotiation

[Yoav Nir]

Hi, Nitin.

In section 7.4.1.4 of RFC 5246 it says:

   An extension type MUST NOT appear in the ServerHello unless the same
   extension type appeared in the corresponding ClientHello.

So the answer is no. Only the client may request this.

Yoav

> On 16 Mar 2017, at 21:12, Nitin Shrivastav  
> wrote:
> 
> Hello,
> 
> This is Nitin Shrivastav, Engineering Manager at Broadcom. I have a question 
> on RFC 6066 Maximum Fragment Length Negotiation section
> 
> The question i have is whether it is possible for a server to initiate the 
> Max fragment length negotiation. The RFC describes a scenario where a 
> constrained client can initiate this but in our product the server is very 
> tightly constrained on memory and we want to reduce the memory used for SSL 
> connections by forcing the clients to use reduce fragment length. We don't 
> have control over the clients in our scenario which are basically the 
> browsers like Chrome, IE etc.
> 
> Thanks,
> Nitin
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Uplifting 5289

[Yoav Nir]

Oh, sorry. I missed that it was Informational.

In that case there’s just the issue that it has ECDH ciphersuites at a time 
where 4492bis is deprecating all the other ones.  But some of the ciphersuites 
in there are in wide enough use that it shouldn’t remain Informational.

Yes, it should be uplifted then.

Yoav

> On 16 Mar 2017, at 21:23, Eric Rescorla <e...@rtfm.com> wrote:
> 
> This is actually uplift to PS.
> 
> On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
> 
>> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com 
>> <mailto:kathleen.moriarty.i...@gmail.com> wrote:
>> 
>> 
>> 
>> Please excuse typos, sent from handheld device
>> 
>>> On Mar 16, 2017, at 11:37 AM, Yoav Nir <ynir.i...@gmail.com 
>>> <mailto:ynir.i...@gmail.com>> wrote:
>>> 
>>> 
>>>> On 16 Mar 2017, at 17:17, Eric Rescorla <e...@rtfm.com 
>>>> <mailto:e...@rtfm.com>> wrote:
>>>> 
>>>> Hi folks
>>>> 
>>>> I note that we are proposing to uplift RFC 5289 to PS, despite the fact 
>>>> that it
>>>> standardizes some CBC cipher suites, which the WG is looking to move away
>>>> from. I recognize that these are the only cipher suites you can use in TLS 
>>>> 1.0
>>>> and 1.1, but we also want people to move away from them.
>>>> 
>>>> This problem is probably solvable by marking the registry as Not 
>>>> Recommended, but I wondered if anyone had other thoughts on this topic?
>>>> 
>>> 
>>> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch 
>>> of ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 
>>> 5246.
>> 
>> TLS 1.2 will be in use for a while unless major problems are found, so it's 
>> worthwhile IMO.
> 
> I understand that. I’m wondering what message we are trying to convey by 
> publishing or uplifting a full standard for a now-obsolete protocol.
> 
> The Internet works just fine on proposed standards (or even Internet Drafts)
> 
> Yoav
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Uplifting 5289

[Yoav Nir]

> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote:
> 
> 
> 
> Please excuse typos, sent from handheld device
> 
>> On Mar 16, 2017, at 11:37 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>> 
>> 
>>> On 16 Mar 2017, at 17:17, Eric Rescorla <e...@rtfm.com> wrote:
>>> 
>>> Hi folks
>>> 
>>> I note that we are proposing to uplift RFC 5289 to PS, despite the fact 
>>> that it
>>> standardizes some CBC cipher suites, which the WG is looking to move away
>>> from. I recognize that these are the only cipher suites you can use in TLS 
>>> 1.0
>>> and 1.1, but we also want people to move away from them.
>>> 
>>> This problem is probably solvable by marking the registry as Not 
>>> Recommended, but I wondered if anyone had other thoughts on this topic?
>>> 
>> 
>> 5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch 
>> of ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 
>> 5246.
> 
> TLS 1.2 will be in use for a while unless major problems are found, so it's 
> worthwhile IMO.

I understand that. I’m wondering what message we are trying to convey by 
publishing or uplifting a full standard for a now-obsolete protocol.

The Internet works just fine on proposed standards (or even Internet Drafts)

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Uplifting 5289

[Yoav Nir]

> On 16 Mar 2017, at 17:17, Eric Rescorla  wrote:
> 
> Hi folks
> 
> I note that we are proposing to uplift RFC 5289 to PS, despite the fact that 
> it
> standardizes some CBC cipher suites, which the WG is looking to move away
> from. I recognize that these are the only cipher suites you can use in TLS 1.0
> and 1.1, but we also want people to move away from them.
> 
> This problem is probably solvable by marking the registry as Not Recommended, 
> but I wondered if anyone had other thoughts on this topic?
> 

5289 applies to TLS 1.0, 1.1, and 1.2.  It seems strange to uplift a bunch of 
ciphersuites for 1.2 just as we’re publishing TLS 1.3 which obsoletes 5246.

Yoav




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC4492bis next steps

[Yoav Nir]

OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s comments 
over the weekend.

Yoav

> On 16 Mar 2017, at 14:41, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> 
> 
> 
> On 16/03/17 06:20, Yoav Nir wrote:
>> Hopefully I’ll be all done and ready to submit a new version as soon
>> as submissions are re-opened on the 27th.
> 
> If we're ready sooner, I'd prefer try get that
> out of the way next week. I can tell to secretariat
> to accept updates for this draft. (I'll likely
> do that after the IESG telechat this afternoon)
> 
> Cheers,
> S.
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] RFC4492bis next steps

[Yoav Nir]

Hi.

There are now three PRs pending for this draft:
https://github.com/tlswg/rfc4492bis/pulls 


These all look fine to me.

There is also ekr’s review that requires some more changes:
https://www.ietf.org/mail-archive/web/tls/current/msg22628.html 


So unless there are objections, I will merge the three PRs over the weekend so 
I can make the remaining changes without causing a bunch of conflicts.

Hopefully I’ll be all done and ready to submit a new version as soon as 
submissions are re-opened on the 27th.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

[Yoav Nir]

LGTM

> On 15 Mar 2017, at 21:32, David Benjamin <david...@chromium.org> wrote:
> 
> How's this look? https://github.com/tlswg/rfc4492bis/pull/37 
> <https://github.com/tlswg/rfc4492bis/pull/37>
> 
> On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <ynir.i...@gmail.com 
> <mailto:ynir.i...@gmail.com>> wrote:
> There is (going to be a re-spin). There already is a PR there.
> 
> If you can make a PR to solve your issue, that would be great.
> 
>> On 15 Mar 2017, at 19:20, David Benjamin <david...@chromium.org 
>> <mailto:david...@chromium.org>> wrote:
>> 
>> If there's to be a respin anyway, I have another small editorial comment:
>> https://github.com/tlswg/rfc4492bis/issues/36 
>> <https://github.com/tlswg/rfc4492bis/issues/36>
>> 
>> On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla <e...@rtfm.com 
>> <mailto:e...@rtfm.com>> wrote:
>> FWIW, there's a lot here, but I think it's all essentially editorial, so it 
>> shouldn't
>> be that hard to clean up.
>> 
>> -Ekr
>> 
>> 
>> On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie 
>> <mailto:stephen.farr...@cs.tcd.ie>> wrote:
>> 
>> Thanks Eric,
>> 
>> Let's see what folks say in response to this and I can post
>> anything not immediately resolved as a DISCUSS ballot. We
>> can then process that in the coming week or two, and you
>> can take over the DISCUSS for whatever's not resolved by
>> the swap-over in Chicago. Or if someone else wants to
>> make some or all of Eric's comments a DISCUSS that'd work
>> too, but I'm fine with taking it.
>> 
>> Cheers,
>> S.
>> 
>> On 15/03/17 14:44, Eric Rescorla wrote:
>> > Sorry for the late review of this document. I just got to it this
>> > week. I'm sending this as comments rather than issues/PR due to
>> > how late it is in the proces.
>> >
>> > I have two high-level comments:
>> >
>> > - This document seems to still have a bunch of material about
>> >   static DH (especially static DH authentication). I thought we
>> >   had agreed to remove that.
>> >
>> > - You are inconsistent about using capital 2119 language
>> >   and I expect you want to be consistent.
>> >
>> >
>> > DETAILED
>> > S 2.
>> >All of these key exchange algorithms provide forward secrecy.
>> >
>> > This is actually only true if each side generates fresh ephemerals
>> > which does not seem to be required by the spec.
>> >
>> > Do we really want to promote ECDH_anon to standards track?
>> >
>> >
>> > Nit: you want a line break between the last line of Figure 1
>> > and the legend explaining the message types.
>> >
>> >
>> > S 2.3.
>> >This specification does not impose restrictions on signature schemes
>> >used anywhere in the certificate chain.  The previous version of this
>> >document required the signatures to match, but this restriction,
>> >originating in previous TLS versions is lifted here as it had been in
>> >RFC 5246.
>> >
>> > This section is about ECDH_anon, so maybe this text belongs in S 2.1 or
>> > 2.2.?
>> >
>> >
>> > S 3.
>> > You have a bunch of lower case 2119 key words here.
>> >
>> >If these conditions are not met, the client should send a client
>> >Certificate message containing no certificates.  In this case, the
>> >ClientKeyExchange should be sent as described in Section 2, and the
>> >CertificateVerify should not be sent.  If the server requires client
>> >authentication, it may respond with a fatal handshake failure alert.
>> >
>> > Actually, this "should not be sent" is a MUST NOT, because if you send
>> > an empty certificate, you're forbidden to send CertificateVerify.
>> >
>> >
>> > S 4.
>> >choice of curves and compression techniques specified by the client.
>> >
>> > s/compression techniques/point formats/?
>> >
>> >
>> > S 5.1.1.
>> > Do you want to rename elliptic_curve_list to named_curve_list?
>> >
>> >
>> > S 5.1.2.
>> >
>> >Three point formats were included in the definition of ECPointFormat
>> >above.  This specification deprecates all but the uncompressed point
>> >format.  Implementations of this document MUST support the
>> > 

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

[Yoav Nir]

There is (going to be a re-spin). There already is a PR there.

If you can make a PR to solve your issue, that would be great.

> On 15 Mar 2017, at 19:20, David Benjamin  wrote:
> 
> If there's to be a respin anyway, I have another small editorial comment:
> https://github.com/tlswg/rfc4492bis/issues/36 
> 
> 
> On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla  > wrote:
> FWIW, there's a lot here, but I think it's all essentially editorial, so it 
> shouldn't
> be that hard to clean up.
> 
> -Ekr
> 
> 
> On Wed, Mar 15, 2017 at 8:07 AM, Stephen Farrell  > wrote:
> 
> Thanks Eric,
> 
> Let's see what folks say in response to this and I can post
> anything not immediately resolved as a DISCUSS ballot. We
> can then process that in the coming week or two, and you
> can take over the DISCUSS for whatever's not resolved by
> the swap-over in Chicago. Or if someone else wants to
> make some or all of Eric's comments a DISCUSS that'd work
> too, but I'm fine with taking it.
> 
> Cheers,
> S.
> 
> On 15/03/17 14:44, Eric Rescorla wrote:
> > Sorry for the late review of this document. I just got to it this
> > week. I'm sending this as comments rather than issues/PR due to
> > how late it is in the proces.
> >
> > I have two high-level comments:
> >
> > - This document seems to still have a bunch of material about
> >   static DH (especially static DH authentication). I thought we
> >   had agreed to remove that.
> >
> > - You are inconsistent about using capital 2119 language
> >   and I expect you want to be consistent.
> >
> >
> > DETAILED
> > S 2.
> >All of these key exchange algorithms provide forward secrecy.
> >
> > This is actually only true if each side generates fresh ephemerals
> > which does not seem to be required by the spec.
> >
> > Do we really want to promote ECDH_anon to standards track?
> >
> >
> > Nit: you want a line break between the last line of Figure 1
> > and the legend explaining the message types.
> >
> >
> > S 2.3.
> >This specification does not impose restrictions on signature schemes
> >used anywhere in the certificate chain.  The previous version of this
> >document required the signatures to match, but this restriction,
> >originating in previous TLS versions is lifted here as it had been in
> >RFC 5246.
> >
> > This section is about ECDH_anon, so maybe this text belongs in S 2.1 or
> > 2.2.?
> >
> >
> > S 3.
> > You have a bunch of lower case 2119 key words here.
> >
> >If these conditions are not met, the client should send a client
> >Certificate message containing no certificates.  In this case, the
> >ClientKeyExchange should be sent as described in Section 2, and the
> >CertificateVerify should not be sent.  If the server requires client
> >authentication, it may respond with a fatal handshake failure alert.
> >
> > Actually, this "should not be sent" is a MUST NOT, because if you send
> > an empty certificate, you're forbidden to send CertificateVerify.
> >
> >
> > S 4.
> >choice of curves and compression techniques specified by the client.
> >
> > s/compression techniques/point formats/?
> >
> >
> > S 5.1.1.
> > Do you want to rename elliptic_curve_list to named_curve_list?
> >
> >
> > S 5.1.2.
> >
> >Three point formats were included in the definition of ECPointFormat
> >above.  This specification deprecates all but the uncompressed point
> >format.  Implementations of this document MUST support the
> >uncompressed format for all of their supported curves, and MUST NOT
> >support other formats for curves defined in this specification.  For
> >backwards compatibility purposes, the point format list extension
> >MUST still be included, and contain exactly one value: the
> >uncompressed point format (0).
> >
> > This implies that you have to send supported point formats, but in
> > S 5.1, this is a SHOULD. I believe what you may be trying to say
> > here is that if you send the extension, it must be non-empty.
> >
> > Also, maybe I'm missing it, but where do you say that the default
> > is to assume that the other side supports uncompressed if it doesn't
> > do so. This is a backwards compat issue.
> >
> >
> > S 5.3.
> > You don't define what "authorized for signatures" is, but I suspect
> > you're talking about KeyUsage, etc.? If so, don't you need to say
> > this about ECDHE_ECDSA as well.
> >
> > S 5.4.
> >The value named_curve indicates that a named curve is used.  This
> >option SHOULD be used when applicable.
> >
> > When would you not?
> >
> > S 5.5.
> > This defines:
> >  rsa_fixed_ecdh(65),
> >  ecdsa_fixed_ecdh(66),
> >
> > But the specification doesn't actually support this. Note that
> > the fixed_DH authentication mechanism are specified as having
> > the client's cert be on the same