[IPsec] New Version of Split DNS for IKEv2

[Tommy Pauly]

Hello all,

We've posted a new version of draft-pauly-ipsecme-split-dns 
(https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).

The changes in this version include:

- Textual clarification based on input from Daniel and Tero
- Clarification of DNSSEC payload types
- Update on the content and structure of the INTERNAL_DNSSEC_TA 
attribute
- How to associate DNSSEC values with specific domains
- Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)

We believe this should be ready for adoption and moving forward, to follow the 
charter. Please review and provide your input!

Thanks,
Tommy


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-pauly-ipsecme-split-dns-02.txt
> Date: September 21, 2016 at 1:27:23 PM PDT
> To: Tommy Pauly , Paul Wouters 
> 
> 
> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name: draft-pauly-ipsecme-split-dns
> Revision: 02
> Title:Split DNS Configuration for IKEv2 
> Document date:2016-09-21
> Group:Individual Submission
> Pages:12
> URL:
> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/
> Htmlized:   https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02
> 
> Abstract:
>   This document defines two Configuration Payload Attribute Types for
>   the IKEv2 protocol that add support for private DNS domains.  These
>   domains should be resolved using DNS servers reachable through an
>   IPsec connection, while leaving all other DNS resolution unchanged.
>   This approach of resolving a subset of domains using non-public DNS
>   servers is referred to as "Split DNS".
> 
> 
> 
> 
> 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
> 

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

Re: [IPsec] Quantum Resistance Requirements

[Garcia Morchon O, Oscar]

Hi Scott,

this is a very interesting approach.
Please, find below my feedback.

Kind regards, Oscar.

From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott Fluhrer 
(sfluhrer)
Sent: Tuesday, September 06, 2016 5:10 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: Re: [IPsec] Quantum Resistance Requirements

Last month, I listed a series of potential requirements for a shortterm Quantum 
Resistance solution; several people have commented on these requirements, and 
here are the votes so far (omitting the "no opinion" votes); I've listed the 
voters chiefly so that if I mischaracterized their votes, they can correct me:

From: Scott Fluhrer (sfluhrer)
Sent: Thursday, August 11, 2016 6:01 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: Quantum Resistance Requirements



-  Simplicity; how large of a change to IKE (and IKE implementations) 
are we willing to contemplate?
Scott Fluhrer: very important
Michael Richardson: very important
Tommy Pauly: very important
Valery Smyslov: not as important as other issues
Oscar Garcia-Morchon: very important.


o   My opinion: minimizing changes to IKE should be given high priority, both 
because "complexity is the enemy of security" and this is a short term 
solution; if we have a solution that we can't implement in a few years, well, 
we might as well wait for the crypto people to give us the long term one.


-  Preserving existing IKE security properties?
Scott Fluhrer: very important
Michael Richardson: very important
Tommy Pauly: very important
Valery Smyslov: important
Oscar Garcia-Morchon: very important.


-  What do we feel needs to protected from someone with a Quantum 
Computer?  Do we feel  the need to protect only the IPsec traffic, or do we 
need to protect the IKE traffic as well.
Tommy Pauly: not clear if IKE traffic needs to be protected.
Valery Smylsov: important
Oscar Garcia-Morchon: it seems to me that IPsec traffic is the most important 
one. If IKE traffic could be easily protected as well, this would be a nice 
addition.


-  What level of identity protection do we need to provide?  If two 
different IKE negotiations use the same shared secret, do we mind if someone 
can deduce that?
Scott Fluhrer: not important
Michael Richardson: very important
Tommy Pauly: not important
Valery Smylsov: this is a nice to have, but not critical
Oscar Garcia-Morchon: this is less important, in particular if we only protect 
the IPsec traffic.


-   PPK management; how much support do we provide for automatically 
managing the secrets?
Scott Fluhrer: not important
Tommy Pauly: not important
Oscar Garcia-Morchon: not important.


-  How much support do we provide for nonstatic secrets, for example, 
by QKD, or via something like HIMMO (a key distribution mechanism that appears 
to be post quantum)?
Scott Fluhrer: not important
Michael Richardson: not important
Tommy Pauly: not important
Oscar Garcia-Morchon: not important at this stage, but it is very important to 
have hook to easily support this capability in the future.


-  Authentication; if someone with a Quantum Computer can break the DH 
in real time, do we care if he can act as a man-in-the-middle?
Scott Fluhrer: not important
Michael Richardson: important, provided that we don't run into the same issues 
that IKEv1 PSKs ran into
Tommy Pauly: not important
Valery Smylsov: this would be nice to have
Oscar Garcia-Morchon: less important, but nice to have and it could be easily 
supported with little effort.


-  Algorithm agility; how important is it that we negotiate any 
cryptoprimitives involved?
Scott Fluhrer: not important
Tommy Pauly: not important
Valery Smylsov: important
Oscar Garcia-Morchon: less important.





The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec