[IPsec] The ESP Echo Protocol document for IPsecME

[Yoav Nir]

Hi, folks

At IETF 119, Jen Likova presented [1] the ESP Echo Protocol draft [2].

The conversation in the room was lively, but did not look like the kind of 
consensus that we just confirm on the list.

So rather than starting an adoption call now, we’d like to encourage people to 
discuss it on the list, to see if we are approaching such a consensus.

Regards,

Yoav on behalf of the chairs

[1] https://youtu.be/n-yH3jtQmdQ?t=1205  (presentation starts at the 20:10 mark)
[2] https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org

Re: [Acme] Happy Birthday ACME!

[Yoav Nir]

Hi, Rob

The first question whenever someone proposes a bis document is, of course, “are 
you volunteering to edit?”

Jokes aside, it’s always a question of whether or not it is worth the effort. 
Not just for whoever is editing, but the usual effort associated with any 
document, such as WG participants, shepherd, AD, IESG, various directorates, 
RFC editor.

So before embarking on something like this, it’s not enough to just count the 
number of errata. You need to put yourself in the shoes of a naive implementer 
who doesn’t know about errata. Are the errors big enough that they might lead 
them to make a mistake in the implementation?  Text that uses “example.com 
” instead of “example.org ” probably 
isn’t. Text that says that a challenge object with an error cannot have the 
“processing” status when it can likely is.

As for adding other RFCs, that’s again a judgement call. We did merge some 
add-ons to IKEv2 in one of its revisions. It make sense to merge them if the 
add-on is so obvious and so necessary, that pretty much every implementation of 
8555 would also implement the other document. Is RFC8738 like that? Or are IP 
identifiers so rare and curious that many implementations exclude them?

As always, it’s up to the group whether making a significantly bigger document 
with some of the add-ons makes sense. In general, groups and ADs tend to prefer 
smaller documents, but that is decided on a case-by-case basis.

Yoav

> On 11 Mar 2024, at 23:08, Rob Stradling  
> wrote:
> 
> RFC8555 was published [1] 5 years ago today!
> 
> Just thinking aloud, 'cos I'm curious what folks here think...
> At what point might it make sense to start work on an 8555-bis?
> 
> There's a fairly long list of Errata [2]: 10 Verified, 5 Reported, and 4 Held 
> for Document Update.
> 
> Would it make sense for an 8555-bis document to incorporate and obsolete any 
> of the "add-on" RFCs / I-Ds, such as RFC8738, that have been published since 
> RFC8555?  Or, conversely, would it be preferable to not do that?
> 
> With 5 years of deployment experience behind us, have any "missing" features 
> in RFC8555 been identified that would be best addressed by updating the core 
> specification (i.e., in an 8555-bis document) rather than by writing new 
> "add-on" I-Ds?  Or, conversely, are "add-on" I-Ds always the preferred 
> approach?  (The "missing" feature that immediately springs to my mind is 
> "profiles" [3]).
> 
> 
> [1] 
> https://mailarchive.ietf.org/arch/msg/rfc-dist/25pD6Za_dVkXMbJwyPhBJR6nIlo/
> [2] https://www.rfc-editor.org/errata_search.php?rfc=8555
> [3] https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/
> 
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> ___
> Acme mailing list
> Acme@ietf.org 
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME leadership changes

[Yoav Nir]

Hi, Tomofumi.

Welcome to the working group.

Looking forward to working with you.

Yoav

> On 7 Mar 2024, at 23:48, Roman Danyliw  wrote:
> 
> Hi WG!
> 
> As Deb (Cooley) will be the new, incoming SEC AD at the Brisbane meeting, 
> there is a vacancy left in the co-chair team of ACME.  It is my pleasure to 
> announced that Tomofumi Okubo will be stepping in as the new-chair.  Tomofumi 
> brings a wealth of experience in PKI and as a contributor in PKI-related IETF 
> WGs.
> 
> Tomofumi: Thank you for your willingness to serve.
> 
> Deb: Congratulations on your new AD role!  Thank you for your leadership in 
> the WG.
> 
> Yoav (Nir): Despite these transitions, thank you for your continued service 
> as co-chair in the WG!
> 
> Deb isn't going too far from ACME.  After the AD transition in Brisbane, the 
> responsible AD for ACME will transition from me to her.
> 
> Regards,
> Roman
> 
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

> On 14 Nov 2023, at 19:46, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>> - Although it is implied, it should be stated explicitly that
>> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As
>> some child SAs get deleted and perhaps not rekeyed if they’re idle, if
>> traffic picks up again, new child SAs with these TS can be created
>> until the peer again blocks you with a TS_MAX_QUEUE.
> 
> Do you think it be better for each end to announce a maximum ahead of time?
> (At negotiation of the first child SA)

I think so, but not completely sure.

Suppose one peer is willing to go to 32 parallel SAs, while the other is going 
to stop at 8, because one has 32 cores and the other 8.

So on the “big” gateway, all flows that fit the TS should be forwarded to one 
of 8 cores. If this was negotiated upfront, the big gateway can choose which 8. 
 As it is, the first 8 cores that triggered the negotiation get SAs, while the 
rest have to forward after a short delay while trying and failing to negotiate 
an SA.

Maybe it’s not an issue because SAs can be moved among cores. The draft 
mentions this possibility. 

Yoav



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

> On 13 Nov 2023, at 12:31, Sahana Prasad  wrote:
> 
> Hello,
> 
> I've read the draft and support its adoption.

To clarify, the draft is already adopted since July 2021.  The question now is 
whether it is ready to proceed to publication.

> Specifically, we (at Red Hat) have use cases where customer to data center 
> links
> see performance penalties for enabling IPsec on these
> connections. We've been looking at how to fix this and this draft
> seems to be a solution for our use case.

Since I now realize now that it was not clear from my message, I agree.

Yoav
(with no hats)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

Hi.

I’ve read the draft. Overall, it’s similar to a non-standardized solution we 
did at Check Point several years ago, so I agree that it is a solution that 
works.  Of course, since there *are* a bunch of working implementations, that 
is not particularly insightful.

With a lot of flows, it’s likely that in most situations the number of parallel 
SAs is going to be about the same as the number of “resources”. The text in 
section 4 does mention the issue of having peers with a different number of 
CPUs. In practice these can be very different. It’s not unheard of to have a 
center office with dozens of CPUs working with a branch office machine with 
one. The way this protocol seems to work is that the center office will attempt 
to create dozens of SAs, only to be stopped by the branch office which at some 
point will return the TS_MAX_QUEUE notification.  I’m not a big fan of creating 
as many SAs as you can until the peer fails you, but the alternative would be 
to pre-negotiate the ts_max_queue value.

A couple of editorial comments:
- Although it is implied, it should be stated explicitly that TS_MAX_QUEUE does 
not mean no more child SAs with these TS ever. As some child SAs get deleted 
and perhaps not rekeyed if they’re idle, if traffic picks up again, new child 
SAs with these TS can be created until the peer again blocks you with a 
TS_MAX_QUEUE.
- With a single SA pair per TS, implementations can expect that all packets in 
a flow (such as a TCP connection) will go through the same SA pair. This is 
especially important in implementations that are combined with firewalls. I 
think we need explicit text that says packets for any flow may come on any of 
the SAs from the logical group of child SAs. Perhaps:

“implementations MUST NOT assume that all packets of a particular flow will be 
encrypted with a particular SA in the logical group of child SAs.”

Yoav



> On 25 Oct 2023, at 1:40, Tero Kivinen  wrote:
> 
> This will start three week working group laste call for
> draft-ietf-ipsecme-multi-sa-performance. The working group last call
> will end at 2023-11-15.
> 
> Please review the document and send comments to the list if you think
> it is ready for publication.
> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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: [Lsr] Secdir last call review of draft-ietf-lsr-ip-flexalgo-11

[Yoav Nir]

> On 16 May 2023, at 10:25, Peter Psenak  wrote:
> 
> Yoav,
> 
> thanks for comments, please see inline:
> 
> 
> On 15/05/2023 21:36, Yoav Nir via Datatracker wrote:
>> Reviewer: Yoav Nir
>> Review result: Has Nits
>> Hi.
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG. These comments were written primarily for the benefit of the
>> security area directors. Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>> I am no expert on routing in general or IGP flex algorithms in particular. 
>> That
>> said, I found the Abstract and Introduction jarring. The first paragraph of 
>> the
>> Abstract would be better as part of the introduction than the abstract.
> 
> I moved the first paragraph from Abstract to Introduction.

Sounds good.

> 
>> The Security Considerations section seems mostly copy-pasted from RFC 9350 
>> with
>> mild editing.  The substance may be correct - that the only new attack 
>> possible
>> is suppressing reachability for a prefix, but I think only the second 
>> paragraph
>> is necessary for that.
> 
> I would prefer to keep the first paragraph.

OK.

Yoav
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Secdir last call review of draft-ietf-lsr-ip-flexalgo-11

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Has Nits

Hi.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

I am no expert on routing in general or IGP flex algorithms in particular. That
said, I found the Abstract and Introduction jarring. The first paragraph of the
Abstract would be better as part of the introduction than the abstract.

The Security Considerations section seems mostly copy-pasted from RFC 9350 with
mild editing.  The substance may be correct - that the only new attack possible
is suppressing reachability for a prefix, but I think only the second paragraph
is necessary for that.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[IPsec] Scheduling for London

[Yoav Nir]

Hi, folks.

As you know, we have a 90-minute session on Wednesday, November 9th at 15:00.

In addition to all the document status and solemn recitation of the Note Well, 
we have so far received 4 requests for agenda time:


From Hang Shi about draft-ls-6man-ipcomp-exclude-transport-layer, a proposed 
extension to IPComp
New IKEv2 payload format - by Valery
Revised Cookie processing (draft-smyslov-ipsecme-ikev2-cookie-revised) - also 
by Valery
Inter-domain source address validation using RPKI and IPsec (draft-xu-risav and 
draft-xu-erisav) - by Yangfei Guo

If anyone else needs an agenda slot, now is the time to speak.

Thanks


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[IPsec] Tomorrow's SAAG meeting

[Yoav Nir]

Hi all

In case you missed it, tomorrow's SAAG meeting will feature an "Introduction to 
IPSec" (yes! with a capital S) by Paul Wouters.

See you all there

Yoav

⁣Sent from my phone ​___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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: [IPsec] Cost-efficient quantum-resistant DoS protection

[Yoav Nir]

> On 10 Nov 2021, at 16:41, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>>>> Tero Kivinen  wrote:
>>>>>> Even without surpassing the 64KB limit, this must be a concern.
>>>>>> IKEv2's cookie mechanism and puzzles try to increase the cost of the
>>>>>> attacker per each connection. Now, an attacker must still accept
>>>>>> these costs but can use one connection to trigger several key
>>>>>> exchanges, all significantly larger than what we had with DH, making
>>>>>> the trade-off way better for them compared to non-pqc IKEv2.
>>>> 
>>>>> No it cannot. Attacker can use cookie only once, and will only get one
>>>>> exchange created by each cookie exchange, thus it needs to do puzzles
>>>>> and cookies again for every single attack packet it wants to send.
>>>> 
>>>> I wonder if anyone has any stats on how often cookie challenge is used, how
>>>> often puzzles are invoked.
>>> 
>>> I've implemented puzzles, but I'm not aware of any other implementation.
>>> 
>>> What about cookies - in stress tests they are used very intensively.
>>> But I don't have any real life stats for them.
>>> 
>>> Regards,
>>> Valery.
> 
>> I also implemented puzzles. So that makes two of us.
> 
> Did you ever interop?

No. Never got to it.

> What is your criteria for enabling them?  Do you do this automatically, or is
> it an operator configuation to demand them?

GUI had three settings: off, cookies, puzzles.  In case of cookies or puzzles, 
they would activate with a certain number of simultaneous IKE negotiations in 
progress.

Because of GUI constraints, that setting had to apply to both IKEv1 and IKEv2 
(that was s separate set of radio buttons)

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

[Yoav Nir]

> On 1 Nov 2021, at 13:07, Valery Smyslov  wrote:
> 
> Hi Michael,
> 
>> Tero Kivinen  wrote:
 Even without surpassing the 64KB limit, this must be a concern.
 IKEv2's cookie mechanism and puzzles try to increase the cost of the
 attacker per each connection. Now, an attacker must still accept
 these costs but can use one connection to trigger several key
 exchanges, all significantly larger than what we had with DH, making
 the trade-off way better for them compared to non-pqc IKEv2.
>> 
>>> No it cannot. Attacker can use cookie only once, and will only get one
>>> exchange created by each cookie exchange, thus it needs to do puzzles
>>> and cookies again for every single attack packet it wants to send.
>> 
>> I wonder if anyone has any stats on how often cookie challenge is used, how
>> often puzzles are invoked.
> 
> I've implemented puzzles, but I'm not aware of any other implementation.
> 
> What about cookies - in stress tests they are used very intensively.
> But I don't have any real life stats for them.
> 
> Regards,
> Valery.

I also implemented puzzles. So that makes two of us.

Yoav___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[OAUTH-WG] Secdir last call review of draft-ietf-oauth-iss-auth-resp-02

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The draft is clear and well-written. The Security Considerations section
specifically is comprehensive and clear.

My one suggestion would be to move the first paragraph in the Security
Considerations section to the Introduction. It is about the attack and about
the protocol in the document being effective against the attack. It's not
really a consideration in the way that the rest of the section is.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Acme] Interim Meeiting Minutes

[Yoav Nir]

Hi.

I’ve posted the minutes to datatracker:

https://datatracker.ietf.org/meeting/interim-2021-acme-01/materials/minutes-interim-2021-acme-01-202109291400-00
 


Let me know if something’s missing or off.

Thanks again to Aaron Gable, both for his presentation and for taking the notes.

Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[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

[IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-intermediate-07

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-ipsecme-ikev2-intermediate-07 
as Proposed Standard on behalf of the IPSECME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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: [Acme] Changes in ACME WG leadership team

[Yoav Nir]

Welcome aboard, Deb!



> On 9 Jul 2021, at 19:26, Roman Danyliw  wrote:
> 
> Hi!
> 
> To follow up on the announcement during IETF 109, after 6 years of leading 
> the ACME WG from the very first BoF, Rich will be stepping down as co-chair.  
> Under his stewardship, a working group was formed, the core specifications 
> were completed, and most importantly, they saw adoption.  The underlying ACME 
> technology, and the services using it, have profoundly lowered the barrier to 
> secure communication over the Internet.  
> 
> Rich: This achievement is due to your time, commitment and leadership.  A 
> profound thank you!
> 
> I'm excited to announce that Deb Cooley has graciously agreed to serve as the 
> co-chair with Yoav.  Deb brings top-sight of the security area having worked 
> in a number WGs, and a deep understanding of certificate technologies and 
> associated ecosystems.
> 
> Please join me in thanking Rich for his years of service in the WG, and 
> welcoming Deb to the new role.
> 
> Regards,
> Roman
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

[no hats]
I don’t want to start (or resume) a religious holy war about uppercase MUSTs, 
but they’re usually about protocol compliance. What people should (not SHOULD) 
do with their systems is not subject to requirements language, because the IETF 
does not engineer administrators. What? You are not compliant with RFC  if 
you didn’t upgrade your systems already?

I could understand a statement that Product  is not compliant with RFC  
because it still offers IKEv1, but I don’t like non-compliant administrators. 
Not that I’m advocating to add that statement to the draft. I think it’s fine 
as it is: just offering advice that systems should be upgraded.

Yoav

> On 29 Jun 2021, at 17:21, Daniel Migault  wrote:
> 
> I believe that the first sentence of section 3 says it all. ship it!
> 
> I still have some minor comments, though these may have already been 
> discussed. There are no normative MUST to upgrade ( and in general very 
> little normative language). 
> Shouldn't we have for example:
> Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.
> 
> moved to :
> Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.
> 
> There are overall very little number of SHOULD/MUST but maybe that is an 
> editorial choice. 
> 
> Yours, 
> Daniel 
> 
> 
>  
>  
> 
> Yours, 
> Daniel
> 
> On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins  > wrote:
> 
>Hi,
> 
> On 6/28/21 1:23 AM, Valery Smyslov wrote:
> > Hi,
> >
> > I think document is mostly ready. Few observations:
> >
> > - FWIW I think that Dan's efforts to make draft's language less speculative 
> > and more concrete
> > are valid and should be reflected in the document.
> >
> > - Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
> >
> > - The draft states that it updates RFC 7296, 8221, 8247. What in particular 
> > is being updated?
> > I believe the recent IESG directives require a short explanation of 
> > what is being updated
> > to be present in Abstract. In any case, it should be clearly indicated 
> > in the body of the document.
> > Have I missed it?
> >
> > - Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 
> > in every aspect." is a bit too vague.
> 
>You know, that was bugging me too. "in every aspect" is laying it on 
> a bit thick. IKEv1
> has a security proof. The much maligned PSK mode authenticates the key 
> as well as the
> exchange which is better than what IKEv2 does (and why IKEv1 did not 
> need an update to do
> PQC). So saying it's less secure "in every aspect" just isn't true. But 
> I couldn't figure
> out a better way to say it
> 
> >I believe it's better to list security aspects where we believe IKEv2 is 
> > superior:
> >
> >* IKEv2 supports modern cryptographic primitives, including AEAD ciphers
> >* IKEv2 provides real defense against DoS (cookies, core spec) and DDoS 
> > (puzzles, RFC 8019) attacks
> >* support for post-quantum crypto in IKEv2 is being developed 
> > (draft-ietf-ipsecme-ikev2-multiple-ke)
> >* IKEv2 supports various authentication methods via integration with EAP 
> > (core spec)
> >* an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
> >* did I forget something?
> 
>But this is great! I agree that such a brief summary of the superior 
> features
> would be better than a factually challenged "in every aspect" statement.
> 
>regards,
> 
>Dan.
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> 
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
> 
> 
> -- 
> Daniel Migault
> Ericsson
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

To facilitate this discussion:

The comments are in this message: 
https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/>

Paul repled with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/>

Dan replied with this: 
https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/>

Tero: https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/>

And finally, Dan: 
https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/ 
<https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/>

If I read this correctly, the last two messages are about some of 
decision-making process in IKEv2 drafts, so it’s not relevant to the draft now 
in WGLC.

Can I assume the unaddressed points are those in the third message?

Yoav

> On 27 Jun 2021, at 10:27, Dan Harkins  wrote:
> 
> 
>   I sent substantive comments on this draft to the list on May 6th of this
> year. They were not addressed so they apply to this WGLC.
> 
>   Dan.
> 
> On 6/26/21 1:38 AM, Yoav Nir wrote:
>> Hi, all.
>> 
>> Although this draft is really new, having been submitted in April of this 
>> year, its predecessor draft has been under discussion since March of 2019.
>> 
>> This begins a 2-week WGLC. Please read the draft and post comments to the 
>> list. Since this is rather new, short messages in the vein of “Yeah, this is 
>> good. Ship it”, but substantive comments are, of course, even more welcome.
>> 
>> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
>> 
>> Thanks
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

Forgot to add a link to the draft:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ 
<https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/>


> On 26 Jun 2021, at 11:38, Yoav Nir  wrote:
> 
> Hi, all.
> 
> Although this draft is really new, having been submitted in April of this 
> year, its predecessor draft has been under discussion since March of 2019.
> 
> This begins a 2-week WGLC. Please read the draft and post comments to the 
> list. Since this is rather new, short messages in the vein of “Yeah, this is 
> good. Ship it”, but substantive comments are, of course, even more welcome.
> 
> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
> 
> Thanks
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

[Yoav Nir]

Hi, all.

Although this draft is really new, having been submitted in April of this year, 
its predecessor draft has been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post comments to the list. 
Since this is rather new, short messages in the vein of “Yeah, this is good. 
Ship it”, but substantive comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.

Thanks

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[Acme] Publication has been requested for draft-ietf-acme-dtnnodeid-04

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-acme-dtnnodeid-04 as Proposed 
Standard on behalf of the ACME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WGLC for ACME Integrations

[Yoav Nir]

Nearly a month has passed, and no responses. None at all.

Unless we get some reviews, I can’t declare a working group consensus on this.  
We need at least some “I’ve read it; I believe it’s useful and I think it’s 
ready for publication” reviews.

Without them, I think the best plan would be to tell teh authors that the WG 
doesn’t seem to care much for this, and advise them to turn to the ADs to ask 
to submit this as individuals.

Yoav

> On 31 Mar 2021, at 22:50, Yoav Nir  wrote:
> 
> Hi.
> 
> This starts a WGLC for the subject draft entitled “ACME Integrations. The 
> call will end at EOD Monday, April 19th, 2001.
> 
> The document has been with the WG since last January, and has received some 
> review. Following the closing of the last two issues, the authors believe and 
> the sense of the room at IETF 110 was, that the document is ready.  ACME 
> participants are encouraged to read and review, so that we can make changes 
> if such are needed, and progress the document for publication.
> 
> Linsk:
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ 
> <https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/>
> Plain text: 
> https://www.ietf.org/archive/id/draft-ietf-acme-integrations-03.txt 
> <https://www.ietf.org/archive/id/draft-ietf-acme-integrations-03.txt>
> HTML: https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-03 
> <https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-03>
> PDF: https://tools.ietf.org/pdf/draft-ietf-acme-integrations-03.pdf 
> <https://tools.ietf.org/pdf/draft-ietf-acme-integrations-03.pdf>
> 
> Thanks in advance
> 
> Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] WGLC for ACME DTN Node ID

[Yoav Nir]

Thanks to Russ Housley and Ryan Sleevi for the reviews. Thanks to the authors 
for the revised version.

This is not a great showing in terms of quantity of review, but the quality is 
sufficient. I will write the shepherd write-up and submit.

Yoav


> On 31 Mar 2021, at 22:50, Yoav Nir  wrote:
> 
> Hi.
> 
> This starts a WGLC for the subject draft entitled “Automated Certificate 
> Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID 
> Validation Extension”. The call will end at EOD Monday, April 19th, 2001.
> 
> The document has been with the WG since last August, and has received too 
> little review. ACME participants are encouraged to read and review, so that 
> we can make changes if such are needed, and progress the document for 
> publication.
> 
> Linsk:
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ 
> <https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/>
> Plain text: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.txt 
> <https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.txt>
> HTML: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.html 
> <https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.html>
> PDF: https://tools.ietf.org/pdf/draft-ietf-acme-dtnnodeid-01.pdf 
> <https://tools.ietf.org/pdf/draft-ietf-acme-dtnnodeid-01.pdf>
> 
> Thanks in advance
> 
> Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WGLC for ACME DTN Node ID

[Yoav Nir]

Hi.

This starts a WGLC for the subject draft entitled “Automated Certificate 
Management Environment (ACME) Delay-Tolerant Networking (DTN) Node ID 
Validation Extension”. The call will end at EOD Monday, April 19th, 2001.

The document has been with the WG since last August, and has received too 
little review. ACME participants are encouraged to read and review, so that we 
can make changes if such are needed, and progress the document for publication.

Linsk:
Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ 

Plain text: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.txt 

HTML: https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-01.html 

PDF: https://tools.ietf.org/pdf/draft-ietf-acme-dtnnodeid-01.pdf 


Thanks in advance

Yoav___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] WGLC for ACME Integrations

[Yoav Nir]

Hi.

This starts a WGLC for the subject draft entitled “ACME Integrations. The call 
will end at EOD Monday, April 19th, 2001.

The document has been with the WG since last January, and has received some 
review. Following the closing of the last two issues, the authors believe and 
the sense of the room at IETF 110 was, that the document is ready.  ACME 
participants are encouraged to read and review, so that we can make changes if 
such are needed, and progress the document for publication.

Linsk:
Datatracker: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ 

Plain text: https://www.ietf.org/archive/id/draft-ietf-acme-integrations-03.txt 

HTML: https://datatracker.ietf.org/doc/html/draft-ietf-acme-integrations-03 

PDF: https://tools.ietf.org/pdf/draft-ietf-acme-integrations-03.pdf 


Thanks in advance

Yoav___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Yoav Nir]

> On 3 Mar 2021, at 21:36, Dan Harkins  wrote:
> 
>  
>   Faster and more secure seem to be compelling reasons. Those reasons are
> probably more compelling for ESP than they are for IKE.

Yes. If we were back in 2008 and figuring out which AEAD we should be using and 
they were both as unencumbered as they are now, maybe we would prefer OCB over 
GCM. 13 years later, every IPsec implementation has AES-GCM, so to add OCB to a 
product, it needs to be significantly better.  I haven’t seen recent numbers, 
but if I remember correctly, the performance difference was in the single-digit 
percentage points. It’s harder to quantify the security differences, but I 
don’t think they were compelling.  However, these arguments apply to a product, 
not necessarily to the protocol.  Adding this as an option for IPsec (and IKE) 
is just fine, whether vendors adopt it or not.

> 
>   The license for OCB always had some caveats like the code could not be used
> for military purposes which is something of a nightmare for a manufacturer of
> general purpose hardware/software. Considering how difficult it would be to
> ensure that your product is never used by a military anywhere in the world,
> that's probably enough of a reason for TLS to not support it. Remember how
> long ECC was delayed for (imagined) IP reasons? 
> 
>   IP is bad news. People don't want anything to do with partially encumbered
> technology. Now this technology is not encumbered at all so, yea, let's do it.
> 
>   If an individual draft was to appear would the WG adopt it as a work item?

Up to the WG, but I would support it.

Yoav

> 
>   regards,
> 
>   Dan.
> 
> On 2/28/21 1:47 PM, Yoav Nir wrote:
>> IIRC the license has allowed OCB to be used for TLS for several years. They 
>> haven’t taken it up. There are no AES-OCB ciphersuites 
>> inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
>>  
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4>
>> 
>> So I’m wondering right with you: It has a theoretical advantage in security 
>> and a measurable advantage in speed in software.  Neither were compelling 
>> enough for anyone to bother adding it in TLS ciphersuites.  Why should our 
>> conclusion be any different?
>> 
>> Yoav
>> 
>> 
>>> On 28 Feb 2021, at 22:35, Paul Wouters >> <mailto:p...@nohats.ca>> wrote:
>>> 
>>> 
>>> So now that OCB is finally free, do we want to implement it? :)
>>> 
>>> I'm honestly not sure if the improvements of AES-GCM are worth it.
>>> I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.
>>> 
>>> Paul
>>> 
>>> -- Forwarded message --
>>> Date: Sat, 27 Feb 2021 14:37:30
>>> From: "Salz, Rich via cryptography" >> <mailto:cryptogra...@metzdowd.com>>
>>> To: "cryptogra...@metzdowd.com <mailto:cryptogra...@metzdowd.com>" 
>>> mailto:cryptogra...@metzdowd.com>>
>>> Subject: [Cryptography] Direct public confirmation from Dr. Rogaway
>>> 
>>> 
>>> https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ 
>>> <https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/> :
>>> 
>>>  
>>> 
>>> I can confirm that I have abandoned all OCB patents
>>> 
>>> and placed into the public domain all OCB-related IP of mine.
>>> 
>>> While I have been telling people this for quite some time, I don't
>>> 
>>> think I ever made a proper announcement to the CFRG or on the
>>> 
>>> OCB webpage. Consider that done.
>>> 
>>>  
>>> 
>>> I hope people will use the scheme to do positive things.
>>> 
>>>  
>>> 
>>> phil
>>> 
>>> ___
>>> The cryptography mailing list
>>> cryptogra...@metzdowd.com <mailto:cryptogra...@metzdowd.com>
>>> https://www.metzdowd.com/mailman/listinfo/cryptography 
>>> <https://www.metzdowd.com/mailman/listinfo/cryptography>
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/ipsec 
>>> <https://www.ietf.org/mailman/listinfo/ipsec>
>> 
>> 
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ipsec 
>> <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> -- 
> "The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

[Yoav Nir]

IIRC the license has allowed OCB to be used for TLS for several years. They 
haven’t taken it up. There are no AES-OCB ciphersuites 
inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4>

So I’m wondering right with you: It has a theoretical advantage in security and 
a measurable advantage in speed in software.  Neither were compelling enough 
for anyone to bother adding it in TLS ciphersuites.  Why should our conclusion 
be any different?

Yoav


> On 28 Feb 2021, at 22:35, Paul Wouters  wrote:
> 
> 
> So now that OCB is finally free, do we want to implement it? :)
> 
> I'm honestly not sure if the improvements of AES-GCM are worth it.
> I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.
> 
> Paul
> 
> -- Forwarded message --
> Date: Sat, 27 Feb 2021 14:37:30
> From: "Salz, Rich via cryptography" 
> To: "cryptogra...@metzdowd.com" 
> Subject: [Cryptography] Direct public confirmation from Dr. Rogaway
> 
> 
> https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ :
> 
>  
> 
> I can confirm that I have abandoned all OCB patents
> 
> and placed into the public domain all OCB-related IP of mine.
> 
> While I have been telling people this for quite some time, I don't
> 
> think I ever made a proper announcement to the CFRG or on the
> 
> OCB webpage. Consider that done.
> 
>  
> 
> I hope people will use the scheme to do positive things.
> 
>  
> 
> phil
> 
> ___
> The cryptography mailing list
> cryptogra...@metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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: [I2nsf] Request for Online Meeting for I2NSF WG Rechartering

[Yoav Nir]

Hi.

This is to remind dveryone that I2NSF is holding a virtual interim meeting in 
24 hours to discuss a possible re-chartering.  Paul will present his proposal.

Zoom link:  
https://Dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09 
<https://dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09>

Linda & Yoav

> On 18 Nov 2020, at 14:02, Yoav Nir  wrote:
> 
> Hi.
> 
> I\ve set a Zoom meeting for December 3rd. The link is below:
> https://Dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09 
> <https://dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09>
> 
> 
> An interim meeting for  has been approved or does not require additional 
> approval.
> A message has been sent to the secretariat requesting the interim be 
> announced.
> 
> 
> -
> Name:
> Session Requester:
> 
> Meeting Type: Virtual Meeting
> 
> Session 1:
> 
> Date: 2020-12-03
> Start Time: 14:00 UTC
> Duration: 01:30
> Remote Participation Information: 
> https://dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09 
> <https://dell.zoom.us/j/97095207458?pwd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09>
> Agenda Note:
> 
> 



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

Re: [I2nsf] Request for Online Meeting for I2NSF WG Rechartering

[Yoav Nir]

ZXRxZz09
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:647149540
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONS:[{"DisplayName":"https://Dell.zoom.us/j/97095207458?p
 wd=RHpTUWpMVE42VFkzV1RWd0F5ZXRxZz09"\,"LocationAnnotation":""\,"LocationUr
 i":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":""\,"Locati
 onCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":""}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
On 16 Nov 2020, at 3:38, Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> wrote:Hi Roman,Thanks for your kind guidance.I think it will be better to have an online interim meeting after two weeks for the discussion of the I2NSF re-chartering.I also think there are several organizations to have the new work items.They will speak up their voice in the matter of the re-chartering soon.Thanks.Best Regards,PaulOn Mon, Nov 16, 2020 at 1:44 AM Roman Danyliw <r...@cert.org> wrote:






Hi! It seems like a great idea to gather the WG group to discuss the issue.  A gentle reminder -- it isn’t possible to convene an interim meeting during the virtual IETF 109 week.  Likewise, such a meeting ideally needs two weeks notice to
 allow the participants digest the planned topics of discussion.  Of course, nothing stops individuals from informally gathering, but this is not an official meeting. When we do get to discussing re-charter I’m going to be looking if there is energy and broad support for this proposed new work.  Ideally, there were would be excitement and willingness to implement from beyond the current set of authors
 on the inflight documents. Regards,Roman  


From: I2nsf <i2nsf-boun...@ietf.org> On Behalf Of 
Mr. Jaehoon Paul Jeong
Sent: Wednesday, November 11, 2020 10:46 PM
To: Linda Dunbar <linda.dun...@futurewei.com>
Cc: Roman Danyliw <r...@cert.org>; DIEGO LOPEZ GARCIA <diego.r.lo...@telefonica.com>; i2nsf@ietf.org; Yoav Nir <ynir.i...@gmail.com>; JungSoo Park <p...@etri.re.kr>; Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com>; Xialiang (Frank) <frank.xiali...@huawei.com>;
 Yunchul Choi <cy...@etri.re.kr>; Younghan Kim <young...@ssu.ac.kr>; Patrick Lingga <patricklink...@gmail.com>; skku-iotlab-members <skku-iotlab-memb...@googlegroups.com>; Qin Wu <bill...@huawei.com>; Susan Hares <sha...@ndzh.com>; Hyunsik Yang <yan...@dcn.ssu.ac.kr>
Subject: Re: [I2nsf] Request for Online Meeting for I2NSF WG Rechartering

 
Linda,
Yes, I am requesting an informal session to discuss the text for re-chartering.

Could you set up an informal session date/time for I2NSF WG re-chartering next week?

 

If you want, I can set up a WebEx meeting.

 

In any case, could you decide the meeting date and time?

 

I will provide you and the I2NSF WG with the text for re-chartering this weekend.

 

Thanks.

 

Best Regards,

Paul

 

 

On Thu, Nov 12, 2020 at 11:25 AM Linda Dunbar <linda.dun...@futurewei.com> wrote:



Paul,
 Thank you very much for writing the 3 additional drafts for I2NSF. I already read through them.
Waiting review your drafted re-chartering text. Make sure to identify clearly the detailed work items.
 Are you  requesting an informal session to discuss the text for re-chartering?It would be good to give people some time to review.
 Thank you.
 Linda
From: Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com>

Sent: Tuesday, November 10, 2020 12:54 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; Yoav Nir <ynir.i...@gmail.com>
Cc: Roman Danyliw <r...@cert.org>;
i2nsf@ietf.org; DIEGO LOPEZ GARCIA <diego.r.lo...@telefonica.com>; Susan Hares <sha...@ndzh.com>;
 Xialiang (Frank) <frank.xiali...@huawei.com>; Qin Wu <bill...@huawei.com>; Younghan Kim <young...@ssu.ac.kr>;
 JungSoo Park <p...@etri.re.kr>; Yunchul Choi <cy...@etri.re.kr>; Patrick Lingga <patricklink...@gmail.com>;
 Hyunsik Yang <yan...@dcn.ssu.ac.kr>; skku-iotlab-members <skku-iotlab-memb...@googlegroups.com>; Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com>
Subject: Request for Online Meeting for I2NSF WG Rechartering 
Hi Linda and Yoav,
I would like to suggest an online meeting for I2NSF WG Rechartering

during the IETF-109 week (from November 16 to November 20).

 

Diego Lopez and I expressed new work items for our I2NSF WG before.

 

I am preparing the text for the I2NSF WG Recharter and will share it with our I2NSF WG this week.

 

The new work items to be discussed  

Re: [I2nsf] I2NSF Re-chartering Text

[Yoav Nir]

Does Thursday, December 3rd at 14:00 UTC work for everyone?

It’s 16:00 for me, 15:00 for much of Europe, 9:00 AM EST, 6:00 AM PST, and 
unfortunately, 23:00 in Seoul.

I’ll wait 24 hours before scheduling the meeting in case there are objections.

Yoav


> On 16 Nov 2020, at 3:44, Mr. Jaehoon Paul Jeong  
> wrote:
> 
> Hi Yoav,
> I agree that we can schedule our online interim meeting on the week of the 
> 29th / first week of December.
> 
> Could you schedule such an interim meeting?
> 
> I believe that we can get more people to be engaged in the new I2NSF work 
> items
> other than the authors of the current I2NSF WG and individual drafts.
> With those people, I hope our I2NSF WG can have more energy. :)
> 
> Thanks.
> 
> Best Regards,
> Paul
> 
> On Mon, Nov 16, 2020 at 1:59 AM Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> Hi, Paul
> 
> As Roman said in a separate email message, we can’t schedule a meeting during 
> IETF week. It also requires two weeks notice, so it anyway can only be done 
> on the week of the 29th / first week of December.
> 
> That’s not a bad thing: it will give people enough time to read the charter 
> and form an opinion before coming to the meeting.
> 
> If and when we have this meeting, I think we need to get a good number (5 
> maybe?) or people who are not authors and will commit to reviewing the 
> proposed documents. I think it is very obvious that this working group has 
> lost energy, and we wouldn’t want to take on more work unless there is a 
> clear indication that there will be such energy going forward.
> 
> Yoav
> 
>> On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong > <mailto:jaehoon.p...@gmail.com>> wrote:
>> 
>> Hi Linda and Yoav,
>> Here is the text for I2NSF WG Re-chartering.
>> ---
>> Charter for Working Group
>> 
>> Interface to Network Security Functions (I2NSF) provides security vendors 
>> with a standard framework and interfaces for cloud-based security services. 
>> I2NSF enables the enforcement of a high-level security policy of a user's 
>> perspective in a target network (e.g., cloud network and edge network). This 
>> security policy enforcement in I2NSF is a data-driven approach using 
>> NETCONF/YANG or RESTCONF/YANG where a security policy is constructed into an 
>> XML file based on a YANG data model.
>> 
>> The I2NSF framework consists of four components such as I2NSF User, Security 
>> Controller, Network Security Function (NSF), and Developer's Management 
>> System (DMS). I2NSF User specifies a high-level security policy for a target 
>> network (e.g., cloud network). Security Controller maintains the capability 
>> of an NSF and takes a security policy from I2NSF User for the enforcement of 
>> the corresponding security service. An NSF performs a specific security 
>> service (e.g., firewall, web filter, deep packet inspection, and DDOS-attack 
>> mitigator) according to a security policy rule. DMS registers the capability 
>> of an NSF with Security Controller.
>> 
>> The I2NSF framework has four interfaces such as Consumer-Facing Interface, 
>> NSF-Facing Interface, Registration Interface, and Monitoring Interface. 
>> Consumer-Facing Interface is used to deliver a high-level security policy 
>> from I2NSF User to Security Controller. NSF-Facing Interface is used to 
>> deliver a low-level security policy from Security Controller to an NSF. 
>> Registration Interface is used to register the capability of an NSF with 
>> Security Controller. Monitoring Interface is used to collect monitoring data 
>> from an NSF.
>> 
>> The goal of I2NSF is to define a set of software interfaces and data models 
>> of such interfaces for configuring, maintaining, and monitoring NSFs in 
>> Network Functions Virtualization (NFV) environments. For security management 
>> automation in an autonomous security system, I2NSF needs to have a feedback 
>> control loop consisting of security policy configuration in an NSF, 
>> monitoring for an NSF, data analysis for NSF monitoring data, feedback 
>> delivery, and security policy augmentation/generation. For this security 
>> management automation, the I2NSF framework requires a new component to 
>> collect NSF monitoring data and analyze them, which is called I2NSF 
>> Analyzer. Also, the I2NSF framework needs a new interface to deliver a 
>> feedback message for security policy adjustment from I2NSF Analyzer to 
>> Security Controller.
>> 
>> I2NSF is vulnerable to an inside attack and a su

Re: [I2nsf] I2NSF Re-chartering Text

[Yoav Nir]

Hi, Paul

As Roman said in a separate email message, we can’t schedule a meeting during 
IETF week. It also requires two weeks notice, so it anyway can only be done on 
the week of the 29th / first week of December.

That’s not a bad thing: it will give people enough time to read the charter and 
form an opinion before coming to the meeting.

If and when we have this meeting, I think we need to get a good number (5 
maybe?) or people who are not authors and will commit to reviewing the proposed 
documents. I think it is very obvious that this working group has lost energy, 
and we wouldn’t want to take on more work unless there is a clear indication 
that there will be such energy going forward.

Yoav

> On 15 Nov 2020, at 18:26, Mr. Jaehoon Paul Jeong  
> wrote:
> 
> Hi Linda and Yoav,
> Here is the text for I2NSF WG Re-chartering.
> ---
> Charter for Working Group
> 
> Interface to Network Security Functions (I2NSF) provides security vendors 
> with a standard framework and interfaces for cloud-based security services. 
> I2NSF enables the enforcement of a high-level security policy of a user's 
> perspective in a target network (e.g., cloud network and edge network). This 
> security policy enforcement in I2NSF is a data-driven approach using 
> NETCONF/YANG or RESTCONF/YANG where a security policy is constructed into an 
> XML file based on a YANG data model.
> 
> The I2NSF framework consists of four components such as I2NSF User, Security 
> Controller, Network Security Function (NSF), and Developer's Management 
> System (DMS). I2NSF User specifies a high-level security policy for a target 
> network (e.g., cloud network). Security Controller maintains the capability 
> of an NSF and takes a security policy from I2NSF User for the enforcement of 
> the corresponding security service. An NSF performs a specific security 
> service (e.g., firewall, web filter, deep packet inspection, and DDOS-attack 
> mitigator) according to a security policy rule. DMS registers the capability 
> of an NSF with Security Controller.
> 
> The I2NSF framework has four interfaces such as Consumer-Facing Interface, 
> NSF-Facing Interface, Registration Interface, and Monitoring Interface. 
> Consumer-Facing Interface is used to deliver a high-level security policy 
> from I2NSF User to Security Controller. NSF-Facing Interface is used to 
> deliver a low-level security policy from Security Controller to an NSF. 
> Registration Interface is used to register the capability of an NSF with 
> Security Controller. Monitoring Interface is used to collect monitoring data 
> from an NSF.
> 
> The goal of I2NSF is to define a set of software interfaces and data models 
> of such interfaces for configuring, maintaining, and monitoring NSFs in 
> Network Functions Virtualization (NFV) environments. For security management 
> automation in an autonomous security system, I2NSF needs to have a feedback 
> control loop consisting of security policy configuration in an NSF, 
> monitoring for an NSF, data analysis for NSF monitoring data, feedback 
> delivery, and security policy augmentation/generation. For this security 
> management automation, the I2NSF framework requires a new component to 
> collect NSF monitoring data and analyze them, which is called I2NSF Analyzer. 
> Also, the I2NSF framework needs a new interface to deliver a feedback message 
> for security policy adjustment from I2NSF Analyzer to Security Controller.
> 
> I2NSF is vulnerable to an inside attack and a supply chain attack since it 
> trusts in NSFs provided by DMS, assuming that NSFs work for their security 
> services appropriately. Also, I2NSF trusts in I2NSF User and Security 
> Controller. The registration of an NSF's capability, the enforcement of a 
> security policy from either I2NSF User or Security Controller, and the 
> monitoring data from an NSF are assumed to be genuine and non-malicious. If 
> one of such activities is malicious, the security system based on I2NSF may 
> collapse. To prevent this malicious activity from happening in the I2NSF 
> framework or detect the root of a security attack, all the activities in the 
> I2NSF framework should be logged in either a centralized way or a 
> decentralized way (e.g., blockchain). Also, the operations and activities of 
> the I2NSF components (i.e., I2NSF User, Security Controller, NSF, DMS, and 
> I2NSF Analyzer) need to be verified by remote attestation.
> 
> Furthermore, an NSF can be instantiated as either a Virtual Network Function 
> (VNF) in an NFV-based cloud or a container in a native cloud. The current 
> YANG data models for the I2NSF interfaces are designed on the basis of VNF, 
> so they need to be redesigned for the case where I2NSF components are 
> instantiated by containers.
> 
> The I2NSF working group's deliverables include:
> 
> o A single document for an extension of I2NSF 

Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[Yoav Nir]

> On 31 Oct 2020, at 15:12, tom petch  wrote:
> 
> On 30/10/2020 22:42, Tero Kivinen wrote:
>> Roman Danyliw writes:
>> It seems to me that the IANA entries for IKEv2 are incomplete.
>> RFC8247 does a fine job of specifying algorithms and adding
>> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
>> information which is not present on IANA.  The policy for, e.g.
>> Transform Type 1, is expert review and entries have been added via
>> draft-smyslov-esp-gont but the IANA entries lack this information
>> and, looking at the I-D, I see no such information (nor is there any
>> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs
>> this information as references in the YANG module show.
>> 
>> I am lost what information is missing from the IANA registry.
> 
> 
> Tero
> 
> Thanks for getting back to me.  What is missing from the IANA registry is the 
> guidance as to the status of the algorithm, how highly it is recommended or 
> not.  This I-D tells people to go to RFC8247 and the IANA Registry for 
> advice; RFC8247 gives that advice; the IANA web page does not.

It’s possible to add a column in the IANA registry, but it is not possible to 
capture the information from 8247 in such a table. 

RFC 8247 has “MAY” and “SHOULD+” labels, but it also has comments and a bunch 
of explanation, such as that some algorithm is a SHOULD for IoT, but not 
otherwise. I think it’s better to point people at the RFC where the information 
is, rather than post very partial information in an IANA table.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [I2nsf] [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[Yoav Nir]

> On 31 Oct 2020, at 15:12, tom petch  wrote:
> 
> On 30/10/2020 22:42, Tero Kivinen wrote:
>> Roman Danyliw writes:
>> It seems to me that the IANA entries for IKEv2 are incomplete.
>> RFC8247 does a fine job of specifying algorithms and adding
>> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
>> information which is not present on IANA.  The policy for, e.g.
>> Transform Type 1, is expert review and entries have been added via
>> draft-smyslov-esp-gont but the IANA entries lack this information
>> and, looking at the I-D, I see no such information (nor is there any
>> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs
>> this information as references in the YANG module show.
>> 
>> I am lost what information is missing from the IANA registry.
> 
> 
> Tero
> 
> Thanks for getting back to me.  What is missing from the IANA registry is the 
> guidance as to the status of the algorithm, how highly it is recommended or 
> not.  This I-D tells people to go to RFC8247 and the IANA Registry for 
> advice; RFC8247 gives that advice; the IANA web page does not.

It’s possible to add a column in the IANA registry, but it is not possible to 
capture the information from 8247 in such a table. 

RFC 8247 has “MAY” and “SHOULD+” labels, but it also has comments and a bunch 
of explanation, such as that some algorithm is a SHOULD for IoT, but not 
otherwise. I think it’s better to point people at the RFC where the information 
is, rather than post very partial information in an IANA table.

Yoav

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Secdir last call review of draft-ietf-quic-invariants-11

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Ready

The contents of the "security and privacy considerations" section seems to be
advice for middlebox authors. I think that it may have been better to name the
section something else.  However, there is no information that is missing, so I
don't really have any recommendations for changing things.

[Acme] WGLC on draft-ietf-acme-star-delegation

[Yoav Nir]

Hello all

   This memo proposes a profile of the ACME protocol that allows the
   owner of an identifier (e.g., a domain name) to delegate to a third
   party access to a certificate associated with said identifier.  A
   primary use case is that of a CDN (the third party) terminating TLS
   sessions on behalf of a content provider (the owner of a domain
   name).  The presented mechanism allows the owner of the identifier to
   retain control over the delegation and revoke it at any time by
   cancelling the associated STAR certificate renewal with the ACME CA.
   Another key property of this mechanism is it does not require any
   modification to the deployed TLS ecosystem.

Having this document discussed in the working group for almost two years, the 
authors and chairs believe that this document is ready for working group last 
call.

So this is to start a 2-week WGLC on this document. Please read the document 
and send comments to the list. Statements of support or opposition are also 
welcome, especially if accompanied by a technical explanation.

Send the comments to the list by EOD Monday 19-Oct-2020.

Rich & Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Meeting Materials Uploaded

[Yoav Nir]

Hi all,

I’ve just uploaded the meeting materials for tomorrow’s session.

https://datatracker.ietf.org/meeting/materials#acme 


If you’re presenting tomorrow, please check that your slides are there.

See you all tomorrow.

Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

[Yoav Nir]

Hi.

I uploaded a PDF version to the meeting materials. Also added a list of action 
items for the chairs.  Comments are welcome on that part as well.

https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 


Yoav

> On 28 Jul 2020, at 16:15, Tero Kivinen  wrote:
> 
> Here is preliminary minues from the IETF 108 IPsecME WG meeting. I
> copied some discussion about the proposed changes to ESP from Jabber
> to here, as I think it was important to record those even when we did
> not have time to have comments during the meeting. 
> 
> If you have any comments, please send them to me as soon as possible. 
> --
> # IPsecME IETF 108
> 
> Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC
> 
> ## Agenda:
> * 11:00-11:05 - Note Well, technical difficulties and agenda bashing
> * 11:05-11:10 - Document status (chairs)
> * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy)
> * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery)
> * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery)
> * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg)
> * 12:00-12:15 - IPTFS (Christian Hopps)
> * 12:15-12:30 - YANG model for IPTFS (Christian Hopps)
> * 12:30-12:40 - AOB + Open Mic
> 
> ### Note Well, technical difficulties and agenda bashing
> *Chairs* (5min)
> 
> No Edits
> 
> ### Document status
> *chairs* (5min)
> 
> *-implicit-Iv published as RFC8750
> *-qr-ikev2 published as RFC8784
> 
> *-ipv6-ipv4-codes publication requested
> 
> ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec)
> *Valery/Tommy* (15min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00
> 
> Paul Wouters: What are the kernel implications? And does this allow for 
> smaller IPsec/ESP Packets?
> Valery: Text is a bit short, TCP stream packets will have same class
> Paul: What Interop testing has been done?
> Valery: Tested with Apple, Cisco, libreswan
> 
> Piannissimo Hum for who has read the draft
> 
> Paul: Good idea to adopt, found issues that would be good to incorporate in 
> draft
> 
> Yoav: Will take to list if we need an update to 8229 and if this is the right 
> starting point.
> 
> ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS)
> *Valery* (10min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for-encrypted-dns-00
> 
> Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope 
> bit)
> 
> Valery: Still an interesting subject
> 
> Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, 
> for DoH, need to provide URI template
> 
> Valery: Presentation also requested in ADD, but didn't have room in agenda.  
> Re: URI, will be covered in DoH clarifications (?)
> 
> Ben: When DoQ arrives may need additional work
> 
> Tero: Add configuration attributes, less internal strucutre, more higher 
> level structure
> 
> Yoav (participant): Missing motivation from draft  Moving towards encrypted 
> world, don't want to force people to keep insecure DNS just for legacy IKEv2 
> server 
> 
> Valery: That is one of the motivations; users won't see this, but it is 
> useful.
> 
> Tirumaleswar Reddy: URL can be discovered another way
> 
> Benedict Wong: My understanding is that in some cases we need a hostname to 
> do validation of the DoT server
> 
> Tirumaleswar: This only supports PKI-based verification, so we can verify 
> based on sent certificate.
> 
> Yoav: Calling for adoption?
> 
> Valery: ADD Primary target for adoption, ipsecme is just informational, if 
> there is interest it could persist in this WG, but not yet.
> 
> Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make 
> sure both working groups are aware of work
> 
> Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks 
> it makes sense, it's good information for ADD to have
> 
> ### draft-smyslov-ipsecme-ikev2-auth-announce
> *Valery* (10min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported-authentication-methods-in-ikev2-00
> 
> Paul: Good idea, unclear where complexity might be, in the past migration 
> between methods (null -> something else) needed a ppk hack - sending two auth 
> payloads
> 
> Tero (participant): Could have one part negotiate the algorithm, and the 
> second part to negotiate the algorithm ids for CAs in the certreq
> 
> Yoav: will take a call for adoption to the list
> 
> ### Proposed improvements to ESP
> *Michael Rossberg* (15min)
> 
> Slides link: 
> https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01
> 
> Yoav (?): Discussion happening on list and in jabber.  Informational would be 
> wrong, changes packet on wire, so experimental or standards track if anything
> 
> Summary of 

Re: [IPsec] Teaser for pitch talk at IETF 108

[Yoav Nir]

> On 24 Jul 2020, at 23:42, Michael Rossberg  
> wrote:
> 
> Wiliam, Yoav,
> 
> thanks for the comments, I’ll try to elaborate in a single mail as you are 
> heading in a similar direction.
> 
>> RFC 6311 allows multiple members in a cluster of IPsec gateways to have 
>> independent parallel SAs so as to solve the problem of synchronization and 
>> counter re-use among nodes.
>> 
>> While the focus there is on different nodes, the synchronization problem 
>> also exists between cores of a single node. There is no reason to think RFC 
>> 6311 could not be adapted to multi-core nodes.
>> 
>> So I’m wondering if we really need multi-window logic to scale over CPUs, or 
>> whether it would be simpler to just generate multiple SAs for multiple CPUs.
> 
> If one just has a couple of IPsec gateways happening to be many-core systems, 
> I totally agree that
> multiple SAs would be the way to go. IMHO there are still a couple 
> differences in protocol handling
> that may be an advantage here and there, but nothing which justifies a 
> protocol change in the data
> plane.
> 
> Now our believe is that the many-core issue is just a special case of a 
> broader issue. There are more
> reasons to have unsynchronised replay windows.

Right. And my question is, why not have multiple SAs instead of multiple 
windows within an SA.

The advantage of multiple SAs is that you don’t really need to change the other 
side of the IPsec connection (especially if the peer already supports 6311).  
So if you have 30 cluster members, or 30 CPUs, or 30 virtual LANs, or 30 QoS 
classes, you can generate 30 SAs rather than 30 windows within 1 SA.

An SA is rather cheap:  It requires a value out of a 32-bit space. It requires 
at a minimum saving the key and current counter. Usually also a 64-bit replay 
bitmap at the receiver. Add metadata and we’re talking about a few dozen bytes. 
Add an expanded key for performance, and we’re still under a kilobyte. 

I’m not saying it’s a better design, but a new design should come with an 
explanation of why it’s better.

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Teaser for pitch talk at IETF 108

[Yoav Nir]

Hi, Michael.

Thanks for bringing this to the group.

> On 22 Jul 2020, at 13:26, Michael Rossberg  
> wrote:
> 
> 
> We have been analyzing issues ESP has in current data-center networks and 
> came to
> the conclusion that changes in the protocol could significantly improve its 
> behavior. Some
> of results will be presented next Tuesday in a pitch talk at IETF 108. This 
> mail is just a
> small teaser, in case some of you wanted to gather some arguments for the 
> discussion.
> 
> In particular, we propose the following changes to ESP:
> 
>   * Allow multiple windows per SA to allow for scaling over CPUs, windows 
> per QoS
> class & replay protection in multicast groups
>   * 64 bit sequence counters in each header to ease protocol handling and 
> allow for
> replay protection in multicast groups
>   * Removing the trailer to ease segment & fragment handling and alignment
>   * Implicit IVs in spirit of RFC 8750 removing the need for AAD
> 
> Further details and benchmark results may be found in a paper preprint [1] 
> and a
> presentation [2] we held with at the Linux IPsec Workshop.

RFC 6311 allows multiple members in a cluster of IPsec gateways to have 
independent parallel SAs so as to solve the problem of synchronization and 
counter re-use among nodes. 

While the focus there is on different nodes, the synchronization problem also 
exists between cores of a single node. There is no reason to think RFC 6311 
could not be adapted to multi-core nodes.

So I’m wondering if we really need multi-window logic to scale over CPUs, or 
whether it would be simpler to just generate multiple SAs for multiple CPUs.

Yoav
(with no hats other than co-author of RFC 6311) 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Agenda Uploaded

[Yoav Nir]

Please note that the times given are UTC.

https://www.ietf.org/proceedings/108/agenda/agenda-108-ipsecme-00 


Yoav___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsecme - Requested session has been scheduled for IETF 108

[Yoav Nir]

Hi, all

Notice that the times for our session is stated in UTC. 11:00 UTC is 13:00 in 
Madrid (where we were supposed to meet), 14:00 in Moscow and Israel, 7:00 AM in 
the eastern US, 4:00 AM (sorry, folks) in the Pacific US, and 19:00 in Beijing.

If you need a time-slot for this meeting, please send your request to the 
chairs. Valery has already sent three requests; no need to re-send them.

Tero & Yoav

> On 3 Jul 2020, at 3:20, IETF Secretariat  wrote:
> 
> Dear Yoav Nir,
> 
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request. 
> 
> 
>ipsecme Session 1 (1:40 requested)
>Tuesday, 28 July 2020, Session I 1100-1240
>Room Name: Room 6 size: 6
>-
> 
> 
> iCalendar: https://datatracker.ietf.org/meeting/108/sessions/ipsecme.ics
> 
> Request Information:
> 
> 
> -
> Working Group Name: IP Security Maintenance and Extensions
> Area Name: Security Area
> Session Requester: Yoav Nir
> 
> 
> Number of Sessions: 1
> Length of Session(s):  100 Minutes
> Number of Attendees: 30
> Conflicts to Avoid: 
> Chair Conflict: tls acme
> Technology Overlap: cfrg
> 
> 
> 
> 
> 
> 
> People who must be present:
>  Yoav Nir
>  Tero Kivinen
>  Benjamin Kaduk
> 
> Resources Requested:
> 
> Special Requests:
> 
> -
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

[talking as another individual and co-author of RFC7296, not as the other chair]


> On 18 Jun 2020, at 21:03, Tero Kivinen  wrote:
> 
> [talking as individual and one of RFC7296 authors, not as WG chair].
> 
> Toerless Eckert writes:
>> On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
>>> The RFC states:
>>> 
>>>   The USE_TRANSPORT_MODE notification MAY be included in a request
>>>   message that also includes an SA payload requesting a Child SA.  It
>>>   requests that the Child SA use transport mode rather than tunnel mode
>>>   for the SA created.  If the request is accepted, the response MUST
>>>   also include a notification of type USE_TRANSPORT_MODE.  If the
>>>   responder declines the request, the Child SA will be established in
>>>   tunnel mode.
> 
> At this point the responder already created an Child SA in tunnel
> mode, and when the initiator receives that message from the responder
> it will also create the Child SA in tunnel mode. Responder might
> already be sending traffic at this point.
> 
> This means both initiator and responder MUST implement tunnel mode, as
> otherwise they cannot perform those actions. Meaning as the fallback
> from the transport mode is tunnel mode, all implementations MUST
> implement it even if it not explictly said in the RFC.

I half agree. RFC 7296 describes IKEv2, not IPsec. An IKEv2 implementation must 
support the creation of a tunnel-mode Child SA. It may configure an IPsec layer 
that does not support tunnel-mode.

I think it’s compliant with the letter if not the spirit of RFC 7296 to have a 
specialized IKEv2 implementation that can negotiate a tunnel mode SA, but 
immediately deletes such an SA if it is created, and I think such an 
implementation will also be compliant if it rejects any CREATE_CHILD_SA request 
that does not include the USE_TRANSPORT_MODE notification.

Of course none of us would use such an implementation in our VPN gateway, but 
it can be appropriate for special uses, such as host-to-host within a 
datacenter.

Having said that, supporting tunnel mode as a fallback and making transport a 
SHOULD is still a good idea. Tunnel mode has a per-packet extra cost of 20 or 
40 bytes, but it’s generally better than no communications at all.

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[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: [IPsec] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

[Yoav Nir]

[With chair hat on]

Yes, the charter says that we are to make a guidance document. If the working 
group feels that it’s better to put the specification and guidance in a single 
document, we can work on that and clear it with the ADs. 

Charters can be modified.

Yoav

> On 29 Apr 2020, at 18:42, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
>> Hi Valery,
>> 
>> Thanks for bringing this up again. Would you be interested in making this
> an
>> RFC8229bis instead? I think it would be most useful for an implementer to
> fold
>> some of these clarifications into the main text itself. How do you feel
> about
>> that?
> 
> I'd be happy to do it. I also think that a -bis document is more useful.
> The reason that this draft is not a rfc8229bis is that one and half
> year ago it was a general feeling that more experience need to be
> collected before -bis document should be issued. Now it is almost
> 3 years since rfc8229 is published, I agree that it's probably time to start
> preparing -bis.
> 
> One concern is the current WG charter - 
> it seems to me that it only allows
> clarification document and not a -bis.
> It is a question to our chairs and AD - are
> we allowed to proceed with rfc8229bis document
> with the current charter text or should we update it
> and ask for re-chartering?
> 
> Regards,
> Valery.
> 
> 
>> Best,
>> Tommy
>> 
>>> On Apr 28, 2020, at 2:54 AM, Valery Smyslov 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> a one and half year ago at IETF 103 in Bangkok I presented
>>> draft-smyslov-ipsecme-tcp-guidelines
>>> "Clarifications and Implementation Guidelines for using TCP
>>> Encapsulation in IKEv2"
>>> 
> (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/).
 From my recollection of the meeting and from minutes it was a general
>>> feeling in the room that
>>> this document was useful for implementers, since it clarified some
>>> subtle issues that were not covered in RFC 8229. However, at that time
>>> no adoption call was issued since this work would require to update
>>> the IPSECME charter.
>>> It took over a year to adopt the updated charter and now the WG is
>>> chartered for this work with this draft as a possible starting point.
>>> The text in the charter:
>>> 
>>> RFC8229, published in 2017, specifies how to encapsulate
>>> IKEv2 and ESP traffic in TCP. Implementation experience has
>>> revealed that not all situations are covered in RFC8229, and that
> may
>>> lead to interoperability problems or to suboptimal performance. The
>>> WG
>>> will provide a document to give implementors more guidance about how
>>> to use
>>> reliable stream transport in IKEv2 and clarify some issues that have
>>> been
>>> discovered.
>>> 
>>> However, since it was so long since the WG last discussed the draft,
>>> the chairs asked me to send a message to the list to determine whether
>>> there is still an interest in the WG to proceed with this work with
>>> this draft as a starting point.
>>> 
>>> Regards,
>>> Valery.
>>> 
>>> 
>>> 
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[IPsec] Holding a virtual interim meeting. Or not

[Yoav Nir]

Hi all.

As you know, the in-person IETF meeting in Vancouver has been cancelled. There 
is a reduced schedule for virtual meetings [1], but it does not include 
IPsecME.  The IESG chair has published a recommended schedule [2] for the 
working groups to hold virtual meetings in April instead of the physical 
session in Vancouver.  For IPsecME, the chosen date is Wednesday, April 8th, 
but we are free to choose to meet at that date at whatever time is convenient, 
or we may choose a different date in May, or we may skip the meeting altogether 
if we don’t believe there is added value in holding a virtual meeting over just 
using email.

Please note that virtual meetings are pretty poor for status and progress 
reports. They are functional for specific discussion and for making decisions.

So, if you are interested in holding a meeting, please reply to this with three 
pieces of information:
Work item you would like to discuss online, for example: the traffic flow 
security draft  (possible to have more than 1)
A thing you think requires discussion online that doesn’t seem to get settled 
in email (example: which protocol number to use)
Preferred time of day for the interim meeting (please state that in UTC to 
avoid confusion)

Thanks,

Tero & Yoav

[1] https://datatracker.ietf.org/meeting/107/agenda 

[2] 
https://trac.ietf.org/trac/wgchairs/raw-attachment/wiki/WikiStart/April2020-RecommendedSchedule.pdf
 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[Acme] Holding a virtual interim meeting. Or not

[Yoav Nir]

Hi all.

As you know, the in-person IETF meeting in Vancouver has been cancelled. There 
is a reduced schedule for virtual meetings [1], but that does not include ACME. 
 The IESG chair has published a recommended schedule [2] for the working groups 
to hold virtual meetings in April instead of the physical session in Vancouver. 
 For ACME, the chosen date is Monday, April 6th, but we are free to choose to 
meet at that date at whatever time is convenient, or we may choose a different 
date in May, or we may skip the meeting altogether if we don’t believe there is 
added value in holding a virtual meeting over just using email.

Please note that virtual meetings pretty poor for status and progress reports. 
They are functional for discussion and making decisions.

So, if you are interested in holding a meeting, please reply to this with three 
pieces of information:
Work item you would like to discuss online (example: the email-smime draft  
(possible to have more than 1)
Think you think requires discussion (example: Need to support text/html mail 
for the challenge)
Preferred time of day for the interim meeting (please state that in UTC to 
avoid confusion)

Thanks,

Rich & Yoav

[1] https://datatracker.ietf.org/meeting/107/agenda
[2] 
https://trac.ietf.org/trac/wgchairs/raw-attachment/wiki/WikiStart/April2020-RecommendedSchedule.pdf___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 107; agenda

[Yoav Nir]

The IESG are considering the options and will let us know. The intent is still 
to have a week of virtual meetings.

After that ACME can decide if we’re participating in that, or making our own 
virtual interim a few weeks later.

> On 10 Mar 2020, at 22:21, Mary Barnes  wrote:
> 
> So, I thought it was a possibility to have the week consist of all virtual 
> meetings.  Or has that been totally removed from the table?  Some of us like 
> that option as we've already blocked that week in our calendars.  
> 
> On Tue, Mar 10, 2020 at 3:07 PM Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> 
> 
> > On 9 Mar 2020, at 17:11, Salz, Rich  > <mailto:40akamai@dmarc.ietf.org>> wrote:
> > 
> > Yaron and I cannot attend and will be remote.  We have volunteers to act as 
> > chairs for us (on CC).  Looking at the list below, it seems reasonable to 
> > cancel our session.  PLEASE POST IF YOU DISAGREE.  Of course "they" may 
> > decide to cancel anyway, but please post your opinion here.
> 
> As it turns out, this decision has been made for us, as the entire meeting 
> has been cancelled.
> 
> We will discuss on this list whether, when, and in what format we are 
> planning on having a virtual meeting to replace the physical one.
> 
> See you all around, physically or virtually
> 
> Rich and Yoav
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 107; agenda

[Yoav Nir]

> On 9 Mar 2020, at 17:11, Salz, Rich  wrote:
> 
> Yaron and I cannot attend and will be remote.  We have volunteers to act as 
> chairs for us (on CC).  Looking at the list below, it seems reasonable to 
> cancel our session.  PLEASE POST IF YOU DISAGREE.  Of course "they" may 
> decide to cancel anyway, but please post your opinion here.

As it turns out, this decision has been made for us, as the entire meeting has 
been cancelled.

We will discuss on this list whether, when, and in what format we are planning 
on having a virtual meeting to replace the physical one.

See you all around, physically or virtually

Rich and Yoav

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] IETF 107; agenda

[Yoav Nir]

…and Yoav won’t be there either. No idea about Yaron.

> On 9 Mar 2020, at 17:11, Salz, Rich  wrote:
> 
> Yaron and I cannot attend and will be remote.  We have volunteers to act as 
> chairs for us (on CC).  Looking at the list below, it seems reasonable to 
> cancel our session.  PLEASE POST IF YOU DISAGREE.  Of course "they" may 
> decide to cancel anyway, but please post your opinion here.
> 
> Let’s look at the documents in our queue and see which need time at IETF 107. 
>  See https://datatracker.ietf.org/wg/acme/documents/ to link to the document.
> 
> draft-ietf-acme-authority-token-04, ACME Challenges Using an Authority Token 
> -and-
> draft-ietf-acme-authority-token-tnauthlist-05,  TNAuthList profile of ACME 
> Authority Token
>   Any update from the authors?  Is this ready for WGLC?
>   This has never had much in-person discussion, and the domain expertise 
> is in STIR
> 
> draft-ietf-acme-client-00, ACME End User Client and Code Signing Certificates
>   Any updates?  This was recently adopted by the WG.
> 
> draft-ietf-acme-integrations-00, ACME Integrations
>   Michael Richardson can present.
> 
> draft-friel-acme-subdomains-02
>   Michael Richardson can present; this is a topic for WG adoption
> 
> draft-ietf-acme-email-smime-06, Extensions to Automatic Certificate 
> Management Environment for end user S/MIME certificates
>   Any updates?  Ready for WGLC?
> 
> draft-ietf-acme-star-delegation-03, An ACME Profile for Generating Delegated 
> STAR Certificates
>   Yaron just pushed a new update.  Does this need F2F time?  The main 
> document (draft-ietf-acme-star-11,  Support for Short-Term, 
> Automatically-Renewed (STAR) Certificates in Automated Certificate Management 
> Environment (ACME) is already in IESG review and probably wants this one to 
> be in the same bundle.)
> 
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] The session in Vancouver - Looking for a volunteer

[Yoav Nir]

Hi

As it turns out, both Rich and I will not be able to attend IETF 107 due to 
company and government (in my case) restrictions on travel.

For now we hope not to cancel the ACME session.  Since neither of us is going 
to be on-site, we are looking for a volunteer to sling the slides, send around 
the blue sheets and operate the Big Red Button, which should see considerably 
more use this time.

So if you are: (1) still planning to attend, and (2) allowed to do so by your 
employer, your government, Canada’s government, and your significant others, 
and (3) willing to sit up front and run the meeting, please send a message to 
Rich and me.

We will still prepare the slides and will, if possible, even present them from 
home, but we really need someone to sit up front.

Thanks in advance.

Rich & Yoav.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

> On 26 Feb 2020, at 19:56, Michael Richardson  wrote:
> 
> 
> Yoav Nir  wrote:
>> The draft says “IPsec tunnel mode is required ”, so it’s not
>> transport. What goes in the TS payloads?
> 
> TSi=HostA-LL/128, TSr=HostB-LL/128, Protocol = GRE(47) or IPIP(41)

If that’s the intention, I don’t see why this should be tunnel mode. Both GRE 
and IPIP are tunnels, and they do not require ESP tunnel mode to add yet 
another IP header.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

The draft says “IPsec tunnel mode is required ”, so it’s not transport. What 
goes in the TS payloads?

> On 26 Feb 2020, at 3:20, Michael Richardson  wrote:
> 
> 
>> Michael: Yoav talked about the non-GRE case.
> 
> In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode.
> Which is literally the VTI case.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[Yoav Nir]

Hi, Toerless.

I trimmed below most of your background info.

> On 24 Feb 2020, at 21:50, Toerless Eckert  wrote:
> 
> [hope its fine to cross-post ipsec and ipsecme given how one is concluded, 
> but may have
> more long-time subscribers]

ipsec is this group’s mailing list. I don’t know that there even is an 
ipse...@ietf.org 

> We're looking for opinions about an IPsec profile for "Autonomic Control 
> Plane"
> draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of:
> 
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt
> 
> Quick background so you do not need to read anything more than 6.7.1.1.1:

I read a little more. Hope you don’t mind.

The profile seems fine to me. There is one thing that I think is missing.

The profile specifies that the ACP nodes should use tunnel mode (when GRE is 
not used), because:
   IPsec tunnel mode is required because the ACP will route/forward
   packets received from any other ACP node across the ACP secure
   channels, and not only its own generated ACP packets.  With IPsec
   transport mode, it would only be possible to send packets originated
   by the ACP node itself.
OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but 
that’s not important here) they need an IPsec policy that specifies traffic 
selectors so that IKEv2 can specify traffic selectors.  Nowhere in your draft 
do I see a specification of what traffic selectors need to be negotiated.

If I understand the above paragraph correctly, both the source of the packet 
and the destination can be the IP address of any ACP node, neither of which are 
required to be the tunnel endpoints.  This implies some sort of generic traffic 
selector.  The draft should specify this, IMO

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[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

[IPsec] Publication has been requested for draft-ietf-ipsecme-ipv6-ipv4-codes-04

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-ipsecme-ipv6-ipv4-codes-04 as 
Proposed Standard on behalf of the IPSECME working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

[Yoav Nir]

Not really. You’ve added an explanation of why it’s hard to encrypt.  That is 
not needed IMO. What is needed is a statement that sending in the clear (not 
the default in IETF protocols these days) is OK because the data is not 
sensitive.

> On 18 Jan 2020, at 0:49, Michael Richardson  wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Yoav Nir via Datatracker  wrote:
> 
>> The draft is short and to the point and easy to understand.  The security
>> considerations (and privacy considerations!) sections are well written and
>> cover everything.  I'm just missing one clause.
> 
>> The first paragraph reads:
>> All of the contents of this Information Element are sent in the
>> clear.  The containing Enhanced Beacon is not encrypted.
> 
>> What I'm missing is "...and this is fine because the 6tisch-Join-Info 
>> structure
>> contains no sensitive information."
> 
> point taken.  How do you feel about this:
> 
> # Security Considerations
> 
> All of the contents of this Information Element are sent in the clear.
> The containing Enhanced Beacon is not encrypted.
> This is a restriction in the cryptographic architecture of the TSCH
> mechanism.
> In order to decrypt or do integrity checking of layer-2 frames in TSCH, the
> TSCH Absolute Slot Number (ASN) is needed.
> The Enhanced Beacon provides the ASN to new (and long-sleeping) nodes.
> 
> The Enhanced Beagon is authenticated at the layer-2 level using 802.15.4
> mechanisms using the network-wide keying material.  Nodes which are enrolled
> will have the network-wide keying material and can validate the beacon.
> 
> Pledges which have not yet enrolled are unable to authenticate the beacons,
> and will be forced to temporarily take the contents on trust.
> After enrollment, the pledge will be able to return to the beacon and
> validate it.
> 
> In addition to the enrollment and join information described in this
> document, the Enhanced Beacon contains a description of the TSCH schedule to
> be used by the transmitter of this packet.
> The schedule can provide an attacker with a list of channels and frequencies
> on which communication will occur.
> Knowledge of this can help an attacker to more efficiently jam
> communications, although there is future work being considered to make some
> of the schedule less visible.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Has Nits

The draft is short and to the point and easy to understand.  The security
considerations (and privacy considerations!) sections are well written and
cover everything.  I'm just missing one clause.

The first paragraph reads:
   All of the contents of this Information Element are sent in the
   clear.  The containing Enhanced Beacon is not encrypted.

What I'm missing is "...and this is fine because the 6tisch-Join-Info structure
contains no sensitive information."

I'm not disputing this or asking for rigorous proof, but it you say "this is
sent in the clear", you should finish with at least a statement that says that
this is OK.

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [IPsec] [Last-Call] Last Call: (Postquantum Preshared Keys for IKEv2) to Proposed Standard

[Yoav Nir]

Hi, Paul

> On 11 Dec 2019, at 20:03, Paul Hoffman  wrote:
> 
> On 11 Dec 2019, at 8:23, Salz, Rich wrote:
> 
>> We are seeing a flurry of these kind of “post quantum protection” things.
> 
> This is the only one I have seen that is a method, not a new key exchange 
> algorithm. It is understandable that you could have missed this from the 
> title which misstates the topic. A much better title would be "Mixing 
> Preshared Keys in IKEv2 for Postquantum Resistance".

Should we consider this a last call comment?

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[I2nsf] Publication has been requested for draft-ietf-i2nsf-sdn-ipsec-flow-protection-07

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of 
draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 as Proposed Standard on behalf of 
the I2NSF working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[Ace] Secdir telechat review of draft-ietf-ace-cwt-proof-of-possession-11

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Ready

This is the second secdir review of this document. I'm reviewing version -11.
The previous review was of version -08.

All my concerns were addressed, except one:  I still think it's strange that
the Introduction section is an exact repeat of the Abstract.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [IPsec] Adoption call for draft-hopps-ipsecme-iptfs

[Yoav Nir]

I have read the -01 version of this draft.  I believe it addresses a useful use 
case and that the solution presented there is a good starting point.

I support its adoption.

Yoav

> On 26 Oct 2019, at 18:17, Tero Kivinen  wrote:
> 
> So this is fast (one week) adoption call for the
> draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We
> did have quite positive feedback in last IETF meeting and the charter
> item is being worked on in parallel to this call.
> 
> If you support adopting this document as WG document and as a starting
> place for the charter item proposed for the WG, then send email
> indicating your support to the ipsec@ietf.org mailing-list. If you
> have any comments or reservations send them to list too.
> 
> This adoption call finishes at 2019-11-04.
> 
> --
> The demand for Traffic Flow Confidentiality has been increasing in the user
> community; however, the current method defined in RFC4303 (i.e., add null
> padding to each ESP payload) is very inefficient in it's use of network
> resources. The working group will develop an alternative TFC solution that
> provides for efficient use of network resources.
> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-implicit-iv-07: (with DISCUSS and COMMENT)

[Yoav Nir]

Hi, Éric.  Please see inline.

> On 11 Oct 2019, at 10:02, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-implicit-iv-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for the work put into this document. I am trusting the security AD 
> to
> check whether it is safe not to have a 'random' IV.

I’m sure they will, but as an explanation, some algorithms require a random IV. 
Examples are AES in CBC mode. Other algorithms do not require a random IV, but 
do require a unique IV. The documents describing such algorithms recommend 
using either a simple counter or an LFSR to generate the IV. Examples are AES 
in counter mode and ChaCha20.  Our draft specifies IIV only for the latter kind 
of algorithms.

> I have one trivial-to-fix
> DISCUSS and a couple of COMMENTs.
> 
> It is also unclear at first sight whether the 'nonce' built from the sequence
> number is actually the IIV.

Although they use the same fields, the literature tends to call the random kind 
an "Initialization Vector" and the must-not-repeat kind a “Nonce”.  In IPsec 
the field is called IV, so there is some confusion in the terms.

> 
> Regards,
> 
> -éric
> 
> == DISCUSS ==
> 
> -- Section 1 --
> D.1) Please use the RFC 8174 template ;)

Right, our bad.  This is probably because this document has been making the 
rounds for over 3 years. Will fix.

> --
> COMMENT:
> --
> 
> == COMMENTS ==
> -- Section 5 --
> C.1) "inside the SA Payload" probably worth being a little more descriptive
> here (for instance, "SA payload in the IKE exchange" ?).  Also suggest to use
> "IKE Initiator Behavior" for the section title.

OK

> -- Section 8 --
> C.2) please use the usual text for IANA considerations (notably asking IANA to
> register as this is not this document that registers the codes).

Yes, since we received early assignment I think we should go with the “IANA has 
assigned the following values…” text, and leave a reminder that the reference 
should be updated.

> 
> == NITS ==
> 
> In several places, s/8 byte nonce/8-byte nonce/

Will fix.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[Ace] Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

I think the document shows that security aspects have been considered and
handled well. However, the document has issues with clarity and readability:

For starters, the Abstract and Introduction are nearly identical. The
Introduction could instead be used to explain the domain, who the "players" are
and what they are trying to accomplish. Instead, section 2 introduces the terms
Issuer, Presenter and Recipient with definitions that sound like the CA, the
End Entity and the Relying Party from PKI, with a little OAuth terminology
mixed in. There is no explanation about who this issuer is, and what the trust
model is.

The Security Considerations section also has some problems.  Quoting the second
paragraph:
   Applications utilizing proof of possession SHOULD also utilize
   audience restriction, as described in Section 3.1.3 of [CWT], as it
   provides additional protections.  Audience restriction can be used by
   recipients to reject messages intended for different recipients.

Why? Why is the aud claim needed with a cnf claim (but not in other cases)? 
Neither this document nor RFC 8392 provides insight as to when aud is
appropriate. That they allow recipients to reject messages not intended for
them does not sound like a security feature.

Paragraph 3 says: "A recipient might not understand the "cnf" claim."   This
re-affirms that we need an explanation of who the parties to this protocol are.
We generally don't send messages to recipients that don't understand them. Is
this a closed system with known entities, or is this a protocol where the
parties contact random other parties on the Internet?

I'd also lose some of the Introduction to Crypto in the second-to-last
paragraph.

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[regext] Secdir telechat review of draft-ietf-regext-epp-fees-18

[Yoav Nir via Datatracker]

Reviewer: Yoav Nir
Review result: Has Nits

The changes in revision -17 are fine.

I would still like to have it stated that financial information is not at risk
of leaking because the account information of a customer is only sent in
communications with that customer. The Security Considerations section already
says that encryption is used when transmitting financial information. That is
necessary but not sufficient. You also need to state that such information is
only sent to entities that should have access to that information.

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

Re: [regext] Secdir last call review of draft-ietf-regext-epp-fees-16

[Yoav Nir]

Hi, Roger

Looks good.  What I think should also be said, is that the financial 
information passed to any customer is only information about that customer’s 
own account.  We wouldn’t want customer information to leak to other customers.

Yoav

> On 6 Sep 2019, at 17:48, Roger D Carney  wrote:
> 
> Good Morning,
>  
> Thank you for your comments Yoav, please see my responses below. A new 
> version of the draft will be published shortly and will address all of the 
> review comments that needed edits.
>  
>  
> Thanks
> Roger
>  
> -----Original Message-
> From: Yoav Nir via Datatracker mailto:nore...@ietf.org>> 
> Sent: Saturday, June 29, 2019 10:26 AM
> To: sec...@ietf.org <mailto:sec...@ietf.org>
> Cc: i...@ietf.org <mailto:i...@ietf.org>; 
> draft-ietf-regext-epp-fees@ietf.org 
> <mailto:draft-ietf-regext-epp-fees@ietf.org>; regext@ietf.org 
> <mailto:regext@ietf.org>
> Subject: Secdir last call review of draft-ietf-regext-epp-fees-16
>  
> Notice: This email is from an external sender.
>  
>  
>  
> Reviewer: Yoav Nir
> Review result: Has Nits
>  
> Hi
>  
> I have reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.  These 
> comments were written primarily for the benefit of the security area 
> directors.
> Document editors and WG chairs should treat these comments just like any 
> other last call comments.
>  
> The entire text of the Security Considerations section is as follows:
>  
>The mapping extensions described in this document do not provide any
>security services beyond those described by EPP [RFC5730], the EPP
>domain name mapping [RFC5731], and protocol layers used by EPP.  The
>security considerations described in these other specifications apply
>to this specification as well.
>  
> This is what we like to call "security considerations by reference". I don't 
> know what "security services" are in this context, but they are not the only 
> thing that needs to be described in a Security Considerations section.
>  
> In this case, the draft adds information about fees, customer credit and pay 
> schedule. This falls under the category of financial information, which 
> should be protected in transit by security mechanisms that protect 
> confidentiality and integrity. It is also true that any transport mechanism 
> that complies with RFC
> 5730 provides those functions. So what I'm missing here is a sentence that 
> calls this out specifically. Something along the lines of "This extension 
> adds financial information to the EPP protocol, so confidentiality and 
> integrity protection must be provided by the transport mechanism.  All 
> transports compliant with RFC5730 provide that"
>  
> [RDC] We have added the following text to section 7: "This extension passes 
> financial information using the EPP protocol, so confidentiality and 
> integrity protection must be provided by the transport mechanism.  All 
> transports compliant with RFC5730 provide the needed level of confidentiality 
> and integrity protections."

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

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

[I2nsf] Publication has been requested for draft-ietf-i2nsf-capability-05

[Yoav Nir via Datatracker]

Yoav Nir has requested publication of draft-ietf-i2nsf-capability-05 as 
Proposed Standard on behalf of the I2NSF working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability/

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[I2nsf] Fwd: New Version Notification for draft-nir-i2nsf-ipsec-dc-prof-00.txt

[Yoav Nir]

Hi.

The below is a private submission by myself of a profile for using the protocol 
in sdn-ipsec-flow to protect internal traffic within the data center.

A few notes:
This is *not* a working group draft
I am not at this point asking for adoption, and I won’t at least until the 
sdn-ipsec-flow document is past IESG processing.
The intended status is Informational, as is common for profiles
Comments are welcome.

Yoav
(firmly with no hats)

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-nir-i2nsf-ipsec-dc-prof-00.txt
> Date: 23 July 2019 at 23:25:52 GMT-4
> To: "Yoav Nir" 
> 
> 
> A new version of I-D, draft-nir-i2nsf-ipsec-dc-prof-00.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name: draft-nir-i2nsf-ipsec-dc-prof
> Revision: 00
> Title:A Data Center Profile for Software Defined Networking 
> (SDN)-based IPsec
> Document date:2019-07-22
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/internet-drafts/draft-nir-i2nsf-ipsec-dc-prof-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-nir-i2nsf-ipsec-dc-prof/
> Htmlized:   https://tools.ietf.org/html/draft-nir-i2nsf-ipsec-dc-prof-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-nir-i2nsf-ipsec-dc-prof
> 
> 
> Abstract:
>   This document presents two profiles for configuring IPsec within a
>   data center using an SDN controller and the YANG model described in
>   the sdn-ipsec draft.
> 
>   Two profiles are described to allow both the IKE and IKE-less cases
>   because some data centers may be required to use a standardized
>   method of key exchange rather than SDN.
> 
> 
> 
> 
> 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
> 

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[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

[IPsec] Heads up: IDR meeting on Wednesday

[Yoav Nir]

Hi

This may be of interest to IPsec folks.  The IDR working group is meeting 
tomorrow and has several IPsec-related items on its agenda:
Secure EVPN - where BGP is used instead of IKEv2 to key IPsec and distribute 
policy.
BGP Signaled IPsec Tunnel Configuration - where IKEv2 is configured by BGP to 
set up IPsec SAs.
Subsequent Address Family Indicator for SDWAN Ports - which is something about 
SD-WAN (with IPsec)

So if you’re not doing anything interesting at 13:30, you might want to go 
there.

The agenda:  
https://datatracker.ietf.org/meeting/105/materials/agenda-105-idr-02 


Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt

[Yoav Nir]

Hi, Valery

Obviously, you need a security controller that scales to the number of SAs it 
needs to generate. But generating an SA in the IKE-less case is just generating 
72 random bytes (for AES-GCM-256) and packaging them.  I don’t think with a 
properly scaled SC this would produce more latency than IKE between the nodes, 
which has 1/2 round-trips and requires asymmetric operations.


> On 22 Jul 2019, at 11:39, Valery Smyslov  wrote:
> 
> Hi Rafa,
>  
> sure this problem is general for any SDN solution.
> My point was that if SC performs a lot of real-time 
> (or near real-time) tasks as it may happen in IKE-less case, 
> then this problem may become serious.
>  
> Anyway, I'm happy with the updated text, thank you.
> However, in a following document(s), suggested by Yoav,
> I'd like to see more concrete advices of how SC should
> act in this situation to ensure that the consistence of the 
> network is preserved despite all the possible delays etc.
>  
> Regards,
> Valery.
>  
>  
> From: Rafa Marin Lopez  
> Sent: Monday, July 22, 2019 6:11 PM
> To: Valery Smyslov 
> Cc: Rafa Marin Lopez ; Yoav Nir ; 
> i2...@ietf.org; ipsec@ietf.org; Fernando Pereñíguez García 
> ; m...@tail-f.com; Gabriel Lopez 
> 
> Subject: Re: [I2nsf] I-D Action: 
> draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>  
> Hi Valery:
>  
> Thank you very much for your comments. Please see ours inside.
>> El 20 jul 2019, a las 16:38, Valery Smyslov > <mailto:smyslov.i...@gmail.com>> escribió:
>>  
>> Hi,
>>  
>> thank you for updating the document. I still think that some aspect
>> of IKE-less use case are not discussed yet (well, probably they are not 
>> "serious", depending on one's definition of "serious").
>>  
>> Unlike IKE case. which we can consider as mostly static configuration,
>> the IKE-less case is a dynamic one. If IPsec SA are being created 
>> on demand (via kernel-acquire) and the traffic volume is high,
>> then depending on the IPsec policy IKE-less case can become 
>> a highly dynamic, which implies additional requirement on both
>> the network connecting SC and NSF and the performance of the protocol used 
>> to 
>> secure their communications. In other words, in IKE case the communication
>> between IKE daemon and kernel is seamless, while in IKE-less
>> case the communication between NSF ("kernel") and SC adds
>> noticeable delay (and can potentially add quite a long delay),
>> which can influence total performance of the system.
>>  
>> Generally IKE-less case requires more communications between
>> different nodes to establish or rekey IPsec SA, than IKE case
>> (I assume that IKE SA is already established), that may have
>> an impact on high-speed networks with short-lived IPsec SAs,
>> especially if they are created per transport connection
>> (say one IPsec SA for one TCP session).
>  
> [Authors] What you have just described is what happens in any SDN-based 
> network. In fact, your comment would be applicable to practically any 
> scenario based on the SDN paradigm. In the particular case of the I-D, the 
> IKE-less case is the most similar to case you can see in, for example, 
> Openflow networks where latency is also important (just as an example : 
> https://ieeexplore.ieee.org/document/6573052 
> <https://ieeexplore.ieee.org/document/6573052> )
> 
> 
>>  
>> I believe, that SC's task of managing IPsec SAs in IKE-less case 
>> may become quite complex, especially because due to the
>> additional delay, introduced by the network, the picture of the
>> state of the SAs the SC has can become inaccurate (well, 
>> it will always be inaccurate, but with short delays it doesn't matter).
>> Just an example. Consider an SC receives a signal from NSF that an SA
>> is soft expired and starts rekeying process by first installing a new
>> pair of inbound SAs. It successfully installs them on the NSF
>> it receives notification from, but then it receives a notification
>> that the other NSF has rebooted, so it must clear all the SAs on
>> its peers, including the just installed new one (which is only
>> half-done). There seems to be a lot of nuances, and the document 
>> completely ignores them. Not that I think that the task
>> is impossible, but the algorithm of managing the SAs can become
>> quite complex and possibly unreliable.
>  
> [Authors] We largely thought about this kind of cases, although we do not see 
> any different that may happen in SDN-based network nowadays. And it seems to 
> me that SDN is becoming something generally accepted despite the di