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

Re: [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 ; 
> i2nsf@ietf.org; ip...@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 ac

Re: [Acme] Slides for tomorrow.

[Yoav Nir]

It’s now past 11:00 PM and we still don’t have slides for telephony, TLS-ALPN, 
and STAR delegation.

What’s up with that?

Rich & Yoav

> On 21 Jul 2019, at 12:19, Yoav Nir  wrote:
> 
> Hi, presenters.
> 
> The meeting is tomorrow morning: 
> https://datatracker.ietf.org/meeting/105/materials/agenda-105-acme 
> <https://datatracker.ietf.org/meeting/105/materials/agenda-105-acme>
> 
> Please send your slides by EOD today, and also tell me who will be 
> presenting. We want to have the slides up in plenty of time and the agenda 
> correct.
> 
> Thanks
> 
> Rich & Yoav
> 

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

[Acme] Slides for tomorrow.

[Yoav Nir]

Hi, presenters.

The meeting is tomorrow morning: 
https://datatracker.ietf.org/meeting/105/materials/agenda-105-acme 


Please send your slides by EOD today, and also tell me who will be presenting. 
We want to have the slides up in plenty of time and the agenda correct.

Thanks

Rich & Yoav

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

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

[Yoav Nir]

Hi, Valery

[no hats]

Thanks for that.

I think this demonstrates that the current document is not enough and we will 
need some follow-up documents explaining when to use either case.

I don’t think it’s very useful for the controller to distribute a policy (SPD 
entries) but no SAs (SAD entries) in the IKE-less case.  It makes sense in the 
IKE case because the NSFs can then use IKE to generate the SAs, but in the 
IKE-less case that would mean that one NSF gets a packet that should be 
protected, sends a message to the controller, which generates an SA and sends 
it to both the requester and the other NSF.  This seems high latency.

I think the case for IKE-less is where the controller sends SPD entries and SAD 
entries at the same time (perhaps later updating the SAD entries to rekey). In 
that case the action of the controller is to bring up a tunnel.  For example, 
if the user (or application) decides that communications between node A and 
node B should be encrypted, the controller will send both policy and keys at 
the same time to make that tunnel.

Yoav

> On 20 Jul 2019, at 10:38, Valery Smyslov  wrote:
> 
> 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).
>  
> 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.
>  
> I didn't find this discussion in the draft (sorry if I missed it).
>  
> Regards,
> Valery.
>  
>  
>  
>  
> Thanks for getting this done and published.
>  
> We will wait with requesting publication until the I2NSF session next week.  
> Between now and then, please re-read the draft and send a message to the list 
> is something is seriously wrong.
>  
> Barring any such shouting, we will request publication right after the 
> meeting.
>  
> Thanks again,
>  
> Linda and Yoav
> 
> 
>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez mailto:r...@um.es>> 
>> wrote:
>>  
>> Dear all:
>> 
>> We submitted a new version of the I-D (v05) where we have applied several 
>> changes. In the following you have a summary of the main changes, which we 
>> will expand/explain during our presentation: 
>> 
>> - We have dealt with YANG doctors’ review (Martin's)
>> 
>> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>>  
>> - We have added more specific text in the descriptions.
>> 
>> - Notifications have a simpler format now since most of the information that 
>> contained in the past is already handled by the Security Controller.
>> 
>> - State data has been reduced. For example, in IKE case, most of the 
>> information is related with IKE and not with the specific details about 
>> IPsec SAs that IKE handles (after all, IKE can abstract this information 
>> from the Security Controller).
>>  
>> - We have included text in the security section to discuss about the default 
>> IPsec policies that should be in the NSF when it starts before contacting 

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

[Yoav Nir]

Hi, Valery

[no hats]

Thanks for that.

I think this demonstrates that the current document is not enough and we will 
need some follow-up documents explaining when to use either case.

I don’t think it’s very useful for the controller to distribute a policy (SPD 
entries) but no SAs (SAD entries) in the IKE-less case.  It makes sense in the 
IKE case because the NSFs can then use IKE to generate the SAs, but in the 
IKE-less case that would mean that one NSF gets a packet that should be 
protected, sends a message to the controller, which generates an SA and sends 
it to both the requester and the other NSF.  This seems high latency.

I think the case for IKE-less is where the controller sends SPD entries and SAD 
entries at the same time (perhaps later updating the SAD entries to rekey). In 
that case the action of the controller is to bring up a tunnel.  For example, 
if the user (or application) decides that communications between node A and 
node B should be encrypted, the controller will send both policy and keys at 
the same time to make that tunnel.

Yoav

> On 20 Jul 2019, at 10:38, Valery Smyslov  wrote:
> 
> 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).
>  
> 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.
>  
> I didn't find this discussion in the draft (sorry if I missed it).
>  
> Regards,
> Valery.
>  
>  
>  
>  
> Thanks for getting this done and published.
>  
> We will wait with requesting publication until the I2NSF session next week.  
> Between now and then, please re-read the draft and send a message to the list 
> is something is seriously wrong.
>  
> Barring any such shouting, we will request publication right after the 
> meeting.
>  
> Thanks again,
>  
> Linda and Yoav
> 
> 
>> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez mailto:r...@um.es>> 
>> wrote:
>>  
>> Dear all:
>> 
>> We submitted a new version of the I-D (v05) where we have applied several 
>> changes. In the following you have a summary of the main changes, which we 
>> will expand/explain during our presentation: 
>> 
>> - We have dealt with YANG doctors’ review (Martin's)
>> 
>> - We have dealt with Paul Wouters’ comments and Tero’s comments.
>>  
>> - We have added more specific text in the descriptions.
>> 
>> - Notifications have a simpler format now since most of the information that 
>> contained in the past is already handled by the Security Controller.
>> 
>> - State data has been reduced. For example, in IKE case, most of the 
>> information is related with IKE and not with the specific details about 
>> IPsec SAs that IKE handles (after all, IKE can abstract this information 
>> from the Security Controller).
>>  
>> - We have included text in the security section to discuss about the default 
>> IPsec policies that should be in the NSF when it starts before contacting 

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

[Yoav Nir]

Thanks for getting this done and published.

We will wait with requesting publication until the I2NSF session next week.  
Between now and then, please re-read the draft and send a message to the list 
is something is seriously wrong.

Barring any such shouting, we will request publication right after the meeting.

Thanks again,

Linda and Yoav

> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez  wrote:
> 
> Dear all:
> 
> We submitted a new version of the I-D (v05) where we have applied several 
> changes. In the following you have a summary of the main changes, which we 
> will expand/explain during our presentation: 
> 
> - We have dealt with YANG doctors’ review (Martin's)
> 
> - We have dealt with Paul Wouters’ comments and Tero’s comments.
> 
> - We have added more specific text in the descriptions.
> 
> - Notifications have a simpler format now since most of the information that 
> contained in the past is already handled by the Security Controller.
> 
> - State data has been reduced. For example, in IKE case, most of the 
> information is related with IKE and not with the specific details about IPsec 
> SAs that IKE handles (after all, IKE can abstract this information from the 
> Security Controller).
> 
> - We have included text in the security section to discuss about the default 
> IPsec policies that should be in the NSF when it starts before contacting 
> with the SC such as the IPsec policies required to allow traffic between the 
> SC and the NSF.
> 
> - We have added a subsection 5.3.4 about NSF discovery by the Security 
> Controller.
> 
> - In order to specify the crypto-algorithms we have used a simple approach by 
> including an integer and adding a text pointing the IANA in the reference 
> clause. For example:
> 
> typedef encryption-algorithm-type {
>type uint32;
>description 
>"The encryption algorithm is specified with a 32-bit
>number extracted from IANA Registry. The acceptable
>values MUST follow the requirement levels for
>encryption algorithms for ESP and IKEv2.";
>reference 
> "IANA Registry- Transform Type 1 - Encryption
> Algorithm Transform IDs. RFC 8221 - Cryptographic
> Algorithm Implementation Requirements and Usage
> Guidance for Encapsulating Security Payload (ESP)
> and Authentication Header (AH) and RFC 8247 -
> Algorithm Implementation Requirements and Usage
> Guidance for the Internet Key Exchange Protocol
> Version 2 (IKEv2).";
>}
> 
> - We have included three additional Annexes with examples in about the usage 
> of the YANG model.
> 
> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f 
> yang --yang-line-length 69 in our model without warnings.
> 
> Best Regards.
> 
>> Inicio del mensaje reenviado:
>> 
>> De: internet-dra...@ietf.org 
>> Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>> Fecha: 7 de julio de 2019, 23:34:03 CEST
>> Para: mailto:i-d-annou...@ietf.org>>
>> Cc: i2nsf@ietf.org 
>> Responder a: i2nsf@ietf.org 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Interface to Network Security Functions WG 
>> of the IETF.
>> 
>>Title   : Software-Defined Networking (SDN)-based IPsec Flow 
>> Protection
>>Authors : Rafa Marin-Lopez
>>  Gabriel Lopez-Millan
>>  Fernando Pereniguez-Garcia
>>  Filename: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>>  Pages   : 81
>>  Date: 2019-07-07
>> 
>> Abstract:
>>   This document describes how providing IPsec-based flow protection by
>>   means of a Software-Defined Network (SDN) controller (aka.  Security
>>   Controller) and establishes the requirements to support this service.
>>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>>   gateway and (ii) host-to-host.  The SDN-based service described in
>>   this document allows the distribution and monitoring of IPsec
>>   information from a Security Controller to one or several flow-based
>>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>>   data traffic between network resources.
>> 
>>   The document focuses on the NSF Facing Interface by providing models
>>   for configuration and state data required to allow the Security
>>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>>   to establish Security Associations with a reduced intervention of the
>>   network administrator.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ 
>> 

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

[Yoav Nir]

Thanks for getting this done and published.

We will wait with requesting publication until the I2NSF session next week.  
Between now and then, please re-read the draft and send a message to the list 
is something is seriously wrong.

Barring any such shouting, we will request publication right after the meeting.

Thanks again,

Linda and Yoav

> On 16 Jul 2019, at 15:42, Rafa Marin-Lopez  wrote:
> 
> Dear all:
> 
> We submitted a new version of the I-D (v05) where we have applied several 
> changes. In the following you have a summary of the main changes, which we 
> will expand/explain during our presentation: 
> 
> - We have dealt with YANG doctors’ review (Martin's)
> 
> - We have dealt with Paul Wouters’ comments and Tero’s comments.
> 
> - We have added more specific text in the descriptions.
> 
> - Notifications have a simpler format now since most of the information that 
> contained in the past is already handled by the Security Controller.
> 
> - State data has been reduced. For example, in IKE case, most of the 
> information is related with IKE and not with the specific details about IPsec 
> SAs that IKE handles (after all, IKE can abstract this information from the 
> Security Controller).
> 
> - We have included text in the security section to discuss about the default 
> IPsec policies that should be in the NSF when it starts before contacting 
> with the SC such as the IPsec policies required to allow traffic between the 
> SC and the NSF.
> 
> - We have added a subsection 5.3.4 about NSF discovery by the Security 
> Controller.
> 
> - In order to specify the crypto-algorithms we have used a simple approach by 
> including an integer and adding a text pointing the IANA in the reference 
> clause. For example:
> 
> typedef encryption-algorithm-type {
>type uint32;
>description 
>"The encryption algorithm is specified with a 32-bit
>number extracted from IANA Registry. The acceptable
>values MUST follow the requirement levels for
>encryption algorithms for ESP and IKEv2.";
>reference 
> "IANA Registry- Transform Type 1 - Encryption
> Algorithm Transform IDs. RFC 8221 - Cryptographic
> Algorithm Implementation Requirements and Usage
> Guidance for Encapsulating Security Payload (ESP)
> and Authentication Header (AH) and RFC 8247 -
> Algorithm Implementation Requirements and Usage
> Guidance for the Internet Key Exchange Protocol
> Version 2 (IKEv2).";
>}
> 
> - We have included three additional Annexes with examples in about the usage 
> of the YANG model.
> 
> - We have performed pyang --lint --lint-ensure-hyphenated-names and pyang -f 
> yang --yang-line-length 69 in our model without warnings.
> 
> Best Regards.
> 
>> Inicio del mensaje reenviado:
>> 
>> De: internet-dra...@ietf.org 
>> Asunto: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>> Fecha: 7 de julio de 2019, 23:34:03 CEST
>> Para: mailto:i-d-annou...@ietf.org>>
>> Cc: i2...@ietf.org 
>> Responder a: i2...@ietf.org 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Interface to Network Security Functions WG 
>> of the IETF.
>> 
>>Title   : Software-Defined Networking (SDN)-based IPsec Flow 
>> Protection
>>Authors : Rafa Marin-Lopez
>>  Gabriel Lopez-Millan
>>  Fernando Pereniguez-Garcia
>>  Filename: draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt
>>  Pages   : 81
>>  Date: 2019-07-07
>> 
>> Abstract:
>>   This document describes how providing IPsec-based flow protection by
>>   means of a Software-Defined Network (SDN) controller (aka.  Security
>>   Controller) and establishes the requirements to support this service.
>>   It considers two main well-known scenarios in IPsec: (i) gateway-to-
>>   gateway and (ii) host-to-host.  The SDN-based service described in
>>   this document allows the distribution and monitoring of IPsec
>>   information from a Security Controller to one or several flow-based
>>   Network Security Function (NSF).  The NSFs implement IPsec to protect
>>   data traffic between network resources.
>> 
>>   The document focuses on the NSF Facing Interface by providing models
>>   for configuration and state data required to allow the Security
>>   Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2
>>   to establish Security Associations with a reduced intervention of the
>>   network administrator.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ 
>> 

Re: [Acme] Agenda for IETF 105

[Yoav Nir]

Sure. I’m sorry. I made the list based on datatracker, which doesn’t show 
related drafts for the WG the way the tools page does.

> On 12 Jul 2019, at 2:17, Kathleen Moriarty  
> wrote:
> 
> 
> 
> Sent from my mobile device
> 
> On Jul 11, 2019, at 4:56 PM, Owen Friel (ofriel)  <mailto:ofr...@cisco.com>> wrote:
> 
>> Hi all,
>> Could I have 10 mins to cover:
>> https://tools.ietf.org/html/draft-friel-acme-integrations-01 
>> <https://tools.ietf.org/html/draft-friel-acme-integrations-01>
>>  
>> There is some overlap with 
>> https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01 
>> <https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01>
>>  and https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ 
>> <https://datatracker.ietf.org/doc/draft-moriarty-acme-client/> and we are 
>> having offline discussion with Kathleen and Rifaat on how to align all 3.
> 
> I’d like to present the updated client draft listed above as well.
> 
> There’s an overview draft the may fold in with Owen’s, but we need to figure 
> that out according to interest.
> 
> https://tools.ietf.org/html/draft-moriarty-acme-overview-00 
> <https://tools.ietf.org/html/draft-moriarty-acme-overview-00>
> 
> Best regards,
> Kathleen 
> 
>>  
>> Thanks,
>> Owen
>>  
>> From: Acme mailto:acme-boun...@ietf.org>> On Behalf 
>> Of Yoav Nir
>> Sent: 11 July 2019 20:50
>> To: IETF ACME mailto:acme@ietf.org>>
>> Subject: [Acme] Agenda for IETF 105
>>  
>> Hi, all
>>  
>> We are putting together the agenda for IETF 105.
>>  
>> The current plan is to have presentation and agenda time for email and for 
>> telephony.
>>  
>> There is still time on the agenda to cover more topics, so if you think they 
>> should be brought up, please reply either to this thread, or directly to 
>> Rich and me:
>> · draft-ietf-acme-tls-alpn seems to be stalled for months. We’ve had 
>> a change of AD and a new AD review ([1]). Can allocating meeting time help 
>> with progressing this?
>> · draft-ietf-acme-star is in IETF LC with no significant issues 
>> having come up.  Unless the authors think otherwise, I don’t see a need to 
>> allocate agenda time at this point.
>> · draft-ietf-acme-ip is waiting for an AD write-up and to progress 
>> it. Unless Roland feels differently, I don’t think there’s much to spend 
>> agenda time on.
>> · draft-ietf-acme-caa is in the RFC editor’s queue.  So, all good?
>>  
>> If you have some other business for the WG meeting, please bring it up now.
>>  
>> Thanks
>>  
>> Rich & Yoav
>>  
>>  
>> [1] https://mailarchive.ietf.org/arch/msg/acme/YW9rho7i1YjLd32k-MDYX4p2dSU 
>> <https://mailarchive.ietf.org/arch/msg/acme/YW9rho7i1YjLd32k-MDYX4p2dSU>___
>> Acme mailing list
>> Acme@ietf.org <mailto:Acme@ietf.org>
>> https://www.ietf.org/mailman/listinfo/acme 
>> <https://www.ietf.org/mailman/listinfo/acme>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Agenda for IETF 105

[Yoav Nir]

Hi, all

We are putting together the agenda for IETF 105.

The current plan is to have presentation and agenda time for email and for 
telephony.

There is still time on the agenda to cover more topics, so if you think they 
should be brought up, please reply either to this thread, or directly to Rich 
and me:
draft-ietf-acme-tls-alpn seems to be stalled for months. We’ve had a change of 
AD and a new AD review ([1]). Can allocating meeting time help with progressing 
this?
draft-ietf-acme-star is in IETF LC with no significant issues having come up.  
Unless the authors think otherwise, I don’t see a need to allocate agenda time 
at this point.
draft-ietf-acme-ip is waiting for an AD write-up and to progress it. Unless 
Roland feels differently, I don’t think there’s much to spend agenda time on.
draft-ietf-acme-caa is in the RFC editor’s queue.  So, all good?

If you have some other business for the WG meeting, please bring it up now.

Thanks

Rich & Yoav


[1] https://mailarchive.ietf.org/arch/msg/acme/YW9rho7i1YjLd32k-MDYX4p2dSU___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [bess] Can we have the IPSEC related drafts discussion before Friday during IETF 105?

[Yoav Nir]

Me too.  If it doesn’t collide with ACME, I2NSF, LAKE, IPSECME, or TLS I’m 
around.

> On 1 Jul 2019, at 21:14, Paul Wouters  wrote:
> 
> On Mon, 1 Jul 2019, Linda Dunbar wrote:
> 
>> Hope we can have a face to face meeting discussing IPSEC related drafts in 
>> IETF105.
>> I have hard conflict for Friday July 26.
>> Can we have the discussion anytime before Friday during IETF105?
> 
> I'm around all week, so happy to meet up on one of the other days.
> 
> Paul

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

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

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

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"

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

Re: [I2nsf] IPR Statements about I2NSF documents

[Yoav Nir]

Hi folks. 

As you may have noticed, after some back-and-forth with the authors and their 
university, the IPR statements have been modified as follows:

OLD:
Reasonable and Non-Discriminatory License to All Implementers with Possible 
Royalty/Fee

NEW:
If this standard is adopted, Sungkyunkwan University (SKKU) will not assert any 
patents owned or controlled by SKKU against any party for making, using, 
selling, importing or offering for sale a product that implements the standard, 
provided, however that SKKU retains the right to assert its patents (including 
the right to claim past royalties) against any party that asserts a patent it 
owns or controls (either directly or indirectly) against SKKU or any of SKKU's 
affiliates or successors in title or against any products of SKKU or any 
products of any of SKKU's affiliates either alone or in combination with other 
products; and SKKU retains the right to assert its patents against any product 
or portion thereof that is not necessary for compliance with the standard. 
Royalty-bearing licenses will be available to anyone who prefers that option.


The new version is similar to the licensing terms in many IPR statements issued 
by other rights holders.  See for example 
https://datatracker.ietf.org/ipr/3591/ <https://datatracker.ietf.org/ipr/3591/>

It is still up to the working group to decide if this is acceptable, and group 
members, especially those who raised objections previously, are encouraged to 
chime in.

We will raise this issue one more time at the meeting, just to make sure 
everyone has been heard from.

Thanks,

Linda & Yoav


> On 6 Jun 2019, at 20:27, Yoav Nir  wrote:
> 
> Hi
> 
> Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the 
> following drafts respectively:
> draft-ietf-i2nsf-nsf-facing-interface-dm 
> draft-ietf-i2nsf-nsf-monitoring-data-model
> draft-ietf-i2nsf-capability-data-model
> draft-ietf-i2nsf-registration-interface-dm
> draft-ietf-i2nsf-consumer-facing-interface-dm
> 
> All of these are WG documents, and one of them (the capability data model 
> draft) is in WGLC.  See [6] and RFC 8179 for more information about IPR 
> disclosures.
> 
> All the disclosures claim that the patents or patent applications mentioned 
> may be necessary for implementation of the drafts. Neither the chairs nor 
> anyone else in the IETF is considered competent to evaluate such claims or 
> the validity of any patents, so I suggest that in this thread we avoid 
> bringing this up. What may be concerning is that the licensing policy for 
> these disclosures is "Reasonable and Non-Discriminatory License to All 
> Implementers with Possible Royalty/Fee”, which makes such technologies 
> problematic to many implementers, especially non-commercial ones.
> 
> To quote from section 7 of RFC 8179:
>In general, IETF working groups prefer technologies with no known IPR
>claims or, for technologies with claims against them, an offer of
>royalty-free licensing.  However, to solve a given technical problem,
>IETF working groups have the discretion to adopt a technology as to
>which IPR claims have been made if they feel that this technology is
>superior enough to alternatives with fewer IPR claims or free
>licensing to outweigh the potential cost of the licenses.
> 
> 
> So this message is to start a discussion about how the I2NSF working group 
> would like to handle this disclosure. Continuing as before and moving to 
> publication is the default outcome of this discussion, but the WG is required 
> to evaluate its position about these disclosures. This is what this thread is 
> for.
> 
> Thanks,
> 
> 
> Linda & Yoav
> 
> [1] https://datatracker.ietf.org/ipr/3553/ 
> <https://datatracker.ietf.org/ipr/3553/>
> [2] https://datatracker.ietf.org/ipr/3557/ 
> <https://datatracker.ietf.org/ipr/3557/>
> [3] https://datatracker.ietf.org/ipr/3556/ 
> <https://datatracker.ietf.org/ipr/3556/>
> [4] https://datatracker.ietf.org/ipr/3555/ 
> <https://datatracker.ietf.org/ipr/3555/>
> [5] https://datatracker.ietf.org/ipr/3554/ 
> <https://datatracker.ietf.org/ipr/3554/>
> [6] https://www.ietf.org/standards/ipr/ <https://www.ietf.org/standards/ipr/>
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Yoav Nir]

In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was the 
go-to error code for everything the Responder didn’t like; wrong algorithms, 
wrong transforms (like transport instead of tunnel), unknown peer, 

INVALID_SYNTAX meant something like malformed packet.

> On 20 Jun 2019, at 16:52, Paul Wouters  wrote:
> 
> 
> Hi,
> 
> We are having a discussion about which notify to return in certain
> cases. The issue comes down to the names of the notifies and their
> actual dictated use in the RFC that does not always intuitively
> maps to the name.
> 
> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
> proposal list matches due to all proposals having at least one mismatching
> transform" versus "no matching ike connection for your IKE proposal"
> where proposal refers to the entire IKE proposal, not the proposals
> list with transforms.
> 
> INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text
> uses this as the "if all other errors dont match, use this one" so you
> can end up returning this even if there is no invalid syntax at all.
> 
> So if your IPsec gateway only has static IP based VPNs and an unknown IP
> connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically,
> even though there is no invalid syntax in that proposal, the RFC states
> we should return INVALID_SYNTAX.
> 
> Similarly, if during IKE_AUTH you are finding out there is no IPsec
> configuration that matches the incoming client, there is no "proposal
> list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural
> match, should we really return INVALID_SYNTAX despite there being no
> syntax problem? That is what the RFC says.
> 
> I guess in the end, we are really missing a "CONNECTION_REJECTED"
> notify that would cover all the things not covered in the more specific
> notifies.
> 
> What do other implementations do? Should we clarify this anywhere?
> 
> libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now
> slated to be more strict to the RFC and use INVALID_SYNTAX. (and
> clearly, I'm not happy about it but it seems the RFC dictates this)
> 
> Paul
> 
> ___
> 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

[I2nsf] IPR Statements about I2NSF documents

[Yoav Nir]

Hi

Yesterday we got 5 IPR statements ([1], [2], [3], [4], [5]) related to the 
following drafts respectively:
draft-ietf-i2nsf-nsf-facing-interface-dm 
draft-ietf-i2nsf-nsf-monitoring-data-model
draft-ietf-i2nsf-capability-data-model
draft-ietf-i2nsf-registration-interface-dm
draft-ietf-i2nsf-consumer-facing-interface-dm

All of these are WG documents, and one of them (the capability data model 
draft) is in WGLC.  See [6] and RFC 8179 for more information about IPR 
disclosures.

All the disclosures claim that the patents or patent applications mentioned may 
be necessary for implementation of the drafts. Neither the chairs nor anyone 
else in the IETF is considered competent to evaluate such claims or the 
validity of any patents, so I suggest that in this thread we avoid bringing 
this up. What may be concerning is that the licensing policy for these 
disclosures is "Reasonable and Non-Discriminatory License to All Implementers 
with Possible Royalty/Fee”, which makes such technologies problematic to many 
implementers, especially non-commercial ones.

To quote from section 7 of RFC 8179:
   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  However, to solve a given technical problem,
   IETF working groups have the discretion to adopt a technology as to
   which IPR claims have been made if they feel that this technology is
   superior enough to alternatives with fewer IPR claims or free
   licensing to outweigh the potential cost of the licenses.


So this message is to start a discussion about how the I2NSF working group 
would like to handle this disclosure. Continuing as before and moving to 
publication is the default outcome of this discussion, but the WG is required 
to evaluate its position about these disclosures. This is what this thread is 
for.

Thanks,


Linda & Yoav

[1] https://datatracker.ietf.org/ipr/3553/
[2] https://datatracker.ietf.org/ipr/3557/
[3] https://datatracker.ietf.org/ipr/3556/
[4] https://datatracker.ietf.org/ipr/3555/
[5] https://datatracker.ietf.org/ipr/3554/
[6] https://www.ietf.org/standards/ipr/___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-capability-data-model

[Yoav Nir]

There’s a bunch of disclosures with those terms. 

We’ll start a thread about this later today.

> On 6 Jun 2019, at 6:53, Paul Wouters  wrote:
> 
> 
> On Jun 5, 2019, at 23:05, Mr. Jaehoon Paul Jeong  > wrote:
> 
>> Hi Linda and Yoav,
>> As a coauthor, I am aware of an IPR about this draft as below:
>> https://datatracker.ietf.org/ipr/3556/ 
>>  
> 
> This is very unfortunate:
> 
> “Reasonable and Non-Discriminatory License to All Implementers with Possible 
> Royalty/Fee”
> 
> The word “possible” is a real problem here. How will the WG address this 
> issue? Or will this prevent the document from moving forward ?
> 
> Paul

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

Re: [I2nsf] [yang-doctors] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC

[Yoav Nir]

Good.  But since we are getting a YANG doctor review, let’s wait for that 
before revving the draft.

Yoav


> On 9 Apr 2019, at 10:49, Rafa Marin-Lopez  wrote:
> 
> Hi Yoav:
> 
> After thinking about these past days, I personally think the same. 
> 
> I would add a uint16 and a comment in the description. As we agreed in the 
> last IETF meeting, I do not think our I-D should solve this problem, since 
> this problem happens in general.
> 
> As an example:
> 
> typedef ike-integrity-algorithm-t {
>   type uint32; 
>   description “The acceptable numbers are defined in IANA 
> Registry - Internet Key Exchange Version 2 (IKEv2) Parameters - IKEv2  
> Transform Type 1 - Encryption Algorithm Transform IDs";
> }
> 
> Is this reasonable?
> 
> 
>> El 5 abr 2019, a las 20:13, Yoav Nir > <mailto:ynir.i...@gmail.com>> escribió:
>> 
>> At this point I’m wondering if it would not be a better strategy to avoid 
>> all enumerations of algorithms, whether they are spelled out or imported 
>> from draft-ietf-netconf-crypto-types, and instead use the numbers from the 
>> IANA registry for IPsec.
>> 
>> That does not help us deprecate old algorithms, but it solves the other 
>> issue, which is what to do when a new algorithm is added to IPsec. We don’t 
>> want to have to publish a new i2nsf document whenever that happens, and if 
>> the algorithm identifier is just a number, new values can be added by IANA.
>> 
>> Yoav
>> 
>>> On 5 Apr 2019, at 20:42, Andy Bierman >> <mailto:a...@yumaworks.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> I think conformance for identities is handled very poorly in YANG.
>>> There is an if-feature-stmt allowed inside an identity in YANG 1.1.
>>> This implies that any identity without if-feature is mandatory-to-implement.
>>> 
>>> If the identities are in a separate module, the server can list it as an 
>>> imported module,
>>> which tells the client the server does not implement any of the identities.
>>> 
>>> There is no standard way for the server to inform the client which 
>>> identities it supports
>>> for a given identityref data node.
>>> 
>>> The common implementation strategy is to completely ignore YANG conformance 
>>> for identities
>>> (as Mahesh explained). You just try setting the leaf and see if the server 
>>> accepts it.
>>> 
>>> Andy
>>> 
>>> 
>>> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani 
>>> mailto:mjethanand...@gmail.com>> wrote:
>>> Hi Linda,
>>> 
>>> 
>>>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar >>> <mailto:linda.dun...@huawei..com>> wrote:
>>>> 
>>>> Dear YANG Doctor:
>>>>  
>>>> We need your help in reviewing the YANG model in 
>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF WG is about to call 
>>>> WGLC.
>>>>  
>>>> In particular, we need your advice on the following issue:
>>>>  
>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 imports from 
>>>> draft-ietf-netconf-crypto-types, which appears to be a generic list of 
>>>> algorithms.
>>>> The problem is that the list in draft-ietf-netconf-crypto-types could 
>>>> contain algorithms that are not suitable for IPsec (such as secp192r1 for 
>>>> key agreement), and right now it seems to lack some older algorithms that 
>>>> have fallen out of fashion (3DES) but is still needed in IPsec.  
>>> 
>>> All the algorithms in draft-ietf-netconf-crypto-types are defined as 
>>> identities. If you do not find the algorithm you are looking for in the 
>>> list of defined algorithms, you can go ahead and define your own in your 
>>> own draft, using the same base identity from the ietf-crypto-types module.
>>> 
>>>>  
>>>>  
>>>> Questions to the YANG Doctor:
>>>> 1.   Is it better to list the IPsec specific algorithms in 
>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection (which is a subset of 
>>>> draft-ietf-netconf-crypto-types? Or to import all crypto algorithms many 
>>>> of which are not relevant to IPsec? What is the common practice? 
>>> 
>>> Importing ietf-crypto-types does not mean you have to implement every 
>>> algorithm listed in the module. You can import the module and chose to 
>>> implement the algorithms you want to imp

Re: [I2nsf] [yang-doctors] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC

[Yoav Nir]

At this point I’m wondering if it would not be a better strategy to avoid all 
enumerations of algorithms, whether they are spelled out or imported from 
draft-ietf-netconf-crypto-types, and instead use the numbers from the IANA 
registry for IPsec.

That does not help us deprecate old algorithms, but it solves the other issue, 
which is what to do when a new algorithm is added to IPsec. We don’t want to 
have to publish a new i2nsf document whenever that happens, and if the 
algorithm identifier is just a number, new values can be added by IANA.

Yoav

> On 5 Apr 2019, at 20:42, Andy Bierman  wrote:
> 
> Hi,
> 
> I think conformance for identities is handled very poorly in YANG.
> There is an if-feature-stmt allowed inside an identity in YANG 1.1.
> This implies that any identity without if-feature is mandatory-to-implement.
> 
> If the identities are in a separate module, the server can list it as an 
> imported module,
> which tells the client the server does not implement any of the identities.
> 
> There is no standard way for the server to inform the client which identities 
> it supports
> for a given identityref data node.
> 
> The common implementation strategy is to completely ignore YANG conformance 
> for identities
> (as Mahesh explained). You just try setting the leaf and see if the server 
> accepts it.
> 
> Andy
> 
> 
> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani  > wrote:
> Hi Linda,
> 
> 
>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar > > wrote:
>> 
>> Dear YANG Doctor:
>>  
>> We need your help in reviewing the YANG model in 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF WG is about to call 
>> WGLC.
>>  
>> In particular, we need your advice on the following issue:
>>  
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 imports from 
>> draft-ietf-netconf-crypto-types, which appears to be a generic list of 
>> algorithms.
>> The problem is that the list in draft-ietf-netconf-crypto-types could 
>> contain algorithms that are not suitable for IPsec (such as secp192r1 for 
>> key agreement), and right now it seems to lack some older algorithms that 
>> have fallen out of fashion (3DES) but is still needed in IPsec.  
> 
> All the algorithms in draft-ietf-netconf-crypto-types are defined as 
> identities. If you do not find the algorithm you are looking for in the list 
> of defined algorithms, you can go ahead and define your own in your own 
> draft, using the same base identity from the ietf-crypto-types module.
> 
>>  
>>  
>> Questions to the YANG Doctor:
>> 1.   Is it better to list the IPsec specific algorithms in 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection (which is a subset of 
>> draft-ietf-netconf-crypto-types? Or to import all crypto algorithms many of 
>> which are not relevant to IPsec? What is the common practice? 
> 
> Importing ietf-crypto-types does not mean you have to implement every 
> algorithm listed in the module. You can import the module and chose to 
> implement the algorithms you want to implement, including defining any new 
> ones.
> 
>> 2.  If we do import from draft-ietf-netconf-crypto-types, does it mean 
>> draft-ietf-i2nsf-sdn-ipsec-flow-protection cannot be published until 
>> draft-ietf-netconf-crypto-types is published?
> 
> Yes. The i2nsf draft will hit the state of MISSREF in the RFC Editor queue. 
> But that should not prevent anyone from starting implementation of the 
> module. As a side note, the NETCONF WG is planning on sending the 
> crypto-types draft to IESG shortly. What you do not want is to duplicate the 
> definition of the algorithms in your own draft.
> 
> HTH.
> 
>>  
>>  
>> Thank you very much, 
>>  
>> Linda & Yoav
>>  
>> ___
>> yang-doctors mailing list
>> yang-doct...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/yang-doctors 
>> 
> Mahesh Jethanandani
> mjethanand...@gmail.com 
> 
> 
> 
> ___
> yang-doctors mailing list
> yang-doct...@ietf.org 
> https://www.ietf.org/mailman/listinfo/yang-doctors 
> 
> ___
> I2nsf mailing list
> I2nsf@ietf.org 
> https://www.ietf.org/mailman/listinfo/i2nsf 
> 
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [TLS] A flags extension

[Yoav Nir]

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

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


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

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

Re: [TLS] A flags extension

[Yoav Nir]

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

OK. You got me convinced.

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

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

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


Yoav

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

Re: [TLS] A flags extension

[Yoav Nir]

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

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

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

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

Yoav

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

Re: [TLS] A flags extension

[Yoav Nir]

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

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

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

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

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

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

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

Yoav



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

Re: [TLS] A flags extension

[Yoav Nir]

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

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



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

Re: [TLS] A flags extension

[Yoav Nir]

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

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

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

The question is which is more likely?

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

Re: [TLS] A flags extension

[Yoav Nir]

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

Ah, the beautiful variable length encodings.  Like:

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

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

[TLS] A flags extension

[Yoav Nir]

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

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

Comments are welcome.

Yoav

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



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

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

[Yoav Nir]

Hi.

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


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


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


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

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


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


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

Yoav

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

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

[Yoav Nir]

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

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


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

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

[Yoav Nir]

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

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

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

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

Yoav

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

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

[Yoav Nir]

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

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

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

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

Yoav

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

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

Re: [Acme] IETF 104 Agenda

[Yoav Nir]

Hi Rifaat.

We only have one hour in total.  It's about 5 minutes for the administrative 
stuff, another 10 for status and reconfirming STAR, and maybe 5-10 for status 
of other things. The rest (about 40 minutes) is for device attestation and 
client certs.

⁣Sent from my phone ​


 Original Message 
From: Rifaat Shekh-Yusef 
Sent: Thu Mar 21 13:18:59 GMT+02:00 2019
To: "Salz, Rich" 
Cc: "acme@ietf.org" 
Subject: Re: [Acme] IETF 104 Agenda

Rich,

How much time is allocated to these items?

Regards,
 Rifaat


On Tuesday, March 19, 2019, Salz, Rich  wrote:

> The agenda has been posted to https://datatracker.ietf.org/
> meeting/104/session/acme  It is also below.
>
>
>
> If you want to volunteer before the meeting to do Jabber and/or minutes
> (via etherpad if you prefer), please email acme-cha...@ietf.org
>
>
>
> ACME at IETF 104
>
> Weds 11:20-12:20
>
>
>
>
>
> Admin
>
> Bluesheets, note-taker, jabber
>
> Status
>
>
>
> STAR
>
> Reconfirm lastcall (consensus)
>
>
>
> Device Attestation
>
>
>
> Client certificates
>
>
>
> TNAuth (?)
>
>
>
> Other ?
>




___
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] RFC 8555 on Automatic Certificate Management Environment (ACME)

[Yoav Nir]

Starting work on the champagne & ticker-tape slide for the meeting.

Thanks everyone for all the work.

> On 11 Mar 2019, at 23:44, Richard Barnes  wrote:
> 
> Thanks to everyone for your work on this!  
> 
> On Mon, Mar 11, 2019 at 5:08 PM  > wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 8555
> 
> Title:  Automatic Certificate Management Environment (ACME) 
> Author: R. Barnes,
> J. Hoffman-Andrews,
> D. McCarney, 
> J. Kasten
> Status: Standards Track
> Stream: IETF
> Date:   March 2019
> Mailbox:r...@ipv.sx, 
> j...@eff.org , 
> c...@letsencrypt.org ,
> jdkas...@umich.edu 
> Pages:  95
> Characters: 196903
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-ietf-acme-acme-18.txt
> 
> URL:https://www.rfc-editor.org/info/rfc8555 
> 
> 
> DOI:10.17487/RFC8555
> 
> Public Key Infrastructure using X.509 (PKIX) certificates are used
> for a number of purposes, the most significant of which is the
> authentication of domain names.  Thus, certification authorities
> (CAs) in the Web PKI are trusted to verify that an applicant for a
> certificate legitimately represents the domain name(s) in the
> certificate.  As of this writing, this verification is done through a
> collection of ad hoc mechanisms.  This document describes a protocol
> that a CA and an applicant can use to automate the process of
> verification and certificate issuance.  The protocol also provides
> facilities for other certificate management functions, such as
> certificate revocation.
> 
> This document is a product of the Automated Certificate Management 
> Environment Working Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards 
> ) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce 
> 
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist 
> 
> 
> For searching the RFC series, see https://www.rfc-editor.org/search 
> 
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 
> 
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org 
> .  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> ___
> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Yoav Nir]

> On 18 Jan 2019, at 1:20, Richard Barnes  wrote:
> 
> "Whatever you do, contemplate death"
> — Seneca

He must have been lots of fun at parties.

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

Re: [IPsec] On marking algorithms obsolete in IANA registries

[Yoav Nir]

> On 18 Dec 2018, at 17:19, Paul Wouters  wrote:
> 
> On Tue, 18 Dec 2018, paul.kon...@dell.com wrote:
> 
>>> Well, I think it's a bit too complex for random implementer.
>>> I'd prefer to classify all algorithms as follows:
>>> 
>>> 1. Secure, required for interoperability
>>> 2. Secure, not required for interoperability
>>> 3. Insecure (obsoleted)
> 
>> Possibly some algorithms are candidates for "obsolete" status not because 
>> they are known to be insecure but because they never got traction or 
>> security analysis.  I'm not sure if CAST is an example.
>> 
>> On terminology: "secure" is too strong a statement for the non-expert 
>> audience.  "Believed to be secure" would be more prudent, but I don't really 
>> like those words either.  Can we come up with some words that don't suggest 
>> a guarantee we can't make?
> 
> When I described the various SHOULD, MAY, MUST and their variants, I was
> not suggesting of putting that into the IANA registry. The IANA registry
> should only get "deprecated" or "obsolete". In my view (and I think the
> RFCs view) deprecrated means "issues found, stop using it" and
> "obsolete" means "meh, not harmful but no one else is using it anymore”.

I think it’s best to copy what TLS is doing and just add a “Recommended” column 
with a y/n value to all the algorithm lists.

A prudent administrator enables the algorithms marked “Recommended” and none of 
the others.

An administrator that enables other algorithms will have to explain why he or 
she did that when things go wrong.

TLS did write a document to change the IANA registries like that.

Yoav

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

Re: [IPsec] On marking algorithms obsolete in IANA registries

[Yoav Nir]

Hi, Paul

I think we need an RFC to at least categorize the algorithms, unless we want 
the IANA registry to have stuff like “SHOULD-“ and “MAY+:

> On 18 Dec 2018, at 6:14, Paul Wouters  wrote:
> 
> 
> Recently we had a discussion about mapping IANA entries to a yang model,
> and the question came up whether we sould add a deprecated marker to the
> IKE/ESP registries for algorithms.
> 
> I thought it was a good idea, but not everyone agreed.
> 
> I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility 
> and Selecting Mandatory-to-Implement Algorithms
> 
> 
> Section 2.1: Algorithm Identifiers
> 
>   In the IPsec protocol suite, the Internet Key Exchange Protocol
>   version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the
>   Authentication Header (AH) [RFC4302] and the Encapsulating Security
>   Payload (ESP) [RFC4303].  Such separation is a completely fine design
>   choice.  [...]
> 
>   An IANA registry SHOULD be used for these algorithm or suite
>   identifiers.  Once an algorithm identifier is added to the registry,
>   it should not be changed or removed.  However, it is desirable to
>   mark a registry entry as deprecated when implementation is no longer
>   advisable.
> 
> So there is even an RFC stating that we should really do this :)
> 
> I guess the main question is, can we add these via a request to IANA
> based on RFC 8221 and 8247, or do we need to write a short RFC with
> requests to IANA?
> 
> Paul
> 
> ___
> 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] replacing PSKs: CFRG and PAKE

[Yoav Nir]

Hi, Valery

> On 12 Dec 2018, at 11:02, Valery Smyslov  wrote:
> 
>>> I see this as a social issue, not a technical one. We can't prevent
>>> administrators from being careless, either with PSKs or with passwords.
>> 
>> We can make more secure deployments easier.
>> 
>> If the only change on the site-to-site config is to change the keyword
>> "psk" to "pake" and that prevents offline dictionary attacks, that's an
>> easy win.
> 
> I'm not so sure. Replacing PSK with password+PAKE could in fact decrease 
> security.
> Properly chosen PSK provides high level of protection against both passive
> and active attacks. On the other hand, PAKE, as far as I know,
> only makes it difficult for passive eavesdropper to perform offline
> dictionary attack. But an active attacker may still try out all possible
> password values (due to small search space). Yes, you can easier
> detect active attackers and block them (and site-to-site VPNs
> usually have fixed IPs, that simplifies the task), but I still feel a bit 
> uncomfortable
> by the idea of replacing perfectly secure crypto mechanism with a weaker one. 
> I'd rather educate administrators :-) And note, that no PAKE will
> save you if administrators will select passwords like "foobar" or "12345".
> 
> I think that PAKE is a very good mechanism for remote access
> in situation when certificates (or raw public keys) cannot be used
> for various reasons. E.g. f simple CPE that has no memory
> to securely store private key.

I don’t think the idea is to replace a 128-bit PSK derived from a properly 
seeded DRBG with “ip5ecmeRockz!” using a PAKE.

I think we’re assuming the administrator will configure “ip5ecmeRockz!” (or 
“foobar”) regardless of what we call it, so we might as well give them a better 
mechanism to use this value.

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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

[Yoav Nir]

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the 
two NSFs generate traffic keys between themselves, and in the other it is the 
controller that generates the keys for them.  So how about “distributed keying” 
vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.


Also, I have been asked by someone not on this list whether our work covers the 
road warrior use case. I said it didn’t and wondered why. So I got these points:
Road warriors are numerous and not where the administrator can configure them 
manually.
Additionally, the configuration of what networks, gateways (NSFs), and 
resources a road warrior may access (in IPsec terms, the SPD and PAD) change 
often.
Because of the above, some automatic method of configuring SPD and PAD is 
needed.
There is also the issue of multiple VPN gateways covering similar domains, and 
VPN gateways being overloaded or down for maintenance, as well as malfunctions 
in the network behind those VPN gateways. So the decision on which gateway a 
road warrior should use to access a particular resource is also a natural 
question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:
The current configuration was formatted (automatically by a management 
function) as a text file that the road warrior downloaded through the VPN 
gateway (the gateway doubled as a server serving this one file)
The proper gateway to connect to was determined by pinging all gateways that 
were possible according to the configuration file.
This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case 
for road warrior SDN.

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

Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

[Yoav Nir]

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the 
two NSFs generate traffic keys between themselves, and in the other it is the 
controller that generates the keys for them.  So how about “distributed keying” 
vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.


Also, I have been asked by someone not on this list whether our work covers the 
road warrior use case. I said it didn’t and wondered why. So I got these points:
Road warriors are numerous and not where the administrator can configure them 
manually.
Additionally, the configuration of what networks, gateways (NSFs), and 
resources a road warrior may access (in IPsec terms, the SPD and PAD) change 
often.
Because of the above, some automatic method of configuring SPD and PAD is 
needed.
There is also the issue of multiple VPN gateways covering similar domains, and 
VPN gateways being overloaded or down for maintenance, as well as malfunctions 
in the network behind those VPN gateways. So the decision on which gateway a 
road warrior should use to access a particular resource is also a natural 
question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:
The current configuration was formatted (automatically by a management 
function) as a text file that the road warrior downloaded through the VPN 
gateway (the gateway doubled as a server serving this one file)
The proper gateway to connect to was determined by pinging all gateways that 
were possible according to the configuration file.
This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case 
for road warrior SDN.

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

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

[Yoav Nir]

> On 20 Nov 2018, at 17:14, Paul Wouters  wrote:
> 
> On Mon, 19 Nov 2018, Rafa Marin Lopez wrote:
> 
>>> Based on the introduction and abstract of the draft, this document does two 
>>> things:
>>> 
>>> 1) Specify a yang model for use with SDWAN + IKE + IPsec
>>> 2) Define the desired modes and algorithms to use with 1)
>>> 
>>> It does not try to map the entire IKE/IPsec IANA registry into a yang 
>>> model. Let me know if this is incorrect, because I use
>>> this as an assumption for the remainder of the review.
>> 
>> We must say that our I-D specifies 1) but being SDWAN one of the possible 
>> scenarios to operate so that the intent was to map the IKE/IPsec IANA 
>> registry. In any case we can change that approach if the WG consider is the 
>> right way to proceed.
> 
> Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD
> or MUST (and not include MUST- or SHOULD-)
> 
> So if any other new uses are defined, they don't try to use obsoleted or
> decayed algorithms.
> 

Hi, Paul.

While I agree with your conclusion (although I think it’s fine to include the 
single MUST- which is HMAC-SHA1), this is not really a new application. It’s 
more like a new control plane for the old VPN application.

The typical implementation for the NSF in the ipsec-flow-protection draft will 
be running on a machine that has an IPsec and potentially IKE implementation. 
The authors’ own implementation is running on top of the Linux kernel (and 
StrongSwan). If I was still working for an IPsec vendor, I would implement this 
as a new usermode process pushing SAs or policy into the kernel and into the 
VPN daemon. 

So this isn’t like TLS 1.3 where you’ll need to upgrade the TLS implementation 
anyway to get TLS 1.3, and the new crypto will just come in the same package. 
The NSF code can be made to run on top of a 10-year-old software implementation 
or 10-year-old hardware from before AES-GCM existed.

Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux can 
work, which is why I agree with your conclusion, except for the tweak that 
MUST- is also OK.

Yoav

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

Re: [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03

[Yoav Nir]

> On 20 Nov 2018, at 17:14, Paul Wouters  wrote:
> 
> On Mon, 19 Nov 2018, Rafa Marin Lopez wrote:
> 
>>> Based on the introduction and abstract of the draft, this document does two 
>>> things:
>>> 
>>> 1) Specify a yang model for use with SDWAN + IKE + IPsec
>>> 2) Define the desired modes and algorithms to use with 1)
>>> 
>>> It does not try to map the entire IKE/IPsec IANA registry into a yang 
>>> model. Let me know if this is incorrect, because I use
>>> this as an assumption for the remainder of the review.
>> 
>> We must say that our I-D specifies 1) but being SDWAN one of the possible 
>> scenarios to operate so that the intent was to map the IKE/IPsec IANA 
>> registry. In any case we can change that approach if the WG consider is the 
>> right way to proceed.
> 
> Then I would stick with RFC 8221 and RFC 8247 entries that have SHOULD
> or MUST (and not include MUST- or SHOULD-)
> 
> So if any other new uses are defined, they don't try to use obsoleted or
> decayed algorithms.
> 

Hi, Paul.

While I agree with your conclusion (although I think it’s fine to include the 
single MUST- which is HMAC-SHA1), this is not really a new application. It’s 
more like a new control plane for the old VPN application.

The typical implementation for the NSF in the ipsec-flow-protection draft will 
be running on a machine that has an IPsec and potentially IKE implementation. 
The authors’ own implementation is running on top of the Linux kernel (and 
StrongSwan). If I was still working for an IPsec vendor, I would implement this 
as a new usermode process pushing SAs or policy into the kernel and into the 
VPN daemon. 

So this isn’t like TLS 1.3 where you’ll need to upgrade the TLS implementation 
anyway to get TLS 1.3, and the new crypto will just come in the same package. 
The NSF code can be made to run on top of a 10-year-old software implementation 
or 10-year-old hardware from before AES-GCM existed.

Still, as long as AES-CBC and HMAC-SHA1 are in, even that 10-year-old Linux can 
work, which is why I agree with your conclusion, except for the tweak that 
MUST- is also OK.

Yoav

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

Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

[Yoav Nir]

Thanks, Rafa.

Just one response below.

> On 14 Nov 2018, at 11:30, Rafa Marin-Lopez  wrote:
> 
> Hi Yoav:
> 
>> El 8 nov 2018, a las 17:11, Yoav Nir > <mailto:ynir.i...@gmail.com>> escribió:
>> 
>> Hi, all
>> 
>> As discussed in the room, we need some reviewers for the 
>> sdn-ipsec-flow-protection draft ([1])
> 
> Thanks for these comments. Please see our response below.
>> 
>> While any comments on any part of the document are welcome, I would like 
>> people to concentrate on the following issues:
>> The YANG model in Appendix A
>> Some of the crypto seems obsolete (example: DES). We would get into trouble 
>> in SecDir review.  OTOH ChaCha20-Poly1305 is missing..
> 
> Agree. We will remove DES and add the algorithm you mention.

The TLS working group went quite far with TLS 1.3.  Only 2 ciphers remain: 
AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That’s it.  Specifically, 
they’ve deprecated everything that isn’t an AEAD.

The IPsecME working group hasn’t gone that far yet.  But in practice pretty 
much nothing is used except 3DES, AES-CBC, and AES-GCM.  Perhaps 
ChaCha20-Poly1305 is starting to see some use by now. We have RFC 8221, 
especially sections 5 and 6.  I think (although it’s up to the working group) 
that we should be fine defining only the MUSTs and the SHOULDs in those 
sections.

That brings another question. What is our plan for future expansions?  Suppose 
there’s some hot, new algorithm that everyone is implementing. How do you 
update the YANG model in the future when you add new values to the 
enumerations?  Is it up to the administrator to make sure that the controller 
and NSFs are all on the “same page”?

Thanks

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

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

[Yoav Nir]

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

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

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

[I2nsf] Reviewing sdn-ipsec-flow-protection

[Yoav Nir]

Hi, all

As discussed in the room, we need some reviewers for the 
sdn-ipsec-flow-protection draft ([1])

While any comments on any part of the document are welcome, I would like people 
to concentrate on the following issues:
The YANG model in Appendix A
Some of the crypto seems obsolete (example: DES). We would get into trouble in 
SecDir review.  OTOH ChaCha20-Poly1305 is missing..
Some of the modes are obsolete (BEET)
KINK & IKEv1
The YANG model in Section 6
I think there’s a bit of TMI in there:  Not all fields in an IPsec 
implementation need to be sent from the controller (SA state, like “larval")
The interaction between Controller and NSF
There’s no way for the controller to retrieve NSF capabilities. What if the NSF 
does not implement rc5?  It’s fine if we say that the Controller knows in 
advance what the capabilities of each NSF are, but it should be stated.
ISTM like the Controller sends the private key and the certificate to the NSF. 
While this is a possible model, it is also quite common for private keys to be 
generated in the NSF and never leave the cryptographic boundary. I think this 
should be at least allowed.

Thanks to Paul Wouters and two others who volunteered to review. Substantive 
reviews will be rewarded with a beer in Prague.

Yoav

[1] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

[Acme] ACME implementation (was: Re: Draft minutes)

[Yoav Nir]

[changing the subject]

That’s great, Marcos.

We currently don’t have a list of implementations.  If you want, you can start 
one.

Good places for such a list could be:
The GitHub project wiki: https://github.com/ietf-wg-acme/acme/wiki or
The tools wiki: https://trac.ietf.org/trac/acme

If you need help with setting up a Hackathon slot in Prague, please contact 
Rich or me.

Yoav

> On 8 Nov 2018, at 18:42, Marcos Sanz  wrote:
> 
> I wanted to say the following during AOB, but somehow I missed the moment. 
> We've done an open source Java ACME server implementation:
> 
> https://gitlab.com/ID4me/Acme
> 
> We kind of stopped work at the -09 draft (you guys have been very prolific 
> lately) and not all resources/endpoints/functions are implemented 
> (shortly, we properly deal with accounts and have implemented 
> pre-authorization and DNS challenges because that is all we needed in our 
> project), but it could be a good skeleton to work further towards a 
> full-fledged ACME CA, maybe in an upcoming IETF hackathon. 
> Feedback/contributions are still anytime welcome.
> 
> Best regards,
> Marcos
> 
> ___
> 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] Authority Token at today's meeting

[Yoav Nir]

Hi, all

We have a slot on our agenda reserved for the authority token drafts ([1],[2])

Who is going to present?  And please send the slides.

If the authors do not intend to present, please at least send a status update 
to the list or the chairs.

Thanks

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

[IPsec] Heads Up: I2NSF Meeting Today

[Yoav Nir]

Hi all

FYI: The I2NSF working group is meeting today immediately after IPsecME and in 
the same room (convenient!)

We are going to spend some time on SDN-based IPsec Flow Protection [1].  We 
have had some discussion in the past about Case #2, which is about provisioning 
traffic keys (in the form of IPsec SAs) from an SDN controller to the NSF 
(which is I2NSF-speak for, among others, an IPsec host/gateway). There were 
some objections and we would like to bring that discussion to a close.

For your convenience, this part is the first thing on our agenda.  You are all 
invited.

As a heads-up, we will also be looking for a volunteer to help with review of 
this document, especially with pruning some of the YANG stuff in Appendix A 
([2]). It’s been suggested that 2018 is the wrong year to publish a way to 
configure IPsec gateways to use DES.  Or KINK.

Hope to see you all there,

Linda & Yoav

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

[2] 
https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03#appendix-A
 


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

Re: [Acme] high-value definition

[Yoav Nir]

High-value is not synonymous with a phishing site. If anything, it is a victim 
of phishing sites.

Paypal.com  and bankofamerica.com 
 are high-value sites.

paypaal.com  and bank-of-america.com 
 are phishing sites.

Yoav

> On 2 Nov 2018, at 17:36, Carl Wallace  wrote:
> 
> The term high-value is used twice in the ACME draft but is never defined.
> I think I understand what it means but in chatting with some others, there
> is at least one interpretation that high-value means phishing sites. If
> this is the correct definition, I suggest removing either the high-value
> or phishing bullet in section 10.5 or including a note to affirm these
> terms are synonymous. Including a definition may be worthwhile in any
> case. 
> 
> 
> ___
> 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] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes)

[Yoav Nir]

Hi.

RFC 7296 has the INTERNAL_ADDRESS_FAILURE notification as optional — gateways 
are free to just ignore the requests. However, having read 3.15.4 again, I see 
that the text does say “If the responder encounters an error while attempting 
to assign an IP address to the initiator during the processing of a 
Configuration payload, it responds with an INTERNAL_ADDRESS_FAILURE 
notification.”.  So I’m convinced. It does need to update 7296.

About RFC 5739, at the top of page 3 (and other places) of your draft you 
mention the initiator requesting IPv6 prefix(es). Requesting IPv6 prefixes is 
defined in RFC 7539, which concludes that the way this is defined in 3406 (the 
predecessor of 7296) doesn’t work. I think 5739 should be referenced as 
informative.

Yoav

> On 18 Oct 2018, at 12:49, mohamed.boucad...@orange.com wrote:
> 
> Hi Yoav, 
> 
> Can you please clarify which "stuff" in 5739 you are referring to? 
> 
> The draft updates RFC7296 because it updates the behavior specified in 
> Section 3.15.4 of that RFC. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : IPsec [mailto:ipsec-boun...@ietf.org] De la part de Yoav Nir
>> Envoyé : samedi 13 octobre 2018 15:48
>> À : Tero Kivinen
>> Cc : ipsec@ietf.org
>> Objet : Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-
>> ipv4-codes
>> 
>> I believe the final document should address the stuff in RFC 5739. Also, I’m
>> not sure you need to update 7296 to add some new code points.
>> 
>> Neither of these is a barrier for adoption.
>> 
>> I have read the draft and support its adoption.
>> 
>> Yoav
>> 
>>> On 13 Oct 2018, at 3:09, Tero Kivinen  wrote:
>>> 
>>> Our new charter has been approved and that includes item:
>>> 
>>>   RFC7296 defines a generic notification code that is related to a
>>>   failure to handle an internal address failure. That code does not
>>>   explicitly allow an initiator to determine why a given address
>>>   family is not assigned, nor whether it should try using another
>>>   address family. The Working Group will specify a set of more
>>>   specific notification codes that will provide sufficient
>>>   information to the IKEv2 initiator about the encountered failure.
>>>   A possible starting pointing is
>>>   draft-boucadair-ipsecme-ipv6-ipv4-codes.
>>> 
>>> So this email will start one week long WG adoptation call for that
>>> document [1] for WG adoptation.
>>> 
>>> Send your comments to this list before the 2018-10-21.
>>> 
>>> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-
>> codes/
>>> --
>>> 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

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

Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

[Yoav Nir]

I believe the final document should address the stuff in RFC 5739. Also, I’m 
not sure you need to update 7296 to add some new code points.

Neither of these is a barrier for adoption.

I have read the draft and support its adoption.

Yoav

> On 13 Oct 2018, at 3:09, Tero Kivinen  wrote:
> 
> Our new charter has been approved and that includes item:
> 
>RFC7296 defines a generic notification code that is related to a
>failure to handle an internal address failure. That code does not
>explicitly allow an initiator to determine why a given address
>family is not assigned, nor whether it should try using another
>address family. The Working Group will specify a set of more
>specific notification codes that will provide sufficient
>information to the IKEv2 initiator about the encountered failure.
>A possible starting pointing is
>draft-boucadair-ipsecme-ipv6-ipv4-codes.
> 
> So this email will start one week long WG adoptation call for that
> document [1] for WG adoptation.
> 
> Send your comments to this list before the 2018-10-21.
> 
> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
> -- 
> 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] [Technical Errata Reported] RFC7634 (5441)

[Yoav Nir]

This errata proposes to add the following sentence to section 4 of RFC 7634 
:

As with other transforms that use a fixed-length key, the Key Length attribute 
MUST NOT be specified.

This sentence is correct. If this came up as a suggestion during WG processing 
or during LC, I think we would add it.

Looking back in RFC 7296, we have in section 3.3.5 
:

   o  The Key Length attribute MUST NOT be used with transforms that use
  a fixed-length key.  For example, this includes ENCR_DES,
  ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
  (Integrity Algorithm) transforms specified in this document.  It
  is recommended that future Type 2 or 3 transforms do not use this
  attribute.

And RFC 7634 says:

   o  The encryption key is 256 bits.

Given that, I don’t think there is any chance for a conscientious implementer 
to make the mistake of including the Key Length attribute.

I don’t believe adding clarifying text is a proper use of the errata system. At 
best it should be marked as editorial and held for document update, if not 
rejected outright.

Yoav

> On 26 Jul 2018, at 21:29, RFC Errata System  wrote:
> 
> The following errata report has been submitted for RFC7634,
> "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol 
> (IKE) and IPsec".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5441
> 
> --
> Type: Technical
> Reported by: Andrew Cagney 
> 
> Section: 4
> 
> Original Text
> -
>   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
>   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
>   transform substructure of the SA payload as the ENCR (type 1)
>   transform ID.  As with other AEAD algorithms, INTEG (type 3)
>   transform substructures MUST NOT be specified, or just one INTEG
>   transform MAY be included with value NONE (0).
> 
> Corrected Text
> --
>   When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or
>   IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the
>   transform substructure of the SA payload as the ENCR (type 1)
>   transform ID.
>   As with other transforms that use a fixed-length key, the Key Length
>   attribute MUST NOT be specified.
>   As with other AEAD algorithms, INTEG (type 3)
>   transform substructures MUST NOT be specified, or just one INTEG
>   transform MAY be included with value NONE (0).
> 
> Notes
> -
> Reading both RFC7634 and RFC7539 there seems to be a single fixed-length key 
> of 256-bits.
> Hence, I think https://tools.ietf.org/html/rfc7296#section-3.3.5:
>   o  The Key Length attribute MUST NOT be used with transforms that use
>  a fixed-length key.  For example, this includes ENCR_DES,
>  ENCR_IDEA,...
> applies (my intent is to clarify this).
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC7634 (draft-ietf-ipsecme-chacha20-poly1305-12)
> --
> Title   : ChaCha20, Poly1305, and Their Use in the Internet Key 
> Exchange Protocol (IKE) and IPsec
> Publication Date: August 2015
> Author(s)   : Y. Nir
> Category: PROPOSED STANDARD
> Source  : IP Security Maintenance and Extensions
> Area: Security
> Stream  : IETF
> Verifying Party : IESG



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

Re: [IPsec] Modp-12288 and Modp-16384

[Yoav Nir]

Hi.

Since my message got lost in the overtime, I’ll say it again here.

AFAIK there is very little usage of anything beyond 4096-bit groups. I don't 
sense a need for 16K.  Engineering should be about creating what people need 
(or at least want). 

I haven’t heard anyone say they would like to use 16384-bit DH groups or RSA 
keys. If they want more “bits” then 2048, they usually go to ECDSA/ECDHE or the 
CFRG curves.

I don’t feel strongly about this as in “oh my god, this is horrible for the 
Internet”, but I think this is something we should not do.

Yoav

> On 17 Jul 2018, at 18:15, Tero Kivinen  wrote:
> 
> When we greated RFC3526 [1] in 2003 we included 1536, 2048, 3072,
> 4096, 6144, and 8192 bit modp groups. I did also create 12288 and
> 16384 bit modp groups [2], but we did not include those as we assumed
> they would be too slow for normal use.
> 
> Now sometimes there is requirement to align all security parameters
> with AES-256 also (because AES-128 is not enough if someone gets
> quantum computers some day). 
> 
> SP800-57 part 1 rev 4 [3] has table 2 that says:
> 
> Security  Symmetric FCC   IFC   ECC
> Strength  key   (e.g. DSA,(e.g.,(e.g., 
>  algorithmsD-H)  RSA)  ECDSA)
> <=80  2TDEA L=1024, N=160 k=1024f=160-233
> 112   3TDEA L=2048, N=224 k=2048f=224-255
> 128   AES-128   L=3072, N=256 k=3072f=256-383
> 192   AES-192   L=7680, N=384 k=7680f=384-511
> 256   AES-256   L=15360, N=512k=15360   f=512+
> 
> Meaning that we do not have any MODP groups with IANA numbers that
> would match AES-256. For vendor to add elliptic curve support to
> simply be able to mark that tick mark saying we do support AES-256 is
> bit much. Adding 16384 bit MODP group is much faster and easier, and
> nobody does not need to use it (I think the recommended group in NIST
> documents is still the 2048 bit group).
> 
> NIST SP 800-56A Rev 3 [4] aligns with this and says that MODP-8192 is
> for less than 200 bits of security, i.e., not enough for AES-256.
> 
> In the SP 800-56B rev2 draft [5], there is formula in Appendix D,
> which allows you to calculate the strength for different bit lengths
> and if you plug in the 15360 you get 264 bits. To get 256 bits of
> maximum strength the nBits needs to be between 14446-14993. 15000
> would already give you 264, i.e., the same than 15360 gives. 15360 is
> of course 1024*15 so it is nice round number in binary.
> 
> If you plug in 12288 to that formula you get strength of 240 and 16384
> gives you 272.
> 
> Checking old performance numbers I can see that in 2008 the speed of
> 6144 group was same as 16384 is with current machines, which most
> likely matched what 2048 or 3072 bit group speed was in 2003 (i.e.
> about half a second per full Diffie-Hellman).
> 
> So my question is do other people think it would be useful to allocate
> IANA numbers for the 12288 and 16384 bit MODP groups?
> 
> You can of course use private numbers, but I myself think it would be
> good idea to have IANA numbers for those groups too, just in case
> someone wants interoperability with them at some point. Also we do not
> yet know how quantum computers are going to do for different
> algorithms, i.e., whether P-521 is harder or easier than MODP 16384.
> 
> [1] https://datatracker.ietf.org/doc/rfc3526/
> [2] https://kivinen.iki.fi/primes/
> [3] 
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
> [4] 
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
> [5] 
> https://csrc.nist.gov/CSRC/media/Publications/sp/800-56b/rev-2/draft/documents/sp800-56Br2-draft.pdf
> -- 
> 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] Modp-12288 and Modp-16384

[Yoav Nir]

> On 18 Jul 2018, at 19:08, Graham Bartlett (grbartle) 
>  wrote:
> 
> Hi Tero
> 
> I've no issues per se with this, but as per our chat in London, most VPN 
> consumers pick the group with the highest number (of course group24 is more 
> secure than group21, 24 is bigger than 21 ...!)..

Hasn’t been my experience. Most customers stay with the default. Sophisticated 
customers compare number of bits. So again 2048-bit group 24 is much better 
than 521-bit group 21, but nowhere near as good as 8192-bit group 18.

> Maybe some words of warning around potential performance impact. I’m sure 
> someone somewhere in the world will want this.. 

They only need 16384-bit DH if they use 16384-bit RSA, no?

> I feel for the poor vendors support desk "dear customer, I know you enabled 
> group38 (RSA 16384) and now your 5000 device full mesh solution is not 
> converging as quickly as it did before..”..

Publish it and they will come. I once had to tackle a customer request to 
filter by the RFC 3514 security flag.  As it turns out, this was totally 
possible with my employer’s firewall product. It just wasn’t a good idea.

Yoav


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

Re: [I2nsf] [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Yoav Nir]

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez  wrote:



> Regarding the question about smart objects, I do not understand why a 
> constrained device cannot be a flow-based NSF.  
> 

I don’t think IOT devices are going to be NSFs.  There is no hard definition 
for what a smart object is, but some common features are:
 - low power
 - intermittent operation
 - (relatively) weak in terms of CPU / memory /  network bandwidth. Often this 
is measured in tens of kilobytes of memory and 100/250 kbps.
 - interacts with the real world - has sensors and/or actuators

So none of this says NSF to me, especially the bandwidth.

Which is why I believe that any device that is actually used as an NSF 
implementing IPsec is also likely to have enough power to run IKE.

> Regarding case 2. It follows a SDN model: control plane and data plane. Data 
> plane the IPsec stack is the data plane, which deals with flows; control 
> plane is implemented in the SDN controller. NSF are simpler. One of the key 
> points here is that key material is seen by the SDN controller (which, we 
> should not forget, it is a trusted entity). In this sense, for example, 
> draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH 
> public/private keys trying to avoid this. Other options could be also 
> considered.

It is true that the SDN controller is a trusted entity. We still prefer to 
limit the attack surface by not giving it access to traffic keys. There is no 
doubt that a malicious controller can make the NSFs tunnel all traffic through 
a pervasive monitoring server. We have to trust it not to do that. What we can 
prevent is having it leak the traffic keys through printing them to logs, 
crashing and storing them in core files, swapping them from memory to disk and 
all the other ways that applications leak sensitive information.  That’s just 
not good key hygiene.

That said, a simpler NSF is an NSF that needs less maintenance, less software 
updates, less angst over random-number generators that turn out to be not 
random enough. It’s possible that there is a use case for your case #2 or 
draft-carrel’s modification.  It would be interesting if someone has market 
data about whether people would like to deploy such configurations. 

Unfortunately, the slot this work has in I2NSF is not long enough to hash this 
out.
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [IPsec] [I2nsf] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Yoav Nir]

> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez  wrote:



> Regarding the question about smart objects, I do not understand why a 
> constrained device cannot be a flow-based NSF.  
> 

I don’t think IOT devices are going to be NSFs.  There is no hard definition 
for what a smart object is, but some common features are:
 - low power
 - intermittent operation
 - (relatively) weak in terms of CPU / memory /  network bandwidth. Often this 
is measured in tens of kilobytes of memory and 100/250 kbps.
 - interacts with the real world - has sensors and/or actuators

So none of this says NSF to me, especially the bandwidth.

Which is why I believe that any device that is actually used as an NSF 
implementing IPsec is also likely to have enough power to run IKE.

> Regarding case 2. It follows a SDN model: control plane and data plane. Data 
> plane the IPsec stack is the data plane, which deals with flows; control 
> plane is implemented in the SDN controller. NSF are simpler. One of the key 
> points here is that key material is seen by the SDN controller (which, we 
> should not forget, it is a trusted entity). In this sense, for example, 
> draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH 
> public/private keys trying to avoid this. Other options could be also 
> considered.

It is true that the SDN controller is a trusted entity. We still prefer to 
limit the attack surface by not giving it access to traffic keys. There is no 
doubt that a malicious controller can make the NSFs tunnel all traffic through 
a pervasive monitoring server. We have to trust it not to do that. What we can 
prevent is having it leak the traffic keys through printing them to logs, 
crashing and storing them in core files, swapping them from memory to disk and 
all the other ways that applications leak sensitive information.  That’s just 
not good key hygiene.

That said, a simpler NSF is an NSF that needs less maintenance, less software 
updates, less angst over random-number generators that turn out to be not 
random enough. It’s possible that there is a use case for your case #2 or 
draft-carrel’s modification.  It would be interesting if someone has market 
data about whether people would like to deploy such configurations. 

Unfortunately, the slot this work has in I2NSF is not long enough to hash this 
out.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [I2nsf] How about simplified IKE? RE: [IPsec] IPsec Flow Protection @I2NSF

[Yoav Nir]

[no hats]

I’m not convinced by the necessity of either this or “Case 2”.  

IKEv2 is supported by all operating systems, including every Linux distribution 
and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. Given that, I’m 
not convinced we need to take care of nodes that do not support IKEv2. There 
just aren’t any such nodes in the NSF world. If we were talking about smart 
objects, then we could find such nodes, but not NSFs.

IKE performs two functions:
Authenticate the peers to one another
Exchange keys.

If I understand your proposal correctly, you would like to keep the peers 
exchanging keys (although not directly), but not authenticating. This kind of 
makes sense because the SDN controls identities and credentials. There is no 
meaningful authentication except to verify the credentials provided to the peer 
by the controller.

So I think the proposal makes sense, but I don’t see it as necessary.

Yoav
(again, no hats)

> On 17 Jul 2018, at 6:16, Linda Dunbar  wrote:
> 
> There are two cases proposed by  SDN controlled IPsec Flow Protection:
> -Case 1 is SDN controller only sending down the IPsec configuration 
> attributes to End points, and End Points supports the IKEs and SA maintenance.
> -Case 2 is end points not supporting IKEv2. SDN controller manage all 
> the SA Key computation and distribute to all end nodes. We had an interim 
> meeting discussing this. (see the attached Meeting minutes).
>  
> Question to IPsecme WG: How about something in between? 
> -Assume that SDN controller maintain TLS (or DTLS) to all end points 
> for distributing the IPsec configuration attributes (same as Case 1 above).
> -Instead of using IKEv2 for two end points (E1 & E2) to establish 
> secure channel first for SA negotiation purpose, E1 can utilize the secure 
> channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and 
> responsible for its own SA computation. 
> -E1&E2 still compute SA and maintain SAD. Only utilize the secure 
> channel through the SDN controller to exchange SA.
>  
> This method not only doesn’t require the SDN controller to keep all the SAD 
> for all nodes, but also simplify large SD-WAN deployment with large number of 
> IPsec tunnels among many end points.
>  
> Any opinion? Issues? 
>  
> Linda Dunbar
>  
>   <>
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Yoav Nir
> Sent: Monday, July 16, 2018 3:11 PM
> To: IPsecME WG mailto:ip...@ietf.org>>
> Subject: [IPsec] IPsec Flow Protection @I2NSF
>  
> Hi.
>  
> I’d like to draw you attention to the agenda of the I2NSF working group: 
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 
> <https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00>
>  
> The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
> there is this item which may be of interest to IPsec folks:
>  
> 13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
> In case you haven’t been following, the IPsec flow draft was adopted by 
> I2NSF. The authors are making progress, including open source implementations.
>  
> One issue that may come up in the discussion (either at I2NSF or here) is 
> that other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming 
> up. I’m wondering if these are competing, complementary, or what?
>  
> We’ll be glad to see you all there.
>  
> Yoav
> (co-chair of I2NSF)
>  
> [1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 
> <https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00>
> [2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 
> <https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02>
>  
> 

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

Re: [IPsec] How about simplified IKE? RE: IPsec Flow Protection @I2NSF

[Yoav Nir]

[no hats]

I’m not convinced by the necessity of either this or “Case 2”.  

IKEv2 is supported by all operating systems, including every Linux distribution 
and phone OS since iPhone 2. It’s ubiquitous and isn’t hard. Given that, I’m 
not convinced we need to take care of nodes that do not support IKEv2. There 
just aren’t any such nodes in the NSF world. If we were talking about smart 
objects, then we could find such nodes, but not NSFs.

IKE performs two functions:
Authenticate the peers to one another
Exchange keys.

If I understand your proposal correctly, you would like to keep the peers 
exchanging keys (although not directly), but not authenticating. This kind of 
makes sense because the SDN controls identities and credentials. There is no 
meaningful authentication except to verify the credentials provided to the peer 
by the controller.

So I think the proposal makes sense, but I don’t see it as necessary.

Yoav
(again, no hats)

> On 17 Jul 2018, at 6:16, Linda Dunbar  wrote:
> 
> There are two cases proposed by  SDN controlled IPsec Flow Protection:
> -Case 1 is SDN controller only sending down the IPsec configuration 
> attributes to End points, and End Points supports the IKEs and SA maintenance.
> -Case 2 is end points not supporting IKEv2. SDN controller manage all 
> the SA Key computation and distribute to all end nodes. We had an interim 
> meeting discussing this. (see the attached Meeting minutes).
>  
> Question to IPsecme WG: How about something in between? 
> -Assume that SDN controller maintain TLS (or DTLS) to all end points 
> for distributing the IPsec configuration attributes (same as Case 1 above).
> -Instead of using IKEv2 for two end points (E1 & E2) to establish 
> secure channel first for SA negotiation purpose, E1 can utilize the secure 
> channel between E1 <-> SDN-Controller <->E2 to negotiate SA with E2 and 
> responsible for its own SA computation. 
> -E1&E2 still compute SA and maintain SAD. Only utilize the secure 
> channel through the SDN controller to exchange SA.
>  
> This method not only doesn’t require the SDN controller to keep all the SAD 
> for all nodes, but also simplify large SD-WAN deployment with large number of 
> IPsec tunnels among many end points.
>  
> Any opinion? Issues? 
>  
> Linda Dunbar
>  
>   <>
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Yoav Nir
> Sent: Monday, July 16, 2018 3:11 PM
> To: IPsecME WG mailto:ipsec@ietf.org>>
> Subject: [IPsec] IPsec Flow Protection @I2NSF
>  
> Hi.
>  
> I’d like to draw you attention to the agenda of the I2NSF working group: 
> https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 
> <https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00>
>  
> The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
> there is this item which may be of interest to IPsec folks:
>  
> 13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
> In case you haven’t been following, the IPsec flow draft was adopted by 
> I2NSF. The authors are making progress, including open source implementations.
>  
> One issue that may come up in the discussion (either at I2NSF or here) is 
> that other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming 
> up. I’m wondering if these are competing, complementary, or what?
>  
> We’ll be glad to see you all there.
>  
> Yoav
> (co-chair of I2NSF)
>  
> [1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 
> <https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00>
> [2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 
> <https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02>
>  
> 

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

[IPsec] IPsec Flow Protection @I2NSF

[Yoav Nir]

Hi.

I’d like to draw you attention to the agenda of the I2NSF working group: 
https://datatracker.ietf.org/meeting/102/materials/agenda-102-i2nsf-00 


The I2NSF working group will meet on Wednesday after lunch. On the agenda, 
there is this item which may be of interest to IPsec folks:

13:45-14:00 IPsec Flow Protection (15 min): Rafa Marín-López
In case you haven’t been following, the IPsec flow draft was adopted by I2NSF. 
The authors are making progress, including open source implementations.

One issue that may come up in the discussion (either at I2NSF or here) is that 
other drafts about controlling IPsec VPNs with SDN ([1],[2]) are coming up. I’m 
wondering if these are competing, complementary, or what?

We’ll be glad to see you all there.

Yoav
(co-chair of I2NSF)

[1] https://tools.ietf.org/html/draft-carrel-ipsecme-controller-ike-00 

[2] https://tools.ietf.org/html/draft-dunbar-sr-sdwan-over-hybrid-networks-02 


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

Re: [IPsec] INITIAL_CONTACT in IKEv1

[Yoav Nir]

I think at a minimum we have to have the behavior well-defined rather than open 
to interpretation. That IMO is the most important thing we got in IKEv2.

As long as some IKE SA exists between PEER-A and PEER-B, the peer that does not 
have the IPsec SA can inform the other side with an INVALID_SPI protected 
notification. But I agree it’s better to not get into this situation by wiping 
out the IPsec SAs with the IKE SA. Like we do in IKEv2.

> On 14 Jun 2018, at 19:03, riyaz talikoti  wrote:
> 
> Hi Yoav,
> Thanks a lot for the response.
> Just a quick question on top of what you wrote.
> 
> If a responder did not delete IPSec SA’s and only deletes IKE SA when it 
> receives IC.
> Will it not result in blackhole?
> 
> Lets say
> PEER-A ——— — — PEER-B
> IKE SA(XX) IKE SA(XX)
> IPSEC SA(SPI AA)   IPSEC SA(SPI AA)
> 
> PEER-A starts initiating new session and starts AGGRESSIVE_MODE.
> PEER-B receives IC and lets say PEER-B deletes ONLY IKE SA(XX)(recommended by 
> RFC),
> But will NOT delete IPSEC SA(SPI AA)(as RFC does not mention anything about 
> it).
> 
> And AM and QM exchanges gets completed and new sets of SA’s comes UP on both 
> sides
> 
> Now
> PEER-A ——— — — PEER-B
> IKE SA(YY)  IKE SA(YY)
> IPSEC SA(SPI BB)   IPSEC SA(SPI BB)
> IPSEC SA(SPI AA) —> NOT 
> DELETED When IC is received.
> 
> For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it NOT 
> get dropped at PEER-A with INVALID_SPI.
> So does it not make sense to delete all IPSec SA’s when IC is received.
> 
> Regards
> Riyaz
> 
> 
> 
>> On 12-Jun-2018, at 10:34 PM, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> 
>>> On 12 Jun 2018, at 11:53, riyaz talikoti >> <mailto:riyazin...@gmail.com>> wrote:
>>> 
>>> Hi All,
>>> Need help with couple of questions related to INITIAL_CONTACT in IKEv1
>>> 
>>> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE?
>>> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being 
>>> created as part of just completed AGGRESSIVE MODE exchange?
>>> If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder 
>>> should we ignore the notification?
>>> 
>>> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to 
>>> delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE 
>>> SA(Phase 1 SA) ?
>>> Because the whole purpose is to inform responder to delete all previous 
>>> connection related to this identity as initiator is coming UP freshly.
>>> 
>> 
>> Hi, Riyaz
>> 
>> INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407.  It does not 
>> specify that this notification should only be sent in phase 1 messages, 
>> although I agree that it makes little sense in the context of QUICK MODE.
>> 
>> So the answer to #1 is that it is not wrong.
>> 
>> The meaning of this notification is that all IKE SAs except the one being 
>> used or created in this negotiation is not known to the sender. RFC 2407 
>> unfortunately talks only of an “SA” without specifying whether this is about 
>> an IKE SA or an IPsec SA. I think the only sane interpretation is that this 
>> is about IKE SAs. So if an AGGRESSIVE negotiation created an IKE SA and this 
>> IKE SA is used to protect the QUICK MODE, that IKE SA is safe. If the 
>> AGGRESSIVE negotiation was used to create a different IKE SA, then it will 
>> be deleted.
>> 
>> You are always allowed to ignore an INITIAL_CONTACT notification. It is 
>> meant to help you with state management.  If you use some other IKE SA 
>> created before you received the INITIAL_CONTACT, you are very likely to get 
>> an error.
>> 
>> Regarding question #2: To clarify, on receiving INITIAL_CONTACT you delete 
>> all the other IKE SAs, not the one used in the negotiation.
>> The question of deleting the associated IPsec SAs when deleting an IKE SA 
>> is, unfortunately, not answered in the IKEv1 RFCs. Most vendors followed 
>> Cisco’s example and deleted them. A few didn’t.  In the case of 
>> INITIAL-CONTACT it makes even more sense than when an IKE SA is explicitly 
>> deleted with a DELETE payload.
>> 
>> HTH
>> 
>> Yoav
>> 
> 



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

Re: [IPsec] INITIAL_CONTACT in IKEv1

[Yoav Nir]

> On 12 Jun 2018, at 11:53, riyaz talikoti  wrote:
> 
> Hi All,
> Need help with couple of questions related to INITIAL_CONTACT in IKEv1
> 
> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE?
> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created 
> as part of just completed AGGRESSIVE MODE exchange?
> If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder 
> should we ignore the notification?
> 
> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to 
> delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE 
> SA(Phase 1 SA) ?
> Because the whole purpose is to inform responder to delete all previous 
> connection related to this identity as initiator is coming UP freshly.
> 

Hi, Riyaz

INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407.  It does not specify 
that this notification should only be sent in phase 1 messages, although I 
agree that it makes little sense in the context of QUICK MODE.

So the answer to #1 is that it is not wrong.

The meaning of this notification is that all IKE SAs except the one being used 
or created in this negotiation is not known to the sender. RFC 2407 
unfortunately talks only of an “SA” without specifying whether this is about an 
IKE SA or an IPsec SA. I think the only sane interpretation is that this is 
about IKE SAs. So if an AGGRESSIVE negotiation created an IKE SA and this IKE 
SA is used to protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE 
negotiation was used to create a different IKE SA, then it will be deleted.

You are always allowed to ignore an INITIAL_CONTACT notification. It is meant 
to help you with state management.  If you use some other IKE SA created before 
you received the INITIAL_CONTACT, you are very likely to get an error.

Regarding question #2: To clarify, on receiving INITIAL_CONTACT you delete all 
the other IKE SAs, not the one used in the negotiation.
The question of deleting the associated IPsec SAs when deleting an IKE SA is, 
unfortunately, not answered in the IKEv1 RFCs. Most vendors followed Cisco’s 
example and deleted them. A few didn’t.  In the case of INITIAL-CONTACT it 
makes even more sense than when an IKE SA is explicitly deleted with a DELETE 
payload.

HTH

Yoav



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

Re: [websec] Regarding RFC 6797

[Yoav Nir]

> On 4 May 2018, at 23:11, Robert Linder  wrote:
> 
> Hi,
> 
> I would like to propose the addition of the ”immutable” directive (similar to 
> that of RFC 8246) for the HSTS header field (RFC 6797).

Immutable meaning that the HSTS header is permanent and can never be removed?  
So if a user agent has seen an immutable HSTS header once, that site has to be 
(valid) HTTPS-only forever?

Interesting idea.

Anyway, the WebSec working group has been closed for several years now.  If you 
would like to extend HSTS, you should submit an individual draft (something 
with a name like draft-linder-hsts-immutable-00).

You can then discuss the draft either here or in the secdispatch mailing list 
(more technical discussion goes here; procedural discussion goes there).

You can also ask to present your draft at the meeting of the SecDispatch 
working group at the next IETF meeting (this July in Montreal, or the one after 
that: November in Bangkok). The purpose of the SecDispatch working group is to 
recommend what to do with new drafts - either spin up a new working group, or 
find an existing working group to work on this, or ask an Area Director to 
sponsor the draft as an individual submission.

Hope this helps

Yoav
(former co-chair of WebSec)


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

Re: [I2nsf] WG Adoption call for draft-hares-i2nsf-capability-data-model-07

[Yoav Nir]

Thanks to all who replied. 

The response was overwhelmingly positive, so we judge that there is consensus 
for adoption.

Standard question for draft authors: Are you all willing to continue editing 
this document?  We will assume the answer is yes; please reply to the list or 
to the chairs privately otherwise.

Assuming you all are still on-board, please resubmit the latest version as 
draft-ietf-i2nsf-capability-data-model-00.

Thank you for the effort

Linda & Yoav

> On 7 Apr 2018, at 1:20, Linda Dunbar  wrote:
> 
>  
> The authors of I2NSF capability YANG Data Model 
> https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-data-model/ 
>  
> have requested working group adoption of this draft.  The Capability data 
> model is one of the deliverables of I2NSF WG, which is used by Registration 
> interface and NSF interface.
>  
> Please bear in mind that WG Adoption doesn’t mean that the draft current 
> content is ready, WG Adoption only means that it is a good basis for a 
> working group to work on..
>  
> While all feedback is helpful, comments pro or con with explanations are much 
> more helpful than just "yes please" or "no thank you".
>  
> Thank you. 
>  
> Linda & Yoav
>  
> ___
> I2nsf mailing list
> I2nsf@ietf.org 
> https://www.ietf.org/mailman/listinfo/i2nsf 
> 
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [Acme] Question about finalizing an order

[Yoav Nir]

The thing is, the comments came in before IETF LC started (minutes before, but 
still…)

And IETF LC is 4 weeks because it’s assumed that people will be too busy this 
week having just come back to work from IETF week.  So I’d rather any changes 
that we know are happening should be published before the directorates get 
started on their reviews.

Yoav

> On 27 Mar 2018, at 22:09, Richard Barnes  wrote:
> 
> Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft 
> before sending it to the IESG.  Merging PRs is just the modern way of doing 
> accepting LC comments and addressing them before IESG evaluation.
> 
> On Mon, Mar 26, 2018 at 8:00 PM, Daniel McCarney  <mailto:c...@letsencrypt.org>> wrote:
> Richard: Will you take care of whatever this involves?
> 
> 
> On Mon, Mar 26, 2018 at 12:05 PM, Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> Hi
> 
> Since you’re merging stuff, then please submit a new version of the draft 
> ASAP.  We *are* in IETF LC, and we wouldn’t want everyone to read an “old” 
> version of the draft.
> 
> Thanks
> 
> Yoav
> 
> 
>> On 26 Mar 2018, at 17:52, Daniel McCarney > <mailto:c...@letsencrypt.org>> wrote:
>> 
>> PR #417 was merged. This should be resolved now.
>> 
>> Thanks again!
>> 
>> - Daniel / cpu
>> 
>> On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney > <mailto:c...@letsencrypt.org>> wrote:
>> Hi Ning,
>> 
>> It seems that the second statement makes more sense, by changing the 
>> “pending” into “ready” in the first statement.
>> 
>> Agreed, this was an oversight in 
>> https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e
>>  
>> <https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e>.
>> 
>> I opened a pull request to implement this fix 
>> https://github.com/ietf-wg-acme/acme/pull/417 
>> <https://github.com/ietf-wg-acme/acme/pull/417>
>> 
>> Additionally, should the “finalize” URL be made optional in Section 7.1.3, 
>> and returned only if the order status is transitioned to “ready”?
>> 
>> My preference here is no. This would introduce two ways to check for the 
>> same thing: whether an order is ready. One by checking the status == "ready" 
>> and one by checking if there is a finalizationURL. I think this will 
>> complicate things without any strong benefits.
>> 
>> Thanks for catching another spec error! :-)
>> 
>> - Daniel / cpu
>> 
>> 
>> On Thu, Mar 22, 2018 at 4:10 PM, Zhang, Ning > <mailto:Ning.Zhang@team.neustar>> wrote:
>> In Section 7.4, the following two statements seem to in conflict with each 
>> other:
>> 
>> 
>> 
>> A request to finalize an order will result in error if the order indicated 
>> does not have status “pending”, if the CSR and order identifiers differ, or 
>> if the account is not authorized for the identifiers indicated in the CSR.
>> 
>> …
>> 
>> "ready": The server agrees that the requirements have been fulfilled, and is 
>> awaiting finalization.  Submit a finalization request.
>> 
>> 
>> 
>> It seems that the second statement makes more sense, by changing the 
>> “pending” into “ready” in the first statement.
>> 
>> 
>> 
>> Additionally, should the “finalize” URL be made optional in Section 7.1.3, 
>> and returned only if the order status is transitioned to “ready”?
>> 
>> 
>> 
>> Thanks,
>> 
>> -Ning
>> 
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org <mailto:Acme@ietf.org>
>> https://www.ietf.org/mailman/listinfo/acme 
>> <https://www.ietf.org/mailman/listinfo/acme>
>> 
>> 
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org <mailto:Acme@ietf.org>
>> https://www.ietf.org/mailman/listinfo/acme 
>> <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> 



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

Re: [Acme] Question about finalizing an order

[Yoav Nir]

Hi

Since you’re merging stuff, then please submit a new version of the draft ASAP. 
 We *are* in IETF LC, and we wouldn’t want everyone to read an “old” version of 
the draft.

Thanks

Yoav

> On 26 Mar 2018, at 17:52, Daniel McCarney  wrote:
> 
> PR #417 was merged. This should be resolved now.
> 
> Thanks again!
> 
> - Daniel / cpu
> 
> On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney  > wrote:
> Hi Ning,
> 
> It seems that the second statement makes more sense, by changing the 
> “pending” into “ready” in the first statement.
> 
> Agreed, this was an oversight in 
> https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e
>  
> .
> 
> I opened a pull request to implement this fix 
> https://github.com/ietf-wg-acme/acme/pull/417 
> 
> 
> Additionally, should the “finalize” URL be made optional in Section 7.1.3, 
> and returned only if the order status is transitioned to “ready”?
> 
> My preference here is no. This would introduce two ways to check for the same 
> thing: whether an order is ready. One by checking the status == "ready" and 
> one by checking if there is a finalizationURL. I think this will complicate 
> things without any strong benefits.
> 
> Thanks for catching another spec error! :-)
> 
> - Daniel / cpu
> 
> 
> On Thu, Mar 22, 2018 at 4:10 PM, Zhang, Ning  > wrote:
> In Section 7.4, the following two statements seem to in conflict with each 
> other:
> 
> 
> 
> A request to finalize an order will result in error if the order indicated 
> does not have status “pending”, if the CSR and order identifiers differ, or 
> if the account is not authorized for the identifiers indicated in the CSR.
> 
> …
> 
> "ready": The server agrees that the requirements have been fulfilled, and is 
> awaiting finalization.  Submit a finalization request.
> 
> 
> 
> It seems that the second statement makes more sense, by changing the 
> “pending” into “ready” in the first statement.
> 
> 
> 
> Additionally, should the “finalize” URL be made optional in Section 7.1.3, 
> and returned only if the order status is transitioned to “ready”?
> 
> 
> 
> Thanks,
> 
> -Ning
> 
> 
> ___
> 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



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

Re: [IPsec] Clarification on my comments during the WG about possible KE payloads > 64k

[Yoav Nir]

Hi, Scott.

That was me. When they started talking about about PQC a decade ago, they 
mentioned algorithms like McEliece with public keys around 1MB.

Not that this is a deal-killer. If necessary, we would come up with an IKE 
extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE over TCP 
(RFC 8229) can handle this easily.

But anyway, since the current state of the art seems to not need such an 
extension, I guess there’s no point it bringing this up now.

Yoav

> On 25 Mar 2018, at 20:36, Scott Fluhrer (sfluhrer)  wrote:
> 
> During the WG meeting in London, somebody (I forget who) asked me whether KE 
> payloads larger than 64k.  I thought I ought to clarify matters (as they are 
> more complex than the brief answer I gave indicated).
> 
> Of the proposed postquantum key exchange (and public key encryption 
> algorithms, which can be used to transport keys) submitted to NIST, the 
> majority of them have key shares (or public keys/ciphertexts) smaller than 
> 64k; there are a handful that are larger.  Now, it is possible (albeit 
> unlikely) that all the algorithms with key shares < 64k will be broken; 
> unless this happens, it would be reasonable (IMHO) that we mandate that any 
> algorithm he allow have a KE payload that fits within 64k.  Now, in the event 
> that we feel the need to support larger key shares, there are possible ways 
> to support that; I don’t feel that we need to talk about those options now.
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 


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

[Acme] Wednesday meeting - minutes uploaded

[Yoav Nir]

Thanks to PHB for taking the minutes

https://datatracker.ietf.org/meeting/101/materials/minutes-101-acme-00 


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

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

Hi, Daniel

Inline...

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

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

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

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

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

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

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



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

[Acme] Reminder: Send in your slides

[Yoav Nir]

Hi

If you’re presenting at the ACME session on Wednesday afternoon, please send in 
your slides.

https://datatracker.ietf.org/meeting/101/materials/agenda-101-acme-00 


If you only need to report on the status of your document, let us know and we 
can insert it as one slide in the chairs’ deck.

Thanks and see you all on Wednesday.

Rich and Yoav



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

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

[Yoav Nir]

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

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

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



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


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

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

[Yoav Nir]

IIUC not quite. There is an API, so the application that uses the library can 
get the keys. The application can then save it to a file, send it to a central 
repository, send it to the government, or whatever else it might want to do.

There is no built-in setting where OpenSSL writes the keys to a file, nor do 
applications such as web servers do this AFAIK.

It should not be difficult to write, but is not provided in off-the-shelf 
software.

Making the library send this in-band in some protocol extension is a far bigger 
endeavor. It’s also a dangerous switch to leave lying around.

> On 16 Mar 2018, at 0:16, Richard Barnes  wrote:
> 
> Just to confirm that I understand the scope of the discussion here:
> 
> - TLS libraries have facilities to export keys from the library
> - Obviously, it's possible to ship these exported keys elsewhere (`tail -f 
> $SSLKEYLOGFILE | nc $LOGBOX`)
> 
> So all we're really talking about is whether to define a way to do the 
> shipment of the exported keys in-band to the TLS session.
> 
> 
> On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich  > wrote:
> This is what OpenSSL provides:
> 
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
> 



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

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

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

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




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

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

[Yoav Nir]

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

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


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



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

Re: [TLS] Breaking into TLS to protect customers

[Yoav Nir]

Hi, Rich.

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

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

Yoav

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


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

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

[Yoav Nir]

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

None of these libraries support any of this functionality.

> On 15 Mar 2018, at 2:16, Watson Ladd  wrote:
> 
> One can either use a static DH share, save the ephemerals on the
> servers and export them, or log all the data on the servers.
> 
> These options don't require any change to the wire protocol: they just
> require vendors supporting them. Why don't they meet the needs cited?
> 
> Sincerely,
> Watson
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [I2nsf] Calling for IETF101 I2NSF WG session agenda request. If you need remote presentations, please let us know as soon as possible

[Yoav Nir]

Hi, Paul

That’s a total of 75 minutes, 70 of them for various drafts. So what is the 
intent here?

Last time we had a whole bunch of presentations that were pretty much a primer 
on what this draft is about. Working group sessions are supposed to be about 
discussion, and the attendees are assumed (perhaps naïvely) to have read the 
drafts.  I don’t want another round of primers. If the point is a status 
update, we can make an 8-slide deck with a quick status for each draft and run 
through that in 10-15 minutes.

Can you give me an outline of what things are to be discussed?

Thanks

Linda and Yoav

> On 8 Mar 2018, at 8:22, Mr. Jaehoon Paul Jeong  wrote:
> 
> Hi Linda and Yoav,
> I would like to request timeslots for IETF-101 I2NSF WG Session as below:
> 
> 1. IETF-101 Hackathon I2NSF Project
>  - Presenter: Jaehoon Paul Jeong
>  - Time: 5 min
> 
> 2. Applicability of Interfaces to Network Security Functions to Network-Based 
> Security Services
>  - draft-ietf-i2nsf-applicability-02
>  - Presenter: Jaehoon Paul Jeong
>  - Time: 10 min
> 
> 3. I2NSF Consumer-Facing Interface YANG Data Model
>  - draft-ietf-i2nsf-consumer-facing-interface-dm-00
>  - Presenter: Jaehoon Paul Jeong
>  - Time: 10 min
> 
> 4. I2NSF Network Security Function-Facing Interface YANG Data Model
>  - draft-ietf-i2nsf-nsf-facing-interface-dm-00
>  - Presenter: Jinyong Tim Kim
>  - Time: 10 min
> 
> 5. I2NSF Capability YANG Data Model
>  - draft-hares-i2nsf-capability-data-model-06
>  - Presenter: Jinyong Tim Kim
>  - Time: 10 min
> 
> 6. YANG Data Model for Monitoring I2NSF Network Security Functions
>  - draft-hong-i2nsf-nsf-monitoring-data-model-02
>  - Presenter: Jaehoon Paul Jeong (or Henk Birkholz)
>  - Time: 10 min
> 
> 7. I2NSF Registration Interface Information Model and YANG Data Model
>  - draft-hyun-i2nsf-registration-interface-im-04
>  - draft-hyun-i2nsf-registration-interface-dm-03
>  - Presenter: Jaehoon Paul Jeong
>  - Time: 10 min
> 
> 8. Service Function Chaining-Enabled I2NSF Architecture
>  - draft-hyun-i2nsf-nsf-triggered-steering-05
>  - Presenter: Jaehoon Paul Jeong
>  - Time: 10 min
> 
> Thanks for your coordination.
> 
> Best Regards,
> Paul
> --
> ===
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957
> Email: jaehoon.p...@gmail.com , 
> paulje...@skku.edu 
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
> 
> 
> On Wed, Feb 28, 2018 at 2:52 AM, Linda Dunbar  > wrote:
> I2NSF WG session will be Wed march 21 9:30am~12pm.
> 
> Please let us know if you need presentation slot, and how long is your 
> presentation.
> 
> If you need remote presentation, please let us know as soon as possible.
> 
> 
> 
> Thanks, Linda & Yoav
> 
> 
> -Original Message-
> From: WGChairs [mailto:wgchairs-boun...@ietf.org 
> ] On Behalf Of Meetecho IETF support
> Sent: Monday, February 26, 2018 9:27 AM
> To: wgcha...@ietf.org 
> Subject: Cutoff date for requesting remote presentations support at IETF101
> 
> Dear chairs,
> 
> as usual, please book your remote *presentation* slots at IETF101 by filling 
> out the following form:
> 
> https://ietf101.conf.meetecho.com/index.php/Remote_presentations 
> 
> 
> *The cutoff date is March 16, 2018.*
> 
> You can also check scheduled remote presentations here:
> 
> https://ietf101.conf.meetecho.com/list.php 
> 
> 
> Thanks,
> the Meetecho team
> 
> 
> 
> 
> ___
> I2nsf mailing list
> I2nsf@ietf.org 
> https://www.ietf.org/mailman/listinfo/i2nsf 
> 
> 
> 



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

Re: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5

[Yoav Nir]

This is how I understand it:


> On 1 Mar 2018, at 13:59, Svensson, Lars  wrote:
> 
> When implementing HSTS, my colleagues and I had discussions on how to 
> correctly interpret §8.3, #5 of RFC 6797 [1]. In our opinion the text is 
> ambiguous and we hope that you can help us to clarify what is the proper 
> reading of that section. In §8.3 #5 the following is stated:
> 
> [[
> If, when performing domain name matching any superdomain match
>   with an asserted includeSubDomains directive is found, or, if no
>   superdomain matches with asserted includeSubDomains directives
>   are found and a congruent match is found (with or without an
>   asserted includeSubDomains directive), then before proceeding
>   with the load:
> 
>  The UA MUST replace the URI scheme with "https" [RFC2818], and
> 
>  if the URI contains an explicit port component of "80", then
>  the UA MUST convert the port component to be "443", or
> 
>  if the URI contains an explicit port component that is not
>  equal to "80", the port component value MUST be preserved;
>  otherwise,
> 
>  if the URI does not contain an explicit port component, the UA
>  MUST NOT add one.
> 
>  NOTE:  These steps ensure that the HSTS Policy applies to HTTP
> over any TCP port of an HSTS Host.
> 
>   NOTE:  In the case where an explicit port is provided (and to a
>  lesser extent with subdomains), it is reasonably likely that
>  there is actually an HTTP (i.e., non-secure) server running on
>  the specified port and that an HTTPS request will thus fail
>  (see item 6 in Appendix A ("Design Decision Notes")).
> ]]
> 
> The question is how to interpret the "and" and "or" connections between the 
> paragraphs. One possibility is to use arithmetic ordering ("and" before 
> "or"), another to collect all "or" statements into one expression and then 
> apply the "and". In the first case we arrive at:
> 
>  The UA MUST replace the URI scheme with "https" [RFC2818], and
> 
>   (
>  if the URI contains an explicit port component of "80", then
>  the UA MUST convert the port component to be "443", or
> 
>  if the URI contains an explicit port component that is not
>  equal to "80", the port component value MUST be preserved;
>  otherwise,
> 
>  if the URI does not contain an explicit port component, the UA
>  MUST NOT add one.
>   )
> 
> That is, the UA _always_ has to replace the URI scheme with https and then 
> will continue to handle the port component. In pseudocode this would be:
> 
> If( Scheme = "http" ) {
>   Replace scheme with "https"
>   If ( URI contains explicit port "80" ) {
>   Replace port with "443" ;
>   } ElseIf( URI contains explicit port ) {
>   Keep explicit port ;
>   } Else {
>   Do not add explicit port ;  
>   }
> }
> 
> 
> In the second case the reading would be:
> 
>   (
>  The UA MUST replace the URI scheme with "https" [RFC2818], and
> 
>  if the URI contains an explicit port component of "80", then
>  the UA MUST convert the port component to be "443", or
>   )
> 
>  if the URI contains an explicit port component that is not
>  equal to "80", the port component value MUST be preserved;
> 
>   # The otherwise starts a new scope so we repeat the first clause:
> 
>  otherwise,
> 
>   (   
>  The UA MUST replace the URI scheme with "https" [RFC2818], and
> 
>  if the URI does not contain an explicit port component, the UA
>  MUST NOT add one.
>   )
> 
> That is, the UA must change the schema to https _only then_ when the port is 
> explicitly "80" (and then convert the port to 443) or when there is no port.
> 
> In pseudocode:
> 
> If ( Scheme = "http" ) {
>   If ( URI contains no port ) {
>   Replace URI scheme with https ;
>   } ElseIf ( URI contains port "80" ) {
>   Replace URI scheme with "https" ;
>   Replace port with "443" ;
>   } Else {
>   /* don't touch this, do nothing */
>   }
> 
> }
> 
> This way it's possible to run internal http-based services (e. g. behind a 
> firewall) on other ports than 80 without having to upgrade those to https.
> 
> But if the UA acts like described first, then it will try to upgrade to https 
> on any other port but 80, too. 
> As a consequence, you then will have to offer all "real" services on other 
> port with https - with the exception of a "https-bumper" on 80.
> 
> [1] https://tools.ietf.org/html/rfc6797#section-8.3
> 
> Thanks for any insight,
> 
> Lars
> 
> 
> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
> -- 
> Dr. Lars G. Svensson
> Deutsche Nationalbibliothek
> Informationsinfrastruktur
> Adickesallee 1
> 60322 Frankfurt am Main
> Telefon: +49 69 1525

Re: [Acme] acme - Requested session has been scheduled for IETF 101

[Yoav Nir]

Hi, folks

So we are going to have a 1.5 hour session in London.

Anyone who needs agenda time, please send a note to Rich and me.

Hope to see you all there.

Yoav

> On 28 Feb 2018, at 1:11, 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. 
> 
> acme Session 1 (1:30:00)
>Wednesday, Afternoon Session II 1520-1650
>Room Name: Buckingham size: 175
>-
> 
> 
> 
> Request Information:
> 
> 
> -
> Working Group Name: Automated Certificate Management Environment
> Area Name: Security Area
> Session Requester: Yoav Nir
> 
> Number of Sessions: 1
> Length of Session(s):  1.5 Hours
> Number of Attendees: 70
> Conflicts to Avoid: 
> First Priority: i2nsf curdle dcrup saag ipsecme
> Second Priority: tls cfrg
> 
> 
> 
> People who must be present:
>  Rich Salz
>  Kathleen Moriarty
>  Yoav Nir
>  Richard Barnes
> 
> Resources Requested:
> 
> Special Requests:
> 
> -
> 

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

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

[Yoav Nir]

Thanks.

Yoav

(and this goes for the other thread too)

> On 20 Feb 2018, at 3:42, Mr. Jaehoon Paul Jeong  
> wrote:
> 
> Hi Yoav,
> We authors will address the comments on the new WG document
> on NSF-Facing Interface Data Model and submit it before the I-D due.
> 
> Thanks.
> 
> Best Regards,
> Paul
> 
> 
> On Fri, Feb 16, 2018 at 4:14 AM, Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> Thanks to all who participated.
> 
> We believe that there is rough consensus to adopt this document as a starting 
> point for the group to work on.
> 
> Authors, please resubmit this document as a working group document with the 
> name draft-ietf-i2nsf-nsf-facing-interface-dm-00.
> 
> Yoav
> (on behalf of the WG chairs)
> 
> 
>> On 27 Jan 2018, at 1:21, Linda Dunbar > <mailto:linda.dun...@huawei.com>> wrote:
>> 
>> 
>> The authors of I2NSF Network Security Functions-Facing Interface YANG Data 
>> Model
>> https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04
>>  
>> <https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04>
>> 
>> Have requested working group adoption of this draft.
>> 
>> Please bear in mind that WG Adoption doesn’t mean that the draft current 
>> content is ready, WG Adoption only means that it is a good basis for a 
>> working group to work on.
>> 
>> While all feedback is helpful, comments pro or con with explanations are 
>> much more helpful than just "yes please" or "no thank you".
>> 
>> Thank you.
>> 
>> Linda & Yoav
>> 
>> ___
>> I2nsf mailing list
>> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2nsf 
>> <https://www.ietf.org/mailman/listinfo/i2nsf>
> 
> ___
> I2nsf mailing list
> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
> https://www.ietf.org/mailman/listinfo/i2nsf 
> <https://www.ietf.org/mailman/listinfo/i2nsf>
> 
> 
> 
> 
> --
> ===
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software
> Sungkyunkwan University
> Office: +82-31-299-4957
> Email: jaehoon.p...@gmail.com <mailto:jaehoon.p...@gmail.com>, 
> paulje...@skku.edu <mailto:paulje...@skku.edu>
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php 
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>



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

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

[Yoav Nir]

> On 16 Feb 2018, at 21:09, Tero Kivinen  wrote:
> 
> Yoav Nir writes:
>>> 2) The privacy of the initiator's identity in the presence of a man in
>>>  the middle attacker is not protected.
>>> 
>>>   Today an attacker with full control of the network can receive the
>>>   IDi/IDr sent by the initiator in the first AUTH packet. We should
>>>   add a mechanism to IKEv2 that allows the initiator to only send
>>>   IDi/IDr to known entities (e.g. that possess a shared secret).
>> 
>> This is more feasible. I understand the issue, but the only use case
>> where I think it’s important is remote access. It would make sense
>> in remote access to reverse the order of authentication so that the
>> responder identifies and authenticates first, but you’d still need
>> the initiator to send the IDr first.
> 
> The reason why we defined IKEv2 so that initiator provides identity
> first, was that if responder provides identity first, then attackers
> can make probe attacks and collect identities of the remote peers,
> even when the IPsec is not currently in use. I.e., like we might run
> nmap to find out the open ports, this would also provide authenticated
> (if using certificateS) identity of the peer…

I realize this, but one side has to identify itself first, and with remote 
access I think it’s more important to protect the initiator identity than to 
protect that fact that some organization has an IPsec remote access 
concentrator.

In fact we can run nmap and find which ports are open, and we can and do scan 
for HTTP(S) servers on ports 80 and 443, and we do get their certificates.


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

Re: [IPsec] Additional charter items 4/4: Mitigating privacy concerns

[Yoav Nir]

> On 16 Feb 2018, at 20:13, Tero Kivinen  wrote:
> 
> This item does not have charter text yet, we do have text which
> explains what the problem is, but I think it requires some
> reformatting to fit as charter text.
> 
> The problem description is:
> 
> --
> 
> IKEv2 is currently vulnerable to the two following privacy concerns:
> 
> 1) It's not possible to run a server that obfuscates IKEv2/IPsec using
>   TLS.
> 
>Today thanks to RFC 8229 it is possible to run an IKEv2/IPsec
>server on TCP port 443 with TLS. However if a government agent
>tries to send an SA_INIT over that it will discover that this
>server runs IKEv2/IPsec, and may blacklist it. We should add a
>mechanism to IKEv2 that allows the server to only respond to
>SA_INIT from known entities (e.g. that possess a shared secret).

That would require that within the SA_INIT request, the initiator proves 
possession of a shared secret and does so in a non-replayable way.

Wouldn’t it be better for the initiator to prove identity or group membership 
in the TLS handshake?

> 
> 2) The privacy of the initiator's identity in the presence of a man in
>   the middle attacker is not protected.
> 
>Today an attacker with full control of the network can receive the
>IDi/IDr sent by the initiator in the first AUTH packet. We should
>add a mechanism to IKEv2 that allows the initiator to only send
>IDi/IDr to known entities (e.g. that possess a shared secret).

This is more feasible. I understand the issue, but the only use case where I 
think it’s important is remote access. It would make sense in remote access to 
reverse the order of authentication so that the responder identifies and 
authenticates first, but you’d still need the initiator to send the IDr first.

> --
> 
> Is this something that we should add to charter? Do people understand
> the issue?
> 
> Note, that there are multiple ways of solving these issues, for
> example the 2nd problem can also be solved by using pseudonyms, i.e.,
> sending random one use ID payloads during the IKE_AUTH, and after the
> peers have authenticated each other, they can do new exchange which
> will change the pseudonyms for next use. I think the 2nd option should
> be rewritten in bit more generic ways to allow that kind of option
> too.
> 
> Send your comments and whether you support adding this to the charter
> to the ipsec list in next two weeks.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



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

Re: [IPsec] Additional charter items 3/4: Labeled IPsec

[Yoav Nir]

> On 16 Feb 2018, at 20:06, Tero Kivinen  wrote:
> 
> This charter text was not ready during the IETF 100, we just had very
> short description about the item, and I think most of the people did
> not really understand it.
> 
> The proposed charter text for this item is:
> 
> --
> Some systems support security labels (aka security context) as one of
> the selectors of the SPD. This label needs to be part of the IKE
> negotiation for the IPsec SA. non-standard implementations exist for
> IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now
> using private space IPSEC Security Association Attribute 32001). The
> work is to standarize this for IKEv2.
> --
> 
> Is that charter text clear enough?

Yeah, I think anyone who’s heard of multilevel security understands what is 
proposed here.

> Is there enough people interested
> in this?

I guess, since MLS keeps coming up…

I’m not, but I’m not opposed to doing this as long as there’s no burden on 
non-supporting implementations.

> 
> Send your comments and whether you support adding this to the charter
> to the ipsec list in next two weeks.
> --
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec



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

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04

[Yoav Nir]

Thanks to all who participated.

We believe that there is rough consensus to adopt this document as a starting 
point for the group to work on.

Authors, please resubmit this document as a working group document with the 
name draft-ietf-i2nsf-nsf-facing-interface-dm-00.

Yoav
(on behalf of the WG chairs)


> On 27 Jan 2018, at 1:21, Linda Dunbar  wrote:
> 
>  
> The authors of I2NSF Network Security Functions-Facing Interface YANG Data 
> Model
> https://tools.ietf.org/html/draft-kim-i2nsf-nsf-facing-interface-data-model-04
>  
> 
>  
> Have requested working group adoption of this draft.  
>  
> Please bear in mind that WG Adoption doesn’t mean that the draft current 
> content is ready, WG Adoption only means that it is a good basis for a 
> working group to work on.
>  
> While all feedback is helpful, comments pro or con with explanations are much 
> more helpful than just "yes please" or "no thank you".
>  
> Thank you. 
>  
> Linda & Yoav
>  
> ___
> I2nsf mailing list
> I2nsf@ietf.org 
> https://www.ietf.org/mailman/listinfo/i2nsf 
> 
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [I2nsf] WG Adoption call for https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04

[Yoav Nir]

Thanks to all who participated.

We believe that there is rough consensus to adopt this document as a starting 
point for the group to work on.

Authors, please resubmit this document as a working group document with the 
name draft-ietf-i2nsf-consumer-facing-interface-dm-00.

Yoav
(on behalf of the WG chairs)


> On 27 Jan 2018, at 1:23, Linda Dunbar  wrote:
> 
>  
>  
> The authors of I2NSF Consumer-Facing Interface YANG Data Model
> https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-04 
> 
>  
> Have requested working group adoption of this draft.  
>  
> Please bear in mind that WG Adoption doesn’t mean that the draft current 
> content is ready, WG Adoption only means that it is a good basis for a 
> working group to work on.
>  
> While all feedback is helpful, comments pro or con with explanations are much 
> more helpful than just "yes please" or "no thank you".
>  
> Thank you. 
>  
> Linda & Yoav
>  
> ___
> I2nsf mailing list
> I2nsf@ietf.org 
> https://www.ietf.org/mailman/listinfo/i2nsf 
> 
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

Re: [IPsec] Candidate charter text is now in wiki

[Yoav Nir]

> On 9 Feb 2018, at 18:40, Paul Wouters  wrote:
> 
> On Wed, 7 Feb 2018, Tero Kivinen wrote:
> 
>> It depends. If we do not take the item as official working group
>> chartered item, there are still few different options. You can either
>> get it processed as AD sponsored draft, or you can go individual
>> submission track.
> 
> It is a little strange we don't have an ops group for ipsec. The IPsecME
> group really functions as such.

Are there any work items to add to the charter of this group or a dedicated ops 
group?

I don’t remember any draft about how you’d go about deploying IPsec either in 
VPN or within a datacenter. Certainly not at scale. 

There is the work in I2NSF for the datacenter and there are some “software 
defined WAN” products that use IPsec for VPN, but the latter is not 
standardised.

Yoav

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

Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)

[Yoav Nir]

Sorry. Resending with the correct To: and CC: lists

> On 31 Jan 2018, at 7:04, Yoav Nir  wrote:
> 
> Hi.
> 
> I don’t see anything wrong with the suggestion (it’s just adding “to indicate 
> NONE” in the last sentence). However:
> A value marked “Reserved” in IANA just means that IANA should not assign it. 
> It does not mean that it cannot appear in the protocol.
> Using a zero in a field to indicate no value is common, and IANA registries 
> are inconsistent about whether such zero values are named or just reserved.
> Unless we want to change the IANA registry, there is no reason to uppercase 
> ‘none’
> I don’t think we need to update the IANA registry.
> 
> “Hold for document update”?
> 
>> On 30 Jan 2018, at 23:50, RFC Errata System > <mailto:rfc-edi...@rfc-editor.org>> wrote:
>> 
>> The following errata report has been submitted for RFC7296,
>> "Internet Key Exchange Protocol Version 2 (IKEv2)".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5247 
>> <http://www.rfc-editor.org/errata/eid5247>
>> 
>> --
>> Type: Editorial
>> Reported by: Andrew Cagney 
>> 
>> Section: 3.10.
>> 
>> Original Text
>> -
>>   o  Protocol ID (1 octet) - If this notification concerns an existing
>>  SA whose SPI is given in the SPI field, this field indicates the
>>  type of that SA.  For notifications concerning Child SAs, this
>>  field MUST contain either (2) to indicate AH or (3) to indicate
>>  ESP.  Of the notifications defined in this document, the SPI is
>>  included only with INVALID_SELECTORS, REKEY_SA, and
>>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>>  sent as zero and MUST be ignored on receipt.
>> 
>> Corrected Text
>> --
>>   o  Protocol ID (1 octet) - If this notification concerns an existing
>>  SA whose SPI is given in the SPI field, this field indicates the
>>  type of that SA.  For notifications concerning Child SAs, this
>>  field MUST contain either (2) to indicate AH or (3) to indicate
>>  ESP.  Of the notifications defined in this document, the SPI is
>>  included only with INVALID_SELECTORS, REKEY_SA, and
>>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>>  sent as zero to indicate NONE and MUST be ignored on receipt.
>> 
>> Notes
>> -
>> If I assume that the 'Protocol ID' field in the notification payload is 
>> specified by:
>> 
>>  Internet Key Exchange Version 2 (IKEv2) Parameters
>>  IKEv2 Security Protocol Identifiers
>> 
>> then a notification is using the 'Reserved' value 0.   Since the value is 
>> being used,
>> I think it would be better to give it a name.  Other uses of 'Protocol ID' 
>> don't need
>> updating as they all explicitly list allowed values, and in no case is 0 
>> allowed.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
>> --
>> Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
>> Publication Date: October 2014
>> Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
>> Category: INTERNET STANDARD
>> Source  : IP Security Maintenance and Extensions
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>> 
>> ___
>> 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] [Editorial Errata Reported] RFC7296 (5247)

[Yoav Nir]

Hi.

I don’t see anything wrong with the suggestion (it’s just adding “to indicate 
NONE” in the last sentence). However:
A value marked “Reserved” in IANA just means that IANA should not assign it. It 
does not mean that it cannot appear in the protocol.
Using a zero in a field to indicate no value is common, and IANA registries are 
inconsistent about whether such zero values are named or just reserved.
Unless we want to change the IANA registry, there is no reason to uppercase 
‘none’
I don’t think we need to update the IANA registry.

“Hold for document update”?

> On 30 Jan 2018, at 23:50, RFC Errata System  wrote:
> 
> The following errata report has been submitted for RFC7296,
> "Internet Key Exchange Protocol Version 2 (IKEv2)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5247
> 
> --
> Type: Editorial
> Reported by: Andrew Cagney 
> 
> Section: 3.10.
> 
> Original Text
> -
>   o  Protocol ID (1 octet) - If this notification concerns an existing
>  SA whose SPI is given in the SPI field, this field indicates the
>  type of that SA.  For notifications concerning Child SAs, this
>  field MUST contain either (2) to indicate AH or (3) to indicate
>  ESP.  Of the notifications defined in this document, the SPI is
>  included only with INVALID_SELECTORS, REKEY_SA, and
>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>  sent as zero and MUST be ignored on receipt.
> 
> Corrected Text
> --
>   o  Protocol ID (1 octet) - If this notification concerns an existing
>  SA whose SPI is given in the SPI field, this field indicates the
>  type of that SA.  For notifications concerning Child SAs, this
>  field MUST contain either (2) to indicate AH or (3) to indicate
>  ESP.  Of the notifications defined in this document, the SPI is
>  included only with INVALID_SELECTORS, REKEY_SA, and
>  CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
>  sent as zero to indicate NONE and MUST be ignored on receipt.
> 
> Notes
> -
> If I assume that the 'Protocol ID' field in the notification payload is 
> specified by:
> 
>  Internet Key Exchange Version 2 (IKEv2) Parameters
>  IKEv2 Security Protocol Identifiers
> 
> then a notification is using the 'Reserved' value 0.   Since the value is 
> being used,
> I think it would be better to give it a name.  Other uses of 'Protocol ID' 
> don't need
> updating as they all explicitly list allowed values, and in no case is 0 
> allowed.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
> --
> Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
> Publication Date: October 2014
> Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
> Category: INTERNET STANDARD
> Source  : IP Security Maintenance and Extensions
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] A question for TLS middle-box/middleware vendors/implementers

[Yoav Nir]

Hi, Thomas

Inline

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

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

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

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

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

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

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

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

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

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

Yoav

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

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

[Yoav Nir]

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

Hi, Thomas.

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

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

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

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

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

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

HTH

Yoav

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

Re: [IPsec] Dynamic PMTUD over IKEv2

[Yoav Nir]

> On 23 Jan 2018, at 12:29, Shibu Piriyath  wrote:
> 
> Hi All,
> 
> We have come up with a proposal for discovering Path MTU between IPsec 
> head-ends dynamically using IKEv2 messages.
> Please review the draft - 
> https://tools.ietf.org/html/draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00 
>  
> and let us know your comments,
> 
> Thanks,
> Shibu.

Hi Shibu.

Thank you for working on this.  I have some comments.


Administrative/political: 
This document proposes an IPv4-only mechanism.  While the IETF has not (yet?) 
approved" [1] (see discussion threads [2] and [3]), there needs to be some 
justification for why we’re doing an IPv4-only mechanism.  Is this not a 
problem in IPv6 (Because we assume that PTB responses propagate correctly in 
the IPv6 network that in the IPv4 Internet routers routinely fragment) or is 
there some other mechanism for IPv6?


Terminology:
- I usually encounter the terms ingress and egress for interfaces of a 
particular router or host. I think it would be clearer to use “tunnel ingress” 
and “tunnel egress” or “encryptor” and “decryptor”
- "Overhead is the number of bytes required for tunnel encapsulation”. Overhead 
is then used as a number that is subtracted from physical MTU.  However, the 
overhead is not constant. IPsec requires padding to some multiple of 4, 8, or 
16 depending on the algorithm.  I suggest modifying the definition of overhead 
to “Overhead is the *maximum* number of bytes required for tunnel encapsulation”
- "fragmentation within the tunnel is allowed” - this is about fragmenting an 
ESP packet that is too large. I don’t think “within the tunnel” is the best 
term for this. How about “fragmentation of the ESP packet by intermediate 
routers is allowed” ?




Technical:
If the
   packet length is greater than the tunnel MTU and the packet can be
   fragmented, the ingress node fragments the packet, encapsulates each
   fragment, and forwards each encapsulated fragment through the tunnel.

That’s one way of doing things. Another is to encapsulate the packet anyway and 
send the ESP packet out in fragments. This way is also compatible with IPv6.  I 
know of at least one implementation that does this.


There is an assumption that the egress node knows about the fragmentation. 
Usually some layer in the stack will defragment before handing the IPsec stack 
a re-assembled IPsec packet to decrypt.  Maybe some implementations are more 
integrated and the IPsec stack has this information, but this assumption needs 
to be stated explicitly.


Some routers drop packets that are too big instead of fragmenting them. Of 
these, some send back the PTB and some don’t. An active PMTUD method (ingress 
sends dummy packets of various sizes and receives acknowledgements from egress 
if they arrive) can work with such intermediate routers. This method cannot.


How do you prevent the following attack? The attacker manages to drop or delay 
one ESP packet. It captures this packet and retransmits it in small fragments. 
This induces the egress to send the notification from section 3.2 to the 
ingress, causing it to internally fragment all future packets.

Yoav

[1] https://tools.ietf.org/html/draft-ietf-sunset4-ipv6-ietf-01
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg104661.html
[3] https://www.ietf.org/mail-archive/web/ietf/current/msg104721.html

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

Re: [I2nsf] draft-ietf-i2nsf-sdn-ipsec-flow-protection

[Yoav Nir]

Thanks, Benoit.

Authors: Please change this in your working copy so that we can get it right in 
the next revision (-01)

Something like:
 file "ietf-ip...@2018-01-08.yang”
or
 file "ietf-ip...@2017-10-28.yang"

It’s also fine to make the date earlier if you remember when you made this up.

Thanks

Yoav

> On 8 Jan 2018, at 15:35, Benoit Claise  wrote:
> 
> Hi, 
> 
> You're missing a revision in:
> 
>  file "ietf-ipsec.yang"
> 
> 
> See https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ 
> 
> 
> Regards, Benoit

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

Re: [Acme] YA WGLC for draft-ietf-acme-acme

[Yoav Nir]

I meant the one titled “Challenge objects are provoking implementation mistakes”

If there are other threads that are still open, then obviously let’s get them 
closed before submitting the next draft. 

> On 2 Jan 2018, at 21:52, Daniel McCarney  wrote:
> 
> Hi Yoav,
> 
> There are a few threads on the go from Sophie. Is there one in particular you 
> mean to reference here? Both?
> 
> Thanks!
> 
> 
> On Wed, Dec 27, 2017 at 2:15 PM, Yoav Nir  <mailto:ynir.i...@gmail.com>> wrote:
> I take that back.  Solve Sophie’s issue (from the other thread) first, and 
> then publish a new draft.
> 
> 
>> On 27 Dec 2017, at 6:46, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> Thank you for all who participated.
>> 
>> There have been two editorial changes suggested and accepted in the GitHub 
>> repository. As soon as a new draft is published, I think we can progress 
>> this.
>> 
>> Thanks again.
>> 
>> Yoav
>> 
>>> On 14 Dec 2017, at 19:28, Yoav Nir >> <mailto:ynir.i...@gmail.com>> wrote:
>>> 
>>> Hi
>>> 
>>> Draft-09 is now available and has (IMO) addressed all or the outstanding 
>>> issues.
>>> 
>>> This starts an abbreviated WGLC for this draft. Please review the draft and 
>>> send in your comments by EOD Monday the 25th. Please note that Monday the 
>>> 25th is Christmas day, so don’t delay - send in your comments sooner rather 
>>> than later.
>>> 
>>> If all goes well, we can go to IETF LC in early January and have this in 
>>> the RFC Editor queue before the London meeting.
>>> 
>>> Yoav
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>>>> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
>>>> Date: 14 December 2017 at 16:14:02 GMT+2
>>>> To: mailto:i-d-annou...@ietf.org>>
>>>> Cc: acme@ietf.org <mailto:acme@ietf.org>
>>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>> This draft is a work item of the Automated Certificate Management 
>>>> Environment WG of the IETF.
>>>> 
>>>>Title   : Automatic Certificate Management Environment 
>>>> (ACME)
>>>>Authors : Richard Barnes
>>>>  Jacob Hoffman-Andrews
>>>>  Daniel McCarney
>>>>  James Kasten
>>>>Filename: draft-ietf-acme-acme-09.txt
>>>>Pages   : 80
>>>>Date: 2017-12-14
>>>> 
>>>> Abstract:
>>>>   Certificates in PKI using X.509 (PKIX) are used for a number of
>>>>   purposes, the most significant of which is the authentication of
>>>>   domain names.  Thus, certificate authorities in the Web PKI are
>>>>   trusted to verify that an applicant for a certificate legitimately
>>>>   represents the domain name(s) in the certificate.  Today, this
>>>>   verification is done through a collection of ad hoc mechanisms.  This
>>>>   document describes a protocol that a certification authority (CA) and
>>>>   an applicant can use to automate the process of verification and
>>>>   certificate issuance.  The protocol also provides facilities for
>>>>   other certificate management functions, such as certificate
>>>>   revocation.
>>>> 
>>>>   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>>>>   this draft is maintained in GitHub.  Suggested changes should be
>>>>   submitted as pull requests at https://github.com/ietf-wg-acme/acme 
>>>> <https://github.com/ietf-wg-acme/acme>
>>>>   [1].  Instructions are on that page as well.  Editorial changes can
>>>>   be managed in GitHub, but any substantive change should be discussed
>>>>   on the ACME mailing list (acme@ietf.org <mailto:acme@ietf.org>).
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ 
>>>> <https://datatracker.ietf.org/doc/draft-ietf-acme-acme/>
>>>> 
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-acme-a

Re: [TLS] TLS 1.3 : small fragments attack

[Yoav Nir]

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

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

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

Yoav

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

Re: [Acme] YA WGLC for draft-ietf-acme-acme

[Yoav Nir]

I take that back.  Solve Sophie’s issue (from the other thread) first, and then 
publish a new draft.

> On 27 Dec 2017, at 6:46, Yoav Nir  wrote:
> 
> Thank you for all who participated.
> 
> There have been two editorial changes suggested and accepted in the GitHub 
> repository. As soon as a new draft is published, I think we can progress this.
> 
> Thanks again.
> 
> Yoav
> 
>> On 14 Dec 2017, at 19:28, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote:
>> 
>> Hi
>> 
>> Draft-09 is now available and has (IMO) addressed all or the outstanding 
>> issues.
>> 
>> This starts an abbreviated WGLC for this draft. Please review the draft and 
>> send in your comments by EOD Monday the 25th. Please note that Monday the 
>> 25th is Christmas day, so don’t delay - send in your comments sooner rather 
>> than later.
>> 
>> If all goes well, we can go to IETF LC in early January and have this in the 
>> RFC Editor queue before the London meeting.
>> 
>> Yoav
>> 
>>> Begin forwarded message:
>>> 
>>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>>> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
>>> Date: 14 December 2017 at 16:14:02 GMT+2
>>> To: mailto:i-d-annou...@ietf.org>>
>>> Cc: acme@ietf.org <mailto:acme@ietf.org>
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Automated Certificate Management 
>>> Environment WG of the IETF.
>>> 
>>>Title   : Automatic Certificate Management Environment (ACME)
>>>Authors : Richard Barnes
>>>  Jacob Hoffman-Andrews
>>>  Daniel McCarney
>>>  James Kasten
>>> Filename: draft-ietf-acme-acme-09.txt
>>> Pages   : 80
>>> Date: 2017-12-14
>>> 
>>> Abstract:
>>>   Certificates in PKI using X.509 (PKIX) are used for a number of
>>>   purposes, the most significant of which is the authentication of
>>>   domain names.  Thus, certificate authorities in the Web PKI are
>>>   trusted to verify that an applicant for a certificate legitimately
>>>   represents the domain name(s) in the certificate.  Today, this
>>>   verification is done through a collection of ad hoc mechanisms.  This
>>>   document describes a protocol that a certification authority (CA) and
>>>   an applicant can use to automate the process of verification and
>>>   certificate issuance.  The protocol also provides facilities for
>>>   other certificate management functions, such as certificate
>>>   revocation.
>>> 
>>>   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>>>   this draft is maintained in GitHub.  Suggested changes should be
>>>   submitted as pull requests at https://github.com/ietf-wg-acme/acme 
>>> <https://github.com/ietf-wg-acme/acme>
>>>   [1].  Instructions are on that page as well.  Editorial changes can
>>>   be managed in GitHub, but any substantive change should be discussed
>>>   on the ACME mailing list (acme@ietf.org <mailto:acme@ietf.org>).
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ 
>>> <https://datatracker.ietf.org/doc/draft-ietf-acme-acme/>
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-acme-acme-09 
>>> <https://tools.ietf.org/html/draft-ietf-acme-acme-09>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-09
>>> 
>>> 
>>> 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/
>>> 
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>> 
> 



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

Re: [Acme] YA WGLC for draft-ietf-acme-acme

[Yoav Nir]

Thank you for all who participated.

There have been two editorial changes suggested and accepted in the GitHub 
repository. As soon as a new draft is published, I think we can progress this.

Thanks again.

Yoav

> On 14 Dec 2017, at 19:28, Yoav Nir  wrote:
> 
> Hi
> 
> Draft-09 is now available and has (IMO) addressed all or the outstanding 
> issues.
> 
> This starts an abbreviated WGLC for this draft. Please review the draft and 
> send in your comments by EOD Monday the 25th. Please note that Monday the 
> 25th is Christmas day, so don’t delay - send in your comments sooner rather 
> than later.
> 
> If all goes well, we can go to IETF LC in early January and have this in the 
> RFC Editor queue before the London meeting.
> 
> Yoav
> 
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
>> Date: 14 December 2017 at 16:14:02 GMT+2
>> To: mailto:i-d-annou...@ietf.org>>
>> Cc: acme@ietf.org <mailto:acme@ietf.org>
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Automated Certificate Management 
>> Environment WG of the IETF.
>> 
>>Title   : Automatic Certificate Management Environment (ACME)
>>Authors : Richard Barnes
>>  Jacob Hoffman-Andrews
>>  Daniel McCarney
>>  James Kasten
>>  Filename: draft-ietf-acme-acme-09.txt
>>  Pages   : 80
>>  Date: 2017-12-14
>> 
>> Abstract:
>>   Certificates in PKI using X.509 (PKIX) are used for a number of
>>   purposes, the most significant of which is the authentication of
>>   domain names.  Thus, certificate authorities in the Web PKI are
>>   trusted to verify that an applicant for a certificate legitimately
>>   represents the domain name(s) in the certificate.  Today, this
>>   verification is done through a collection of ad hoc mechanisms.  This
>>   document describes a protocol that a certification authority (CA) and
>>   an applicant can use to automate the process of verification and
>>   certificate issuance.  The protocol also provides facilities for
>>   other certificate management functions, such as certificate
>>   revocation.
>> 
>>   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>>   this draft is maintained in GitHub.  Suggested changes should be
>>   submitted as pull requests at https://github.com/ietf-wg-acme/acme 
>> <https://github.com/ietf-wg-acme/acme>
>>   [1].  Instructions are on that page as well.  Editorial changes can
>>   be managed in GitHub, but any substantive change should be discussed
>>   on the ACME mailing list (acme@ietf.org <mailto:acme@ietf.org>).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-acme-acme/>
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-acme-acme-09
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-09
>> 
>> 
>> 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/
>> 
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
> 



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

Re: [I2nsf] Document Action: 'Framework for Interface to Network Security Functions' to Informational RFC (draft-ietf-i2nsf-framework-10.txt)

[Yoav Nir]

Congratulations to the authors and thanks to all who helped with this document.

This will be our second RFC, and with any luck it should be published before we 
all meet in London.

Linda and Yoav

> On 20 Dec 2017, at 18:44, The IESG  wrote:
> 
> The IESG has approved the following document:
> - 'Framework for Interface to Network Security Functions'
>  (draft-ietf-i2nsf-framework-10.txt) as Informational RFC
> 
> This document is the product of the Interface to Network Security Functions
> Working Group.
> 
> The IESG contact persons are Kathleen Moriarty and Eric Rescorla.
> 
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-framework/
> 
> 
> 
> 
> 
> Technical Summary
> 
>   This document describes the framework for the Interface to Network
>   Security Functions (I2NSF), and defines a reference model (including
>   major functional components) for I2NSF.  Network security functions
>   (NSFs) are packet-processing engines that inspect and optionally
>   modify packets traversing networks, either directly or in the context
>   of sessions to which the packet is associated.
> 
> Working Group Summary
> 
>   There was nothing exceptional in the WG processing for this document.
>   There was careful debate resulting in a number of changes and careful
>   synchronization with other WG documents. 
> 
> Document Quality
> 
>   This framework is not directly implementable, but it underpins the work
>   of the working group. At least one vendor is building a system based on
>   the work of the working group and following this framework as an
>   architecture. There has also been experimentation at IETF hackathons
>   that is consistent with this framework.
> 
> Personnel
> 
>   Yoav Nir is the Document Shepherd.
>   Kathleen Moriarty is the Responsible AD.

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

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

[Yoav Nir]

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

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

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


Yoav


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

[Acme] YA WGLC for draft-ietf-acme-acme

[Yoav Nir]

Hi

Draft-09 is now available and has (IMO) addressed all or the outstanding issues.

This starts an abbreviated WGLC for this draft. Please review the draft and 
send in your comments by EOD Monday the 25th. Please note that Monday the 25th 
is Christmas day, so don’t delay - send in your comments sooner rather than 
later.

If all goes well, we can go to IETF LC in early January and have this in the 
RFC Editor queue before the London meeting.

Yoav

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
> Date: 14 December 2017 at 16:14:02 GMT+2
> To: 
> Cc: acme@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Automated Certificate Management Environment 
> WG of the IETF.
> 
>Title   : Automatic Certificate Management Environment (ACME)
>Authors : Richard Barnes
>  Jacob Hoffman-Andrews
>  Daniel McCarney
>  James Kasten
>   Filename: draft-ietf-acme-acme-09.txt
>   Pages   : 80
>   Date: 2017-12-14
> 
> Abstract:
>   Certificates in PKI using X.509 (PKIX) are used for a number of
>   purposes, the most significant of which is the authentication of
>   domain names.  Thus, certificate authorities in the Web PKI are
>   trusted to verify that an applicant for a certificate legitimately
>   represents the domain name(s) in the certificate.  Today, this
>   verification is done through a collection of ad hoc mechanisms.  This
>   document describes a protocol that a certification authority (CA) and
>   an applicant can use to automate the process of verification and
>   certificate issuance.  The protocol also provides facilities for
>   other certificate management functions, such as certificate
>   revocation.
> 
>   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
>   this draft is maintained in GitHub.  Suggested changes should be
>   submitted as pull requests at https://github.com/ietf-wg-acme/acme
>   [1].  Instructions are on that page as well.  Editorial changes can
>   be managed in GitHub, but any substantive change should be discussed
>   on the ACME mailing list (acme@ietf.org).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-acme-09
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-09
> 
> 
> 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/
> 
> ___
> 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