Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02

On Sun, Nov 10, 2019 at 03:41:44PM -0500, Russ Housley wrote: > Ben: > > I have made the edits indicated in my response below. I cannot pot it until > the I-D repository reopens. I'm happy to approve a manual posting sooner if you want, though I do not think it would have a huge impact on time-

Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02

Ben: I have made the edits indicated in my response below. I cannot pot it until the I-D repository reopens. > Thanks for putting this together, and sorry again for the delays in > processing. > > I note inline many places where we essentially repeat preexisting > requirements from RFC 8446 bu

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Mon, May 22, 2017 at 04:00:20PM -0500, Nico Williams wrote: > On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:43 AM, Nico Williams > > wrote: > > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > > > On Tue, May 23, 2017 at 5:17 AM

Re: [TLS] AD Review of draft-ietf-tls-tls13

On 5/22/17 at 10:46 AM, ietf-d...@dukhovni.org (Viktor Dukhovni) wrote: On May 22, 2017, at 1:37 PM, Salz, Rich wrote: I strongly believe the text should stay as it is, for the most good to the most people. Viktor is in the weeds, arguably by himself. Right, all by myself... With support

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 06:22:30AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 6:00 AM, Nico Williams > wrote: > > > I don't understand the question. If you treat them as unknown then > > > either your path construction code will route around them or once you > > > try to verify, it will

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 5:22 PM, Eric Rescorla wrote: > > I don't think "opportunistic" is a clearly enough defined category to be > useful > here. If you mean: > I don't think "strongly authenticate" is useful here. I think the > requirement is that the RP must not accept these algorithms in a

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 6:00 AM, Nico Williams wrote: > On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:43 AM, Nico Williams > > wrote: > > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > > > On Tue, May 23, 2017 at 5:17 AM, Nico

Re: [TLS] AD Review of draft-ietf-tls-tls13

This document has WGLC and so has a presumption of consensus. If you want to re-raise that, this is a process question which is the province of the chairs, so if you feel strongly, as it appears you do, I would encourage you raise it with them. -Ekr On Tue, May 23, 2017 at 6:02 AM, Viktor Dukhov

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 3:42 PM, Eric Rescorla wrote: > > Well, I certainly think past the Web PKI, because one of the cases I care > about > is WebRTC, which doesn't do any PKI validation at all. > > In any case, I think there are two issues: > 1. Forbid TLS 1.3 implementations from accepting M

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 05:49:47AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 5:43 AM, Nico Williams > wrote: > > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams > > > wrote: > > > > > In any case, I think there are tw

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 5:43 AM, Nico Williams wrote: > On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > > On Tue, May 23, 2017 at 5:17 AM, Nico Williams > > wrote: > > > > In any case, I think there are two issues: > > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 05:26:28AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 5:17 AM, Nico Williams > wrote: > > > In any case, I think there are two issues: > > > 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1. > > > 2. Require a specific failure if the peer presents s

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 5:17 AM, Nico Williams wrote: > On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote: > > Well, I certainly think past the Web PKI, because one of the cases I > > care about is WebRTC, which doesn't do any PKI validation at all. > > > > In any case, I think there

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote: > Well, I certainly think past the Web PKI, because one of the cases I > care about is WebRTC, which doesn't do any PKI validation at all. > > In any case, I think there are two issues: > 1. Forbid TLS 1.3 implementations from acceptin

Re: [TLS] AD Review of draft-ietf-tls-tls13

Well, I certainly think past the Web PKI, because one of the cases I care about is WebRTC, which doesn't do any PKI validation at all. In any case, I think there are two issues: 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1. 2. Require a specific failure if the peer presents such

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 1:37 PM, Salz, Rich wrote: > > I strongly believe the text should stay as it is, for the most good to the > most people. Viktor is in the weeds, arguably by himself. Right, all by myself... With support from Nico, Ilari, and others who've upthread accepted that certifi

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On 22 May 2017, at 20:27, Benjamin Kaduk wrote: > > On 05/22/2017 12:17 PM, Viktor Dukhovni wrote: >>> On May 22, 2017, at 1:06 PM, Benjamin Kaduk >>> wrote: >>> >>> Given the apparent strength of opinion against removing these supposed >>> restrictions entirely,

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 1:27 PM, Benjamin Kaduk wrote: > >> Isn't the language in question tackling a non-problem? > > It probably is, but I don't feel a need to spend a lot of my time pushing > for it to be removed. Well, the reason for this sub-thread is that I just to waste a bunch of cycles

Re: [TLS] AD Review of draft-ietf-tls-tls13

I assert that most uses of TLS are server-authenticated using a PKIX-compliant certificate, no matter if you count users/servers, connections, bytes transferred, or e-commerce dollar value. It has been this way forever and that is why the TLS RFC’s have always talked about certificates, althoug

Re: [TLS] AD Review of draft-ietf-tls-tls13

On 05/22/2017 12:17 PM, Viktor Dukhovni wrote: >> On May 22, 2017, at 1:06 PM, Benjamin Kaduk wrote: >> >> Given the apparent strength of opinion against removing these supposed >> restrictions entirely, it seems like this text (or something similar) is >> probably the best we can do. > Perhaps

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 1:06 PM, Benjamin Kaduk wrote: > > Given the apparent strength of opinion against removing these supposed > restrictions entirely, it seems like this text (or something similar) is > probably the best we can do. Perhaps so, but I saw only one strong objection from Dave G

Re: [TLS] AD Review of draft-ietf-tls-tls13

On 05/20/2017 12:55 AM, Viktor Dukhovni wrote: >> On May 20, 2017, at 1:41 AM, Nico Williams wrote: >> >> "When using TLS to authenticate the server, certificate signature >> algorithms weaker than >> MUST NOT be used." > Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX)

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 11:35 AM, Viktor Dukhovni wrote: > > Still, all of this belongs in an update of RFC5280, but if we just can't > resist saying something here along the lines you suggest then it might be: > > "When peer authentication is via a certificate, with RFC5280 (PKIX) chain > verifi

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 22, 2017, at 10:50 AM, Nico Williams wrote: > >>> "When using TLS to authenticate the server, certificate signature >>> algorithms weaker than >>> MUST NOT be used." >> >> Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX) >> to authenticate... (the [server or

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Sat, May 20, 2017 at 01:55:07AM -0400, Viktor Dukhovni wrote: > > On May 20, 2017, at 1:41 AM, Nico Williams wrote: > > "When using TLS to authenticate the server, certificate signature > > algorithms weaker than > > MUST NOT be used." > > Minor correction, perhaps you really mean to say "whe

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote: > On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > > Which brings us to some more undesirable layer violation in the current > > draft. The language in question is appropriate for updates to RFC5280, > > but does not belong

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 20, 2017, at 1:41 AM, Nico Williams wrote: > > "When using TLS to authenticate the server, certificate signature > algorithms weaker than > MUST NOT be used." Minor correction, perhaps you really mean to say "when using RFC5280 (PKIX) to authenticate... (the [server or client?]). TLS

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Fri, May 19, 2017 at 09:43:19PM -0400, Dave Garrett wrote: > On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > > I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, > > MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 > > or even MD5. >

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 19, 2017, at 9:43 PM, Dave Garrett wrote: > >> I note that TLS 1.3 does not have any language prohibiting MD2, MDC2DES, >> MD4, RIPEMD160, private signature oids, ... that may be weaker than SHA-1 >> or even MD5. > > They're not listed as possible field values anywhere directly in the

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Friday, May 19, 2017 04:51:21 pm Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already addressed else

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Fri, May 19, 2017 at 04:51:21PM -0400, Viktor Dukhovni wrote: > Which brings us to some more undesirable layer violation in the current > draft. The language in question is appropriate for updates to RFC5280, > but does not belong in TLS. The problems in question are largely > already addresse

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 19, 2017, at 5:34 AM, Sankalp Bagaria wrote: > > I would like to mention that TLS can be used with non-X.509 certificates also. > In particular, it can be used with ITS ETSI and IEEE certificates. > https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609 > > So, in my

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Fri, May 19, 2017 at 03:04:49PM +0530, Sankalp Bagaria wrote: > Hi, > > I would like to mention that TLS can be used with non-X.509 certificates > also. > In particular, it can be used with ITS ETSI and IEEE certificates. > https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee160

Re: [TLS] AD Review of draft-ietf-tls-tls13

Hi, I would like to mention that TLS can be used with non-X.509 certificates also. In particular, it can be used with ITS ETSI and IEEE certificates. https://datatracker.ietf.org/doc/html/draft-serhrouchni-tls-certieee1609 So, in my opinion, TLS should be very loosely or not at all coupled with R

Re: [TLS] AD Review of draft-ietf-tls-tls13

On 18 May 2017 at 09:08, Eric Rescorla wrote: > This works for me, does anyone object to my updating the PR in this fashion? Go ahead. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AD Review of draft-ietf-tls-tls13

This works for me, does anyone object to my updating the PR in this fashion? -Ekr On Thu, May 18, 2017 at 2:10 AM, Brian Smith wrote: > Kathleen Moriarty wrote: > > 4. Section 6.2 Error Alerts > > > > In addition to sending the error, I don't see any mention of the error > > being logged on t

Re: [TLS] AD Review of draft-ietf-tls-tls13

Kathleen Moriarty wrote: > 4. Section 6.2 Error Alerts > > In addition to sending the error, I don't see any mention of the error > being logged on the server side, shouldn't that be specified? Logging > errors (at least in debug modes when needed) provides valuable > troubleshooting information

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tuesday, May 16, 2017 12:37:42 pm Viktor Dukhovni wrote: >* RFC7250 raw public keys Just as a footnote to anyone reading this discussion that may not know: The current version of the TLS 1.3 spec explicitly recommends RFC7250 raw public keys as a viable option and provides the needed inform

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 9:49 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni > wrote: > > > >> On May 16, 2017, at 11:36 AM, Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > >> > >> OK, does that put us back to t

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 8:36 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > On Tue, May 16, 2017 at 11:31 AM, Russ Housley > wrote: > > > > On May 16, 2017, at 11:23 AM, Eric Rescorla wrote: > > > > > > > > On Tue, May 16, 2017 at 8:17 AM, Russ Housley > wrote: > >> > >> > >

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni wrote: > >> On May 16, 2017, at 11:36 AM, Kathleen Moriarty >> wrote: >> >> OK, does that put us back to the suggested wording: >> >>"TLS depends on certificate path validation, and a conformant >> TLS implementation MUST implement certif

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 16, 2017, at 11:36 AM, Kathleen Moriarty > wrote: > > OK, does that put us back to the suggested wording: > >"TLS depends on certificate path validation, and a conformant > TLS implementation MUST implement certificate paths validation > in a manner that achieves the same

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 11:31 AM, Russ Housley wrote: > > On May 16, 2017, at 11:23 AM, Eric Rescorla wrote: > > > > On Tue, May 16, 2017 at 8:17 AM, Russ Housley wrote: >> >> >> On May 15, 2017, at 7:01 PM, Eric Rescorla wrote: >> >> >> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley >> wro

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 16, 2017, at 11:23 AM, Eric Rescorla wrote: > > > > On Tue, May 16, 2017 at 8:17 AM, Russ Housley > wrote: > >> On May 15, 2017, at 7:01 PM, Eric Rescorla > > wrote: >> >> >> >> On Mon, May 15, 2017 at 12:38 PM, Russ Housley >

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 8:17 AM, Russ Housley wrote: > > On May 15, 2017, at 7:01 PM, Eric Rescorla wrote: > > > > On Mon, May 15, 2017 at 12:38 PM, Russ Housley > wrote: > >> Just commenting on Section 4.2 … >> >> > >> > > 3. Section 4.2. >> > > >> > >"In general, detailed certificate vali

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 11:17 AM, Russ Housley wrote: > > On May 15, 2017, at 7:01 PM, Eric Rescorla wrote: > > > > On Mon, May 15, 2017 at 12:38 PM, Russ Housley wrote: >> >> Just commenting on Section 4.2 … >> >> > >> > > 3. Section 4.2. >> > > >> > >"In general, detailed certificate valid

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 15, 2017, at 7:01 PM, Eric Rescorla wrote: > > > > On Mon, May 15, 2017 at 12:38 PM, Russ Housley > wrote: > Just commenting on Section 4.2 … > > > > > > 3. Section 4.2. > > > > > >"In general, detailed certificate validation procedures are out of >

Re: [TLS] AD Review of draft-ietf-tls-tls13

On Mon, May 15, 2017 at 12:38 PM, Russ Housley wrote: > Just commenting on Section 4.2 … > > > > > > 3. Section 4.2. > > > > > >"In general, detailed certificate validation procedures are out of > > >scope for TLS (see [RFC5280]). This section provides TLS-specific > > >requirements.

Re: [TLS] AD Review of draft-ietf-tls-tls13

> On May 15, 2017, at 3:38 PM, Russ Housley wrote: > >>> I don't see an explanation of why it is out-of-scope. The reference >>> is just to RFC5280, which seems odd. I would expect the reference to >>> be to something that explains why it is out-of-scope. > > I think the the separation of cer

Re: [TLS] AD Review of draft-ietf-tls-tls13

Just commenting on Section 4.2 … > > > 3. Section 4.2. > > > >"In general, detailed certificate validation procedures are out of > >scope for TLS (see [RFC5280]). This section provides TLS-specific > >requirements." > > > > I don't see an explanation of why it is out-of-scope. The

Re: [TLS] AD Review of draft-ietf-tls-tls13

Hi Eric, Thanks for your response. Sorry for the delay, I'v been traveling. The responses sound good, I do have a clarification and will respond inline. On Sat, May 13, 2017 at 2:09 PM, Eric Rescorla wrote: > Hi Kathleen, > > Thanks for your review. > > >> 1. Since this is going for IETF last c

Re: [TLS] AD Review of draft-ietf-tls-tls13

Hi Kathleen, Thanks for your review. > 1. Since this is going for IETF last call soon and there has been > review of the draft (workshop, but is clearly ongoing from the list > discussions), should the first sentence of the Introductions be > removed? > >DISCLAIMER: This is a WIP draft of TL