Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt

[mohamed.boucadair]

Re-,

This version fixes the type for the ADN TLV. 

Thanks Bernie for catching that. 

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : mercredi 5 octobre 2022 16:18
> À : i-d-annou...@ietf.org
> Cc : opsawg@ietf.org
> Objet : I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Operations and Management Area
> Working Group WG of the IETF.
> 
> Title   : RADIUS Extensions for Encrypted DNS
> Authors : Mohamed Boucadair
>   Tirumaleswar Reddy
>   Filename: draft-ietf-opsawg-add-encrypted-dns-02.txt
>   Pages   : 18
>   Date: 2022-10-05
> 
> Abstract:
>This document specifies new Remote Authentication Dial-In User
>Service (RADIUS) attributes that carry an authentication domain
> name,
>a list of IP addresses, and a set of service parameters of
> encrypted
>DNS resolvers.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-
> dns/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-
> encrypted-dns-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-
> dns-02
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : RADIUS Extensions for Encrypted DNS
Authors : Mohamed Boucadair
  Tirumaleswar Reddy
  Filename: draft-ietf-opsawg-add-encrypted-dns-02.txt
  Pages   : 18
  Date: 2022-10-05

Abstract:
   This document specifies new Remote Authentication Dial-In User
   Service (RADIUS) attributes that carry an authentication domain name,
   a list of IP addresses, and a set of service parameters of encrypted
   DNS resolvers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-dns-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS

[Alan DeKok]

On Oct 5, 2022, at 9:52 AM,  
 wrote:
> [Med] FWIW, https://www.iana.org/assignments/radius-types/radius-types.xhtml 
> lists the following:
> 
> 144   DS-Lite-Tunnel-Name text[RFC6519]
> 
> but RFC6519 itself says the following: 
> 
>   The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string
>   with opaque encapsulation, according to Section 5 of [RFC2865].

  That appears to be an error.  I'll file an errata with IANA.

  Alan DeKok.

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

Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : mercredi 5 octobre 2022 15:38
> À : Bernie Volz 
> Cc : BOUCADAIR Mohamed INNOV/NET ;
> dh...@ietf.org; opsawg@ietf.org
> Objet : Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS
> Option: Encrypted DNS
> 
> On Oct 5, 2022, at 8:37 AM, Bernie Volz  wrote:
> > One minor item you may want to look at is whether “text” is the
> best way to label the following data type in Table 2:
> >
> > TBA3  | Encrypted-DNS-ADN  | text  | This-Document,
> |
> > |   ||   |
> > Section 3.3.1
> >
> > Perhaps “dns wire encoding” might be better?
> 
>If it's encoded as a sequence of DNS labels (length + data,
> length + data, 00), then the correct RADIUS data type is "string"
> [RFC8044] Section 3.5:
> 

[Med] Good point. This would be consistent with this part in the draft: 

  This field includes a fully qualified domain name of the encrypted
  DNS resolver.  This field is formatted as specified in Section 10
  of [RFC8415].

>The "string" data type encodes binary data as a sequence of
>undistinguished octets.   ...
> 
> > Someone that just uses this table may get it wrong? While
> perhaps there is some definition of “text” for Radius attributes,
> a quick check of some seems to show that it is mostly used for
> textual values.
> 
>   RFC 8044 Section 3.4 says this:
> 
>   The "text" data type encodes UTF-8 text ...
> 
> > But perhaps you have limited choices here and other dns encoded
> attributes already use text?
> 
>   There are other attributes in RADIUS which encode host names,
> but those are all printable / UTF-8.
> 
>   I think this is the first RFC which uses the "dns encoding"
> format for DNS names. 

[Med] FWIW, https://www.iana.org/assignments/radius-types/radius-types.xhtml 
lists the following:

144 DS-Lite-Tunnel-Name text[RFC6519]

but RFC6519 itself says the following: 

   The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string
   with opaque encapsulation, according to Section 5 of [RFC2865].

 RFC 8044 allows the transport of non-RADIUS
> data types when that data is simply carried in RADIUS, and is not
> supposed to be interpreted or used by a RADIUS client or server.
> 
>   In this case, I think it's a wash.  Everything else in RADIUS
> uses printable strings.  But if this attribute is simply sent to a
> another system which copies it into a DHCPv6 packet as-is, then
> that's fine.
> 
>   i.e. "this attribute is then copied verbatim into a DHCPv6
> attribute "
> 
>   Such text is missing from the document.  The Introduction does
> imply that the RADIUS attributes can be copied to DHCPv5:
> 
>However, there are no
>RADIUS attributes that can be used to populate the discovery
> messages
>discussed in [I-D.ietf-add-dnr].
> 
>  But there is nothing which says "RADIUS attribute FOO is copied
> to DHCPv6 option BAR".  There should probably either be an
> explicit mapping table given, or each attribute definition should
> be extended with "this attribute is copied to DHCPv6 attribute
> BAR"
> 
>   Without such direction, an implementor has to guess as to the
> mapping.  As an implementor, I would strongly prefer that the
> document gives explicit direction.
> 
>   Alan DeKok.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS

[Alan DeKok]

On Oct 5, 2022, at 8:37 AM, Bernie Volz  wrote:
> One minor item you may want to look at is whether “text” is the best way to 
> label the following data type in Table 2:
> 
> TBA3  | Encrypted-DNS-ADN  | text  | This-Document, |
> |   ||   | 
> Section 3.3.1 
> 
> Perhaps “dns wire encoding” might be better?

   If it's encoded as a sequence of DNS labels (length + data, length + data, 
00), then the correct RADIUS data type is "string" [RFC8044] Section 3.5:

   The "string" data type encodes binary data as a sequence of
   undistinguished octets.   ...

> Someone that just uses this table may get it wrong? While perhaps there is 
> some definition of “text” for Radius attributes, a quick check of some seems 
> to show that it is mostly used for textual values.

  RFC 8044 Section 3.4 says this:

  The "text" data type encodes UTF-8 text ...

> But perhaps you have limited choices here and other dns encoded attributes 
> already use text?

  There are other attributes in RADIUS which encode host names, but those are 
all printable / UTF-8.

  I think this is the first RFC which uses the "dns encoding" format for DNS 
names.  RFC 8044 allows the transport of non-RADIUS data types when that data 
is simply carried in RADIUS, and is not supposed to be interpreted or used by a 
RADIUS client or server.

  In this case, I think it's a wash.  Everything else in RADIUS uses printable 
strings.  But if this attribute is simply sent to a another system which copies 
it into a DHCPv6 packet as-is, then that's fine.

  i.e. "this attribute is then copied verbatim into a DHCPv6 attribute "

  Such text is missing from the document.  The Introduction does imply that the 
RADIUS attributes can be copied to DHCPv5:

   However, there are no
   RADIUS attributes that can be used to populate the discovery messages
   discussed in [I-D.ietf-add-dnr].

 But there is nothing which says "RADIUS attribute FOO is copied to DHCPv6 
option BAR".  There should probably either be an explicit mapping table given, 
or each attribute definition should be extended with "this attribute is copied 
to DHCPv6 attribute BAR"

  Without such direction, an implementor has to guess as to the mapping.  As an 
implementor, I would strongly prefer that the document gives explicit direction.

  Alan DeKok.

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

Re: [OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS

[Bernie Volz]

Hi:

Yes, I don’t see an issue.

One minor item you may want to look at is whether “text” is the best way to 
label the following data type in Table 2:

TBA3  | Encrypted-DNS-ADN  | text  | This-Document, |
|   ||   | Section 3.3.1 

Perhaps “dns wire encoding” might be better? Someone that just uses this table 
may get it wrong? While perhaps there is some definition of “text” for Radius 
attributes, a quick check of some seems to show that it is mostly used for 
textual values. But perhaps you have limited choices here and other dns encoded 
attributes already use text?

- Bernie

> On Oct 5, 2022, at 7:52 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Bernie, all, 
> 
> I don't expect this to be problematic but I prefer to have a formal request 
> to review 
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-01#section-6.3
>  as it relates to a DHC registry.
> 
> Thank you. 
> 
> Cheers,
> Med
> 
> -Message d'origine-
> De : internet-dra...@ietf.org  
> Envoyé : vendredi 30 septembre 2022 16:25
> À : Tirumaleswar Reddy.K ; BOUCADAIR Mohamed INNOV/NET 
> ; Tirumaleswar Reddy 
> Objet : New Version Notification for 
> draft-ietf-opsawg-add-encrypted-dns-01.txt
> 
> 
> A new version of I-D, draft-ietf-opsawg-add-encrypted-dns-01.txt
> has been successfully submitted by Mohamed Boucadair and posted to the IETF 
> repository.
> 
> Name:draft-ietf-opsawg-add-encrypted-dns
> Revision:01
> Title:RADIUS Extensions for Encrypted DNS
> Document date:2022-09-30
> Group:opsawg
> Pages:18
> URL:
> https://www.ietf.org/archive/id/draft-ietf-opsawg-add-encrypted-dns-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-dns-01
> 
> Abstract:
>   This document specifies new Remote Authentication Dial-In User
>   Service (RADIUS) attributes that carry an authentication domain name,
>   a list of IP addresses, and a set of service parameters of encrypted
>   DNS resolvers.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] RADIUS Attributes Permitted in DHCPv6 RADIUS Option: Encrypted DNS

[mohamed.boucadair]

Hi Bernie, all, 

I don't expect this to be problematic but I prefer to have a formal request to 
review 
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-01#section-6.3
 as it relates to a DHC registry.

Thank you. 

Cheers,
Med

-Message d'origine-
De : internet-dra...@ietf.org  
Envoyé : vendredi 30 septembre 2022 16:25
À : Tirumaleswar Reddy.K ; BOUCADAIR Mohamed INNOV/NET 
; Tirumaleswar Reddy 
Objet : New Version Notification for draft-ietf-opsawg-add-encrypted-dns-01.txt


A new version of I-D, draft-ietf-opsawg-add-encrypted-dns-01.txt
has been successfully submitted by Mohamed Boucadair and posted to the IETF 
repository.

Name:   draft-ietf-opsawg-add-encrypted-dns
Revision:   01
Title:  RADIUS Extensions for Encrypted DNS
Document date:  2022-09-30
Group:  opsawg
Pages:  18
URL:
https://www.ietf.org/archive/id/draft-ietf-opsawg-add-encrypted-dns-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-dns-01

Abstract:
   This document specifies new Remote Authentication Dial-In User
   Service (RADIUS) attributes that carry an authentication domain name,
   a list of IP addresses, and a set of service parameters of encrypted
   DNS resolvers.


  


The IETF Secretariat



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

[tom petch]

From: OPSAWG  on behalf of Joe Clarke (jclarke) 

Sent: 04 October 2022 17:45

Thanks, Ken.  I saw your updates, and I agree with you on 5246.

But now that I am done with my shepherd write-up, I notice that there are a 
slew of references in the MIB that are not reflected in the document references 
(e.g., 1123, 5890, etc.).  Given that the full MIB is included in this new 
document, you should include the same references in the Norm/Inform.


This has been a problem with YANG for years and the accepted solution is to 
include a section 4.1 'This module makes references to [RFC1123], [RFC5890] etc 
'

Consistency with YANG would be good:-)

Tom Petch

Joe

From: Kenneth Vaughn 
Date: Tuesday, October 4, 2022 at 10:37
To: Joe Clarke (jclarke) 
Cc: opsawg@ietf.org 
Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
I've updated the document; the only items that remain in the id-nits check 
(https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-09.txt=True)
 are:


  == Unused Reference: 'STD58' is defined on line 1472, but no explicit

 reference was found in the text

STD 58 is referenced in the MIB but I am guessing that the checking tool does 
not check that content? (I don't think I am supposed to use the formal 
cross-referencing in the MIB section)



  -- Obsolete informational reference (is this intentional?): RFC 5246

 (Obsoleted by RFC 8446)
This reference is intentional as we are identifying the initial entries for the 
SNMP-TLSTM HashAlgorithm Registry, which needs to point to the older RFC.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com


On Oct 3, 2022, at 12:20 PM, Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:

I’m working through the shepherd write-up now.  As part of that, I am reviewing 
the IDNITS checks, and there are a number of warnings.

See 
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-08.txt.
  Please work through and address these.  Thanks.

Joe

From: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Date: Tuesday, September 27, 2022 at 13:00
To: Kenneth Vaughn mailto:kvau...@trevilon.com>>
Cc: opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
Thanks for refreshing my memory.  The clutter argument is sound.  I do wish we 
would have gotten a SEC DIR review, but it will certainly get some eyes from 
the IESG.

I’ll mention this point in the shepherd write-up, and we’ll leave things the 
way they are text-wise for now.

Joe

From: Kenneth Vaughn mailto:kvau...@trevilon.com>>
Date: Tuesday, September 27, 2022 at 12:51
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: opsawg@ietf.org 
mailto:opsawg@ietf.org>>
Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
The concept of automatically registering new hash algorithms was discussed 
during a May e-mail thread. Jürgen objected to the automatic recording of 
values and Tom Petch argued for the automatic registration.

While I don't think we ever achieved "agreement" on the position, we concluded 
with consensus (i.e., no sustained objections) on the wording in the current 
draft due to the fact that there was agreement that there was no requirement 
for our fingerprint to use the same hash as used by the TLS layer (and thus no 
technical requirement to link the two registries). >From that point, we 
concluded that if anyone wanted a value, they "would find the energy to 
register it" and we would not clutter the registry with unnecessary values.

Personally, I see the argument on both sides and am fine with the consensus. 
However, I could perhaps see softening the expert review statement to 
automatically approve the request to add any hash algorithm that is already 
approved for any version of TLS or DTLS rather than fording a consultation with 
the TLS WG.

I've made the other changes, but will hold off on implementing them until we 
resolve this issue..

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com




On Sep 27, 2022, at 10:36 AM, Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:

I am reviewing -07 of this draft ahead of the shepherd review.  I have found a 
few nits, but at a larger level, I think more text might be needed for IANA 
around how to handle the new TLS hash registry.  Currently, the draft talks 
about a sync to “IANA TLS HashAlgorithm Registry”, which is good.  But what if 
new values get added to the cipher suites registry?  For example, what about 
GOST variants?  I would think if the TLS 1.3 spec (and their experts) allow for 
these algorithms would this