[TLS] AD review of draft-ietf-tls-external-psk-importer-05

[Roman Danyliw]

Hi!

I've assumed the role of responsible AD on this document.  As such, I performed 
an AD review of draft-ietf-tls-external-psk-importer-05.  All in all, it is in 
good shape.  My feedback is primarily around clarifying the content of the new 
KDF registry and a few of editorial suggestions.  Given that, I'm going to 
advance this document to IETF LC and the feedback below can be 
discussed/addressed concurrently.

** Section 1.  Editorial.  Expand acronym on first use:
-- s/TLS 1.2 PRF/TLS 1.2 Pseudorandom Function (PRF)/
-- s/KDF/Key Derivation Function (KDF)/

** Section 1. Editorial.  Since the text says "... this document specifies a 
PSK Importer interface ... for use in D(TLS 1.3)" perhaps the this scoping 
should also be upfront in the first sentence too:
s/TLS 1.3 [RFC8446] supports/(D)TLS 1.3 [RFC8446][ID-DTLS]/

** Section 4.1.  Editorial.  Per "The list of 'target_kdf' ...", other parts of 
this text refer to elements of struct ImportIdentity with the notation 
"ImportedIdentity.*".  Consider s/The list of "target_kdf" values/The list of 
ImportedIdentity.target_kdf values/

** Section 4.1.
If the EPSK is a key derived from some other protocol or
   sequence of protocols, ImportedIdentity.context MUST include a
   channel binding for the deriving protocols [RFC5056].

To the end of this normative guidance, I'd recommend adding something to the 
effect of: "The details of this binding will be protocol specific and out of 
scope in this document".

** Section 4.1.  Per "If no hash function is specified, SHA-256 MUST be used"

-- Please provide a reference for SHA-256 (per "... If no hash function is 
specified, SHA-256 MUST be used").   

-- It is likely worth saying that this is the equivalent of HKDF_SHA256 (i.e., 
0x0001)

** Section 4.1.  Per "EPSKs may be imported before the started of the 
connection ..." and "EPSKs may also be imported for early data use ..." should 
be these be a normative MAYs?

** Section 4.1.  Per "Minimally, that means ALPN, QUIC ... must be provisioned 
alongside these EPSK"
-- Please expand ALPN

-- should this be a normative MUST?

** Section 9.  Per the columns in the registry:
-- Is there a reason why there isn't a Reference column in the registry to 
capture which specification describes the particular KDF?  I think it needs one 
to eliminate guesswork from the label in "KDF Description" to an algorithm.  

-- Was a Recommended column (and the associated processed for populating it 
like a few of the other TLS registries) discussed/considered?

** Section 9.  While it is implied by the label, the text doesn't explicitly 
say what HKDF_SHA256 and _SHA384 are (per previous comment about needing a 
reference).

Regards,
Roman

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

[TLS] AD review of draft-ietf-tls-exported-authenticator-13

[Roman Danyliw]

Hi!

I've assumed the role of responsible AD on this document.  As such, I performed 
an AD review of draft-ietf-tls-exported-authenticator-13.  This document has 
seen a few WG LCs and reviews.  Thanks for working out the details for this 
feedback.I have a few questions and suggestions for process and editorial 
clarity described below.  Given that, I'm going to advance this document to 
IETF LC and the feedback below can be discussed/addressed concurrently.

** Section 1.  Editorial. Provide a reference to TLS 1.3 when it is first 
mentioned.

OLD
Post-handshake authentication is defined in TLS 1.3

NEW
Post-handshake authentication is defined in Section 4.6.2 of TLS 1.3 [TLS13]

** Section 1.  Editorial. Provide references to for (D)TLS 1.2

OLD
TLS (or DTLS) version 1.2 or later are REQUIRED

NEW
TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED.

** Section 5.  
   The
   application layer protocol used to send the authenticator SHOULD use
   TLS or a protocol with comparable security properties as its
   underlying transport

I saw the additional text added here after the LC on -09 (and the discussion 
that this can't be MUST-use-TLS because of use cases like QUIC).  However, what 
is the envisioned flexibility by using SHOULD (instead of MUST) given the 
addition of the "or a protocol with comparable security properties"?  When 
would I want to use a protocol with reduced security properties?

** Section 5.1.  Editorial.

These values are derived
   using an exporter as described in [RFC5705] (for TLS 1.2) or Sec. 7.5
   of [TLS13] (for TLS 1.3).

-- Please provide the relevant section in RFC5705 (just like was done for 
[TLS13])

-- s/Sec. 7.5/Section 7.5/

** Section 5.2.2.  Editorial. Per "The definition for TLS 1.3 is:" begs the 
question of what that format might be for TLS 1.2.  Can you please make it 
clearer that the format is the same.

** Section 5.2.2.  

Otherwise, the signature algorithm used
   should be chosen from the "signature_algorithms" sent by the peer in
   the ClientHello of the TLS handshake.  

-- Editorial.  For clarity, s/ Otherwise, the signature algorithm used 
.../Otherwise, with spontaneous server authentication, the signature algorithm 
used .../

-- Would it make sense to make this "should" and normative "SHOULD"?

** Section 5.2.4.
   When validating an
   authenticator, a constant-time comparison SHOULD be used.

What's the concern here?  IMO, this guidance seems better in Section 7.4

** Section 7.*.  As Section 7 states that 7.* is informative:
-- Section 7.3. Downgrade the single normative "RECOMMENDED" to be 
"recommended".

-- Section 7.4. Downgrade the single normative "SHOULD" to be "should"

** Section 8.1.  Why shouldn't this document also be added to the "Reference" 
column to explain the addition of "CR" to the "TLS 1.3" column?

** Section 8.2.  With these additions to "Exporter Labels" registry, please 
describe the values of the other fields:
-- How should the "DTLS-OK" and "Recommended" columns be set?

-- The obvious text that this document should be the "Reference"

Regards,
Roman

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

[TLS] AD review of draft-ietf-tls-md5-sha1-deprecate-03

[Roman Danyliw]

Hi!

I've assumed the role of responsible AD on this document.  As such, I performed 
an AD review of draft-ietf-tls-md5-sha1-deprecate-03.  

Thanks for writing this document to address an important crypto maintenance 
tasks in TLS v1.2.  I have a few clarifying and pro forma editorial items of 
feedback.  

** Please address the following IDNits:

-- The document seems to lack an IANA Considerations section.  (See Section
 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
 when there are no actions for IANA.)

-- The draft header indicates that this document updates RFC5246, but the
 abstract doesn't seem to mention this, which it should.

-- The draft header indicates that this document updates RFC7525, but the
 abstract doesn't seem to mention this, which it should.

** Section 1.  Editorial. 
-- s/RFC 5246 [RFC5246]/[RFC5246]/

-- s/RFC 6151 [RFC6151]/[RFC6151]/

-- s/RFC7525 [RFC7525]/[RFC7525]/

** Section 1.  Editorial.  For symmetry with the rest of the text:

OLD
RFC 6151 [RFC6151]
   details the security considerations, including collision attacks for
   MD5, published in 2011.  

NEW
In 2011, [RFC6151]  detailed the security considerations, including collision 
attacks for MD5.  

** Section 1.  Please provide a reference for "Wang, et al".  Is there a 
reference to provide for the "the potential for brute-force attack"

** Section 6.  Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/

** Section 6.  Move the text "In Section 7.4.1.4.1: the text should be revised 
from" out of the "OLD" block of text to be its own intro paragraph so that the 
OLD vs. NEW is  a clear cut-and-paste.

** Section 7.  Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/

** Section 7.  SHA-1 is also not mentioned in RFC7525.  Recommend:

OLD
The prior text did not explicitly include
   MD5 and this text adds it to ensure it is understood as having been
   deprecated.

NEW
The prior text did not explicitly include MD5 or SHA-1; and this text adds 
guidance to ensure that these algorithms have been deprecated.

** Section 7.  Editorial.  Grammar.

OLD
In addition, the use of the SHA-256 hash algorithm is RECOMMENDED,
   SHA-1 or MD5 MUST NOT be used

NEW
In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or 
MD5 MUST NOT be used

** Section 10.2  Please make RFC5246 a normative reference.

Regards,
Roman

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

[TLS] FW: Last Call: (Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)) to Proposed Standard

[Roman Danyliw]

Cross-posting to ensure visibility given the support of the TLS WG during the 
initial IESG Review of this document.

-Original Message-
From: iesg-secret...@ietf.org  
Sent: Monday, September 6, 2021 2:20 PM
To: IETF-Announce 
Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org; 
emu-cha...@ietf.org; e...@ietf.org; j...@salowey.net; Roman Danyliw 

Subject: Last Call:  (Using EAP-TLS with TLS 
1.3 (EAP-TLS 1.3)) to Proposed Standard


The IESG has received a request from the EAP Method Update WG (emu) to consider 
the following document: - 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the 
last-c...@ietf.org mailing lists by 2021-09-20. Exceptionally, comments may be 
sent to i...@ietf.org instead. In either case, please retain the beginning of 
the Subject line to allow automated sorting.

Abstract


   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
   with existing implementations of EAP-TLS.  TLS 1.3 provides
   significantly improved security, privacy, and reduced latency when
   compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS
   1.3) further improves security and privacy by always providing
   forward secrecy, never disclosing the peer identity, and by mandating
   use of revocation checking.  This document also provides guidance on
   authentication, authorization, and resumption for EAP-TLS in general
   (regardless of the underlying TLS version used).  This document
   updates RFC 5216.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



No IPR declarations have been submitted directly on this I-D.





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

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Roman Danyliw]

> -Original Message-
> From: Martin Thomson [mailto:m...@lowentropy.net]
> Sent: Wednesday, August 21, 2019 8:02 PM
> To: David Benjamin ; Roman
> Danyliw 
> Cc: draft-ietf-tls-gre...@ietf.org;  ; The IESG
> ; tls-chairs 
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03:
> (with COMMENT)
> 
> On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote:
> >  That clause was meant to be descriptive of the other bits of the
> > document. "[Such-and-such] may not be [such-and-such]ed, so [some
> > consequence of this]". Using "must not" reads odd to me: "GREASE
> > values must not be negotiated, so they do not directly impact the
> > security of TLS connections."
> 
> Perhaps what you are looking for is "cannot": "GREASE values cannot be
> negotiated, ..."

A "cannot" would make sense to me.

Roman

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

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Roman Danyliw]

Hi David!

From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of David Benjamin
Sent: Wednesday, August 21, 2019 5:44 PM
To: Roman Danyliw 
Cc: draft-ietf-tls-gre...@ietf.org;  ; The IESG 
; Sean Turner ; tls-chairs 
Subject: Re: Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with 
COMMENT)

On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker 
mailto:nore...@ietf.org>> wrote:
--
COMMENT:
--

(1) Per the following:

Section 3.1 says “Note that this requires no special processing on the client.
Clients are already required to reject unknown values  selected by the server.”

Section 4.1 says “Note that this requires no special processing on the server.
Server are already required to reject unknown values selected by the client..”

These statement don’t seem precisely right.  Per Section 3.1, if a client
understands GREASE enough to put it into a message to the server, and the
server for some reason tries to negotiate this value, isn’t there ‘special
processing' required in the client to the degree that it knows it shouldn’t
accept the value it requested in the negotiation?

I suppose it depends on how one implements it. We implemented it by just making 
our ClientHello, etc., serializer put add extra junk in there, so the logic for 
deciding what extensions are acceptable does not see it at all. I suppose, 
sure, if you implemented it by actually registering a fake curve, that would be 
a lot more complexity and probably a bad plan.

How's this rephrasing?

 Note that this can be implemented without special processing on the 
client. The client
 is already required to reject unknown server-selected values, so it
 may leave GREASE values as unknown and reuse the existing logic.

(And analogously for the server section.)

[Roman] This text works for me.  Thank you.

(2) Section 7.  Per “GREASE values may not be negotiated …”, is there a reason
this isn’t “must not be negotiated”?

 That clause was meant to be descriptive of the other bits of the document. 
"[Such-and-such] may not be [such-and-such]ed, so [some consequence of this]". 
Using "must not" reads odd to me: "GREASE values must not be negotiated, so 
they do not directly impact the security of TLS connections."

[Roman] Understood.  Under separate cover, Martin suggested “cannot”.  I’m 
flexible on the edit (i.e., consider what I said a suggestion) given the 
clarity of your explanation (and this is only a comment).  Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Roman Danyliw]

Hi Christian!

Thanks for the detailed responses and the helpful background.  Below are a 
number of proposed text block replacements to clarify my intent (instead of 
more questions).

Roman

> -Original Message-
> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Christian Huitema
> Sent: Wednesday, September 18, 2019 10:14 PM
> To: Roman Danyliw ; The IESG 
> Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> encryption-05: (with COMMENT)
> 
> Thanks for the feedback, Roman. Comments in line.
> 
> On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> > ** Section 1.  Per “More and more services are colocated on
> > multiplexed servers, loosening the relation between IP address and web
> > service”, completely agree.  IMO, unpacking “multiplexed servers” is
> > worthwhile to explain the subsequent text because it motivates the
> > loss of visibility due to encryption with network only monitoring.
> “Multiplex’ happens at two levels:
> >
> > -- co-tenants (e.g., virtual hosting) – multiple services on the same
> > server (i.e., an IP/port doesn’t uniquely identify the service)
> >
> > -- cloud/cdn  – a given platform hosts the services/servers of a lot
> > of organization (i.e., looking up to what netblock an IP belongs
> > reveals little)
> 
> 
> OK, will try to incorporate your text.

Thanks.

> >
> > ** Section 2.1.  Per “The SNI was defined to facilitate management of
> > servers, though the developers of middleboxes soon found out that they
> > could take advantage of the information.  Many examples of such usage
> > are reviewed in [RFC8404].”,
> >
> > -- Can’t middleboxes also help facilitate the management of servers?
> > This text seems to take a particular view on middleboxes which doesn't
> seem appropriate.
> 
> It is pretty clear that the load balancer in front of a server farm will need
> access to the service ID, and must be able to retrieve the decrypted SNI.
> There may be other examples, such as DoS mitigation boxes. The
> "unanticipated usage" comes typically from middle-boxes that are not in the
> same management domain as either the client or the server. Is there an
> established way to designate those?

I'm not sure I understand the original of the requirement that the client and 
server being in the same management domain.

RFC3546's definition of SNI opens with:
   [TLS] does not provide a mechanism for a client to tell a server the
   name of the server it is contacting.  It may be desirable for clients
   to provide this information to facilitate secure connections to
   servers that host multiple 'virtual' servers at a single underlying
   network address.

It seems to me that if we are trying to channel original intent, then only the 
virtual server use case applies.  I'd propose:

OLD
The SNI was defined to facilitate management of servers, though the developers 
of middleboxes soon found out that they could take advantage of the 
information.  Many examples of such usage are reviewed in [RFC8404].

NEW
The SNI was defined to facilitate secure connections to servers that host 
multiple 'virtual' servers at a single underlying network address [RFC3546].  
However, addition management and security practices emerged making use of this 
information.  Examples of such usage are reviewed in [RFC8404].

This language would let you distinguish all of the middle box behaviors done by 
operators and enterprises from a possible [RFC7258] attacker.

> > -- RFC8404 describes a number of middlebox practices, but only Section
> > 6.2 explicitly discusses SNI, and of the examples list here, only one
> > comes from RFC8404.
> A few of the examples also come in the "deep packet inspection" sections of
> 8404. But rather than going in a long discussion, I would rather rewrite the
> sentence as: Many examples of such usage are reviewed in [@?RFC8404],
> other examples came out during discussions of this draft.
> >
> > ** Section 2.1. The “monitoring and identification of specific sites”
> > isn’t symmetric to the other examples – it is rather generic.  The
> > other examples, identify a what/who (e.g., ISP, firewall) + action (e.g.,
> block, filter).
> > Also, to implement most of the other example, “monitoring and
> > identification of specific sites” needs to be done.

I still think this needs to be cleaned up in some way.  IMO, I'd drop it.


> > ** Section 2.1.  Why is parental controls in quotes?  In RFC8404, it is not.
> > The quotes could be read as a judgement on the practice.
> See answer to Alissa. Removing the quotes.

Thanks.

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Roman Danyliw]

> -Original Message-
> From: Benjamin Kaduk [mailto:ka...@mit.edu]
> Sent: Wednesday, September 25, 2019 8:42 PM
> To: Roman Danyliw 
> Cc: Christian Huitema ; The IESG ;
> draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> encryption-05: (with COMMENT)
> 
> On Wed, Sep 25, 2019 at 05:27:53PM +, Roman Danyliw wrote:
> > Hi Christian!
> >
> > Thanks for the detailed responses and the helpful background.  Below are a
> number of proposed text block replacements to clarify my intent (instead of
> more questions).
> >
> > Roman
> >
> > > -Original Message-
> > > From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Christian
> > > Huitema
> > > Sent: Wednesday, September 18, 2019 10:14 PM
> > > To: Roman Danyliw ; The IESG 
> > > Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org;
> > > tls@ietf.org
> > > Subject: Re: [TLS] Roman Danyliw's No Objection on
> > > draft-ietf-tls-sni-
> > > encryption-05: (with COMMENT)
> > >
> > > Thanks for the feedback, Roman. Comments in line.
> > >
> > > On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> > > > ** Section 1.  Per “More and more services are colocated on
> > > > multiplexed servers, loosening the relation between IP address and
> > > > web service”, completely agree.  IMO, unpacking “multiplexed
> > > > servers” is worthwhile to explain the subsequent text because it
> > > > motivates the loss of visibility due to encryption with network only
> monitoring.
> > > “Multiplex’ happens at two levels:
> > > >
> > > > -- co-tenants (e.g., virtual hosting) – multiple services on the
> > > > same server (i.e., an IP/port doesn’t uniquely identify the
> > > > service)
> > > >
> > > > -- cloud/cdn  – a given platform hosts the services/servers of a
> > > > lot of organization (i.e., looking up to what netblock an IP
> > > > belongs reveals little)
> > >
> > >
> > > OK, will try to incorporate your text.
> >
> > Thanks.
> >
> > > >
> > > > ** Section 2.1.  Per “The SNI was defined to facilitate management
> > > > of servers, though the developers of middleboxes soon found out
> > > > that they could take advantage of the information.  Many examples
> > > > of such usage are reviewed in [RFC8404].”,
> > > >
> > > > -- Can’t middleboxes also help facilitate the management of servers?
> > > > This text seems to take a particular view on middleboxes which
> > > > doesn't
> > > seem appropriate.
> > >
> > > It is pretty clear that the load balancer in front of a server farm
> > > will need access to the service ID, and must be able to retrieve the
> decrypted SNI.
> > > There may be other examples, such as DoS mitigation boxes. The
> > > "unanticipated usage" comes typically from middle-boxes that are not
> > > in the same management domain as either the client or the server. Is
> > > there an established way to designate those?
> >
> > I'm not sure I understand the original of the requirement that the client
> and server being in the same management domain.
> >
> > RFC3546's definition of SNI opens with:
> >[TLS] does not provide a mechanism for a client to tell a server the
> >name of the server it is contacting.  It may be desirable for clients
> >to provide this information to facilitate secure connections to
> >servers that host multiple 'virtual' servers at a single underlying
> >network address.
> 
> I think the idea is that you can have a client-side forward proxy or a server-
> side reverse proxy, and either of those can be okay, but you don't want
> some random unaffiliated thing in the network poking at things.
> So, one might have client != server, but (client == middlebox) OR (server ==
> middlebox), where equality reflects membership in the same administrative
> domain.

Understood, but IMO, this is an interpretation of "anticipated use".  Taking a 
narrow read of RFC3546, I don't see explicit references to proxies, domain 
boundaries, etc.  The line of thinking I read in this draft is that there are 
certain anticipated and unanticipated uses of SNI.  If the practice is 
categorized as unanticipated, then it should be "thwarted" with encrypted SNI 
(per Section 2.3)

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Roman Danyliw]

Hi Christian!

Thanks for all of the updates.  I have a remaining items are described inline.

To bring up a new item, there was new text introduced in -06 of Section 5 to 
which I strongly object.  Specifically:

"Replacing clear text SNI transmission by an encrypted variant will 
also thwart MITM interferences that are sometimes described as  
legitimate.  As explained in Section 2.3, alternative solutions will
have to be developed.”

I read this paragraph as addressing the operational practices outlined in 
Section 2.1.  I think it is inappropriate to refer to some of these operational 
practices as being "sometimes described as legitimate".

> -Original Message-
> From: Christian Huitema [mailto:huit...@huitema.net]
> Sent: Wednesday, September 25, 2019 3:47 PM
> To: Roman Danyliw ; The IESG 
> Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> encryption-05: (with COMMENT)
> 
> Hello Roman,
> 
> A lot of the fixes that you suggested are incorporated in the draft-07 that 
> was
> just released. I think the last version addresses your concerns, but you may
> of course want to verify.
> 
> On 9/25/2019 7:27 AM, Roman Danyliw wrote:
> > Hi Christian!
> >
> > Thanks for the detailed responses and the helpful background.  Below are a
> number of proposed text block replacements to clarify my intent (instead of
> more questions).
> >
> > Roman
> >
> >> -Original Message-
> >> From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Christian
> >> Huitema
> >> Sent: Wednesday, September 18, 2019 10:14 PM
> >> To: Roman Danyliw ; The IESG 
> >> Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org;
> >> tls@ietf.org
> >> Subject: Re: [TLS] Roman Danyliw's No Objection on
> >> draft-ietf-tls-sni-
> >> encryption-05: (with COMMENT)
> >>
> >> Thanks for the feedback, Roman. Comments in line.
> >>
> >> On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> >>> ** Section 1.  Per “More and more services are colocated on
> >>> multiplexed servers, loosening the relation between IP address and
> >>> web service”, completely agree.  IMO, unpacking “multiplexed
> >>> servers” is worthwhile to explain the subsequent text because it
> >>> motivates the loss of visibility due to encryption with network only
> monitoring.
> >> “Multiplex’ happens at two levels:
> >>> -- co-tenants (e.g., virtual hosting) – multiple services on the
> >>> same server (i.e., an IP/port doesn’t uniquely identify the service)
> >>>
> >>> -- cloud/cdn  – a given platform hosts the services/servers of a lot
> >>> of organization (i.e., looking up to what netblock an IP belongs
> >>> reveals little)
> >>
> >> OK, will try to incorporate your text.
> > Thanks.
> 
> Changes incorporated in first paragraph of section 1.

The text -07 works for me.  Thanks for adding this extra bit.

> >
> >>> ** Section 2.1.  Per “The SNI was defined to facilitate management
> >>> of servers, though the developers of middleboxes soon found out that
> >>> they could take advantage of the information.  Many examples of such
> >>> usage are reviewed in [RFC8404].”,
> >>>
> >>> -- Can’t middleboxes also help facilitate the management of servers?
> >>> This text seems to take a particular view on middleboxes which
> >>> doesn't
> >> seem appropriate.
> >>
> >> It is pretty clear that the load balancer in front of a server farm
> >> will need access to the service ID, and must be able to retrieve the
> decrypted SNI.
> >> There may be other examples, such as DoS mitigation boxes. The
> >> "unanticipated usage" comes typically from middle-boxes that are not
> >> in the same management domain as either the client or the server. Is
> >> there an established way to designate those?
> > I'm not sure I understand the original of the requirement that the client
> and server being in the same management domain.
> >
> > RFC3546's definition of SNI opens with:
> >[TLS] does not provide a mechanism for a client to tell a server the
> >name of the server it is contacting.  It may be desirable for clients
> >to provide this information to facilitate secure connections to
> >servers that host multiple 'virtual' servers at a single underlying
> >network address.
&g

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Roman Danyliw]

Hi Christian!

Thanks for all of the iteration and updates.  Given what’s proposed in github 
(https://github.com/tlswg/sniencryption/pull/46/files), consider my comments 
resolved.  Minor comments inline …

From: Christian Huitema [mailto:huit...@huitema.net]
Sent: Thursday, September 26, 2019 6:53 PM
To: Roman Danyliw ; The IESG 
Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@ietf.org; tls@ietf.org
Subject: Re: [TLS] Roman Danyliw's No Objection on 
draft-ietf-tls-sni-encryption-05: (with COMMENT)



On 9/26/2019 11:38 AM, Roman Danyliw wrote:

Hi Christian!



Thanks for all of the updates.  I have a remaining items are described inline.



To bring up a new item, there was new text introduced in -06 of Section 5 to 
which I strongly object.  Specifically:



"Replacing clear text SNI transmission by an encrypted variant will

also thwart MITM interferences that are sometimes described as

legitimate.  As explained in Section 2.3, alternative solutions will

have to be developed.”



I read this paragraph as addressing the operational practices outlined in 
Section 2.1.  I think it is inappropriate to refer to some of these operational 
practices as being "sometimes described as legitimate".

Anything performed by MITM is by definition controversial. But I get your 
point. How about

"Replacing clear text SNI transmission by an encrypted variant will break or 
reduce the

efficacy of the operational practices and techniques implemented in 
middle-boxes as

described in Section 2.1. As explained in Section 2.3, alternative solutions 
will

have to be developed."



[Roman] Looks good to me.  Thanks.



-Original Message-

From: Christian Huitema [mailto:huit...@huitema.net]

Sent: Wednesday, September 25, 2019 3:47 PM

To: Roman Danyliw <mailto:r...@cert.org>; The IESG 
<mailto:i...@ietf.org>

Cc: 
draft-ietf-tls-sni-encrypt...@ietf.org<mailto:draft-ietf-tls-sni-encrypt...@ietf.org>;
 tls-cha...@ietf.org<mailto:tls-cha...@ietf.org>; 
tls@ietf.org<mailto:tls@ietf.org>

Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-

encryption-05: (with COMMENT)



Hello Roman,



A lot of the fixes that you suggested are incorporated in the draft-07 that was

just released. I think the last version addresses your concerns, but you may

of course want to verify.



On 9/25/2019 7:27 AM, Roman Danyliw wrote:

Hi Christian!



Thanks for the detailed responses and the helpful background.  Below are a

number of proposed text block replacements to clarify my intent (instead of

more questions).



Roman



-Original Message-

From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Christian

Huitema

Sent: Wednesday, September 18, 2019 10:14 PM

To: Roman Danyliw <mailto:r...@cert.org>; The IESG 
<mailto:i...@ietf.org>

Cc: 
draft-ietf-tls-sni-encrypt...@ietf.org<mailto:draft-ietf-tls-sni-encrypt...@ietf.org>;
 tls-cha...@ietf.org<mailto:tls-cha...@ietf.org>;

tls@ietf.org<mailto:tls@ietf.org>

Subject: Re: [TLS] Roman Danyliw's No Objection on

draft-ietf-tls-sni-

encryption-05: (with COMMENT)



Thanks for the feedback, Roman. Comments in line.



On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:

** Section 1.  Per “More and more services are colocated on

multiplexed servers, loosening the relation between IP address and

web service”, completely agree.  IMO, unpacking “multiplexed

servers” is worthwhile to explain the subsequent text because it

motivates the loss of visibility due to encryption with network only

monitoring.

“Multiplex’ happens at two levels:

-- co-tenants (e.g., virtual hosting) – multiple services on the

same server (i.e., an IP/port doesn’t uniquely identify the service)



-- cloud/cdn  – a given platform hosts the services/servers of a lot

of organization (i.e., looking up to what netblock an IP belongs

reveals little)



OK, will try to incorporate your text.

Thanks.



Changes incorporated in first paragraph of section 1.



The text -07 works for me.  Thanks for adding this extra bit.





** Section 2.1.  Per “The SNI was defined to facilitate management

of servers, though the developers of middleboxes soon found out that

they could take advantage of the information.  Many examples of such

usage are reviewed in [RFC8404].”,



-- Can’t middleboxes also help facilitate the management of servers?

This text seems to take a particular view on middleboxes which

doesn't

seem appropriate.



It is pretty clear that the load balancer in front of a server farm

will need access to the service ID, and must be able to retrieve the

decrypted SNI.

There may be other examples, such as DoS mitigation boxes. The

"unanticipated usage" comes typically from middle-boxes that are not

in the same management domain as either the client or the server. Is

there an established way to designate those?

I'm not sure I 

[TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

[Roman Danyliw]

Hi!

From: Quynh Dang 
Sent: Wednesday, January 15, 2025 3:22 PM
To: Andrei Popov 
Cc: tls@ietf.org
Subject: [TLS] Re: [EXTERNAL] Re: Changing WG Mail List Reputation

Warning: External Sender - do not click links or open attachments unless you 
recognize the sender and know the content is safe.


On Wed, Jan 15, 2025, 2:45 PM Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:

  *   I started with some change suggestions for you to consider
Understood; the suggestion that consensus should be determined at the meetings 
has been opposed by others, I don’t need to repeat the arguments.
Even as an employee of a large business, I cannot rely solely on the 
(increasingly more expensive) meeting attendance to participate in the IETF 
consensus process.
One can pay for 1 day participation to join in a meeting, see my second email 
on this thread.

[Roman] To add more on the topic of meeting cot – in addition to onsite 
participation, there is a remote participation option.  If one is unable to pay 
the remote meeting fee, there is an unlimited, “no questions asked” fee waiver. 
 See https://www.ietf.org/meeting/registration-fee-waivers/.

Regards,
Roman

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Roman Danyliw's Yes on draft-ietf-tls-external-psk-guidance-04: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-external-psk-guidance-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/



--
COMMENT:
--

Thank you to Rich Salz for the SECDIR review.

** Section 6.1.  Consider providing information references for OpenSSL,
BoringSSL, mbedTLS, gnuTLS and wolfSSL

** Section 6.1.  Should it be noted that some libraries (E.g., OpenSSL,
BoringSSL, mbedTLS) support PSK lengths below the threshold recommend in this
document (i.e., smaller than 128-bits per Section 6)?

** Editorial nits:

-- Section 4.1.  Typo. s/mitigiation/mitigation/
-- Section 6.  Duplicate word. s/exchange exchange/exchange/
-- Section 8. Typo. s/beynond/beyond/



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

[TLS] Roman Danyliw's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-subcerts-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/



--
COMMENT:
--

** Section 4
 Endpoints will reject delegated
  credentials that expire more than 7 days from the current time (as
  described in Section 4.1) based on the default (see Section 3.

For clarity, consider:

NEW
By default, unless set to an alternative value by an application profile (see
Section 3), endpoints will reject delegated credentials that expire more than 7
days from the current time (as described in Section 4.1.3).

** Section 7.1
   However, they cannot create new delegated credentials.  Thus,
   delegated credentials should not be used to send a delegation to an
   untrusted party, ...

The second sentence doesn’t seem to follow from the first.

** Appendix B
   The following certificate has the Delegated Credentials OID.

For clarity, consider:

NEW
The following is an example of a delegation certificate which satisfies the
requirements described in Section 4.2 (i.e., uses the DelegationUsage extension
and has the digitalSignature KeyUsage).

** Appendix B.  I will leave to the RFC Editor to decide if using the Watson
Ladd’s personal home page (kc2kdm.com) in the certificate SAN is an acceptable
example domain name.

Editorial Nits

** Abstract.  Typo. s/to to/to/

** Section 4.2. Typo. s/documnt/document/

** Section 7.6.  In the spirit of inclusive language, consider if there is an
alternative term to “man-in-the-middle certificate”



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

[TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-grease-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-grease/



--
COMMENT:
--

(1) Per the following:

Section 3.1 says “Note that this requires no special processing on the client. 
Clients are already required to reject unknown values  selected by the server.”

Section 4.1 says “Note that this requires no special processing on the server. 
Server are already required to reject unknown values selected by the client.”

These statement don’t seem precisely right.  Per Section 3.1, if a client
understands GREASE enough to put it into a message to the server, and the
server for some reason tries to negotiate this value, isn’t there ‘special
processing' required in the client to the degree that it knows it shouldn’t
accept the value it requested in the negotiation?

(2) Section 7.  Per “GREASE values may not be negotiated …”, is there a reason
this isn’t “must not be negotiated”?


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

[TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-sni-encryption-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/



--
COMMENT:
--

** Section 1.  Per “More and more services are colocated on multiplexed
servers, loosening the relation between IP address and web service”, completely
agree.  IMO, unpacking “multiplexed servers” is worthwhile to explain the
subsequent text because it motivates the loss of visibility due to encryption
with network only monitoring.  “Multiplex’ happens at two levels:

-- co-tenants (e.g., virtual hosting) – multiple services on the same server
(i.e., an IP/port doesn’t uniquely identify the service)

-- cloud/cdn  – a given platform hosts the services/servers of a lot of
organization (i.e., looking up to what netblock an IP belongs reveals little)

** Section 2.1.  Per “The SNI was defined to facilitate management of servers,
though the developers of middleboxes soon found out that they could take
advantage of the information.  Many examples of such usage are reviewed in
[RFC8404].”,

-- Can’t middleboxes also help facilitate the management of servers?  This text
seems to take a particular view on middleboxes which doesn't seem appropriate.

-- RFC8404 describes a number of middlebox practices, but only Section 6.2
explicitly discusses SNI, and of the examples list here, only one comes from
RFC8404.

** Section 2.1. The “monitoring and identification of specific sites” isn’t
symmetric to the other examples – it is rather generic.  The other examples,
identify a what/who (e.g., ISP, firewall) + action (e.g., block, filter). 
Also, to implement most of the other example, “monitoring and identification of
specific sites” needs to be done.

** Section 2.1.  Why is parental controls in quotes?  In RFC8404, it is not. 
The quotes could be read as a judgement on the practice.

** Section 2.1.  Per “The SNI is probably also included in the general
collection of metadata by pervasive surveillance actors”, I recommend against
speculation and instead simply stating that SNI would be interesting meta-data
for a RFC7258 attacker.

** Section 2.2.  Per “One reason may be that, when these RFCs were written, the
SNI information was available through a variety of other means”, what would
those “other means” be?

** Section 2.3.  Per “Deploying SNI encryption will help thwarting most of the
‘unanticipated’ SNI usages described in Section 2.1, including censorship and
pervasive surveillance.”:

-- Why the quotes around "unanticipated" SNI usage?

-- One person’s censorship is another person’s threat mitigation, policy
enforcement for a network they own, or parental controls (per the list in
Section 2.1) – recommend being more precise on the order of “Deploying SNI
encryption will {break | reduce the efficacy of } the operational practices and
techniques used in middleboxes described in Section 2.1”.

** Section 2.3.  Per “It will also thwart functions that are sometimes
described as legitimate”, what functions are those?  I’d recommend eliminating
this sentence as it reads like a value judgement on existing practices (which
doesn’t seem germane for discussing requirements).

** Section 3.  Per “Over the past years, there have been multiple proposals to
add an SNI encryption option in TLS.”, can these past proposals be cited so
future readers can learn from them.

** Section 3.4. The existence of designs were alluded to but not cited.  Be
specific with citation.

** Section 3.7.1. The rational for including this discussion about ALPN isn’t
clear as it doesn’t suggest new requirements for SNI encryption.

** Section 4.  I got hung-up on the description of Section 4 describing a
“solution”.  Is Section 4 (and the related subsections) describing an
operational practice or a notional reference architecture?  The text reads one
part “people are doing” and another part “people could do”.

** Section 4.  Per “In the absence of TLS-level SNI encryption, many sites rely
on an "HTTP Co-Tenancy" solution”, this seems like a strong of a statement
about utilization of this architecture explicitly to hide the
hidden.example.com SNI.  Can you provide a citation for a sense penetration.

** Section 4.  Per the bullet “since this is an HTTP-level solution”, I
recommend citing that it fails on the requirement identified in Section 3.7
(instead of enumerating a list of protocols)

** Section 4.  The opening of this secti

[TLS] Roman Danyliw's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)

[Roman Danyliw via Datatracker]

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/



--
COMMENT:
--

* Section 7. The paragraphs that start with “In this extension, the external
PSK preserves secrecy if the EC(DH) key agreement” …” and “In the future, if
the (EC)DH key agreement ..” seem to be saying the same thing differently.

* Section 7. It’s worth mentioning somewhere the obvious thing – how to
generate, distribute, manage the external PSKs is out of scope for this
specification.

* Section 7.  Per “TLS 1.3 [RFC8446] has received careful security analysis,
and some informal reasoning shows that the addition of this extension does not
introduce any security defects”, is there a citation for this “informal
reasoning”?  Otherwise, it’s a soft statement.

* Editorial Nits:
- Section 3.  Typo.  s/inclue/include/

- Section 5.1. Typo. s/extension are/extensions are/

- Section 5.1. /Most of those extension are not impacted in any way.  This
section discusses the impacts on the other extensions./Most of those extension
are not impacted in any way by this specification.  However, this section
discusses the extensions that require additional consideration./

- Section 5.1.  Typo. s/may be know to other partiers/may be known to other
parties/

- Section 5.1. Typo. s/know to other parties/known to other parties/

- Section 7.  Typo.  s/that external PSK/that the external PSK/


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