Re: [TLS] Extensibility in SCVP draft

[Ashley Kopman]

That is a good suggestion. I will look into expanding on the text to address 
this concern.

Thank you,

Ashley

> On Jul 26, 2022, at 1:33 PM, Rob Sayre  wrote:
> 
> On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman  > wrote:
> 
> Are you concerned that if additional validation extensions were added it 
> could lead to multiple validations for the same handshake? If that is the 
> case, I believe that this is somewhat mitigated by it being optional for the 
> server to choose to perform the SCVP validation. If the TLS server were to 
> receive multiple validation requests it could potentially select to perform 
> only one.
> 
> Hi,
> 
> It's correct that this is my concern, and I thought you might consider adding 
> text along these lines to the document.
> 
> I don't feel strongly about this issue, though.
> 
> thanks,
> Rob
> 
> 
> 
> 
>  
> 
> If I have missed your point, please let me know.
> 
> Thank you,
> Ashley Kopman
> 
>> On Jul 25, 2022, at 11:30 PM, Rob Sayre > > wrote:
>> 
>> Hi,
>> 
>> Doesn’t it depend on whether it would be easier to do this select* or deal 
>> with multiple validations in the same message? No one’s said that exactly 
>> afaik, but I haven’t watched the meeting yet.
>> 
>> thanks,
>> Rob
>> 
>> * in the recent past, the stuff I’ve worked on has made this easy, but I 
>> agree they’re a bit annoying.
>> 
>> On Mon, Jul 25, 2022 at 13:25 Russ Housley > > wrote:
>> I was thinking the same thing during the presentation.  An extension for 
>> SCVP seems fine to me.  Then in the future, if another validation comes 
>> along some day, a new extension can be assigned for that protocol.
>> 
>> Russ
>> 
>> > On Jul 25, 2022, at 4:13 PM, Martin Thomson > > > wrote:
>> > 
>> > Take this:
>> > 
>> > struct {
>> > PathValidationType path_validation_type;
>> > select (path_validation_type) {
>> >  case scvp: SCVPValidationRequest;
>> > } request;
>> > } PathValidationRequest;
>> > enum { scvp(1), (255) } PathValidationType;
>> > 
>> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
>> > making this less generic.  If we want a different validation design, then 
>> > another extension can be defined.  We have a poor track record of being 
>> > able to use these nested extension points and it will be more efficient to 
>> > just put the SCVP pieces in their own extension.
>> 
>> ___
>> TLS mailing list
>> TLS@ietf.org 
>> https://www.ietf.org/mailman/listinfo/tls 
>> 
> 

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

Re: [TLS] Extensibility in SCVP draft

[Rob Sayre]

On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman 
wrote:

>
> Are you concerned that if additional validation extensions were added it
> could lead to multiple validations for the same handshake? If that is the
> case, I believe that this is somewhat mitigated by it being optional for
> the server to choose to perform the SCVP validation. If the TLS server were
> to receive multiple validation requests it could potentially select to
> perform only one.
>

Hi,

It's correct that this is my concern, and I thought you might consider
adding text along these lines to the document.

I don't feel strongly about this issue, though.

thanks,
Rob






>
> If I have missed your point, please let me know.
>
> Thank you,
> Ashley Kopman
>
> On Jul 25, 2022, at 11:30 PM, Rob Sayre  wrote:
>
> Hi,
>
> Doesn’t it depend on whether it would be easier to do this select* or deal
> with multiple validations in the same message? No one’s said that exactly
> afaik, but I haven’t watched the meeting yet.
>
> thanks,
> Rob
>
> * in the recent past, the stuff I’ve worked on has made this easy, but I
> agree they’re a bit annoying.
>
> On Mon, Jul 25, 2022 at 13:25 Russ Housley  wrote:
>
>> I was thinking the same thing during the presentation.  An extension for
>> SCVP seems fine to me.  Then in the future, if another validation comes
>> along some day, a new extension can be assigned for that protocol.
>>
>> Russ
>>
>> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  wrote:
>> >
>> > Take this:
>> >
>> > struct {
>> > PathValidationType path_validation_type;
>> > select (path_validation_type) {
>> >  case scvp: SCVPValidationRequest;
>> > } request;
>> > } PathValidationRequest;
>> > enum { scvp(1), (255) } PathValidationType;
>> >
>> > This adds a layer of extensibility that doesn't do a lot.  Please
>> consider making this less generic.  If we want a different validation
>> design, then another extension can be defined.  We have a poor track record
>> of being able to use these nested extension points and it will be more
>> efficient to just put the SCVP pieces in their own extension.
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Extensibility in SCVP draft

[Ashley Kopman]

Rob,

I apologize, I am not sure that I fully understand your question. I originally 
created the structure of path_validation_type to make it easier in the future 
to potentially expand the extension to use other protocols for path validation. 
But Martin, Rich and Russ pointed out that this likely adds an unnecessary 
layer of nesting complexity that may never be utilized. 

Are you concerned that if additional validation extensions were added it could 
lead to multiple validations for the same handshake? If that is the case, I 
believe that this is somewhat mitigated by it being optional for the server to 
choose to perform the SCVP validation. If the TLS server were to receive 
multiple validation requests it could potentially select to perform only one.

If I have missed your point, please let me know.

Thank you,
Ashley Kopman

> On Jul 25, 2022, at 11:30 PM, Rob Sayre  wrote:
> 
> Hi,
> 
> Doesn’t it depend on whether it would be easier to do this select* or deal 
> with multiple validations in the same message? No one’s said that exactly 
> afaik, but I haven’t watched the meeting yet.
> 
> thanks,
> Rob
> 
> * in the recent past, the stuff I’ve worked on has made this easy, but I 
> agree they’re a bit annoying.
> 
> On Mon, Jul 25, 2022 at 13:25 Russ Housley  > wrote:
> I was thinking the same thing during the presentation.  An extension for SCVP 
> seems fine to me.  Then in the future, if another validation comes along some 
> day, a new extension can be assigned for that protocol.
> 
> Russ
> 
> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  > > wrote:
> > 
> > Take this:
> > 
> > struct {
> > PathValidationType path_validation_type;
> > select (path_validation_type) {
> >  case scvp: SCVPValidationRequest;
> > } request;
> > } PathValidationRequest;
> > enum { scvp(1), (255) } PathValidationType;
> > 
> > This adds a layer of extensibility that doesn't do a lot.  Please consider 
> > making this less generic.  If we want a different validation design, then 
> > another extension can be defined.  We have a poor track record of being 
> > able to use these nested extension points and it will be more efficient to 
> > just put the SCVP pieces in their own extension.
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 

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

Re: [TLS] Extensibility in SCVP draft

[Rob Sayre]

Hi,

Doesn’t it depend on whether it would be easier to do this select* or deal
with multiple validations in the same message? No one’s said that exactly
afaik, but I haven’t watched the meeting yet.

thanks,
Rob

* in the recent past, the stuff I’ve worked on has made this easy, but I
agree they’re a bit annoying.

On Mon, Jul 25, 2022 at 13:25 Russ Housley  wrote:

> I was thinking the same thing during the presentation.  An extension for
> SCVP seems fine to me.  Then in the future, if another validation comes
> along some day, a new extension can be assigned for that protocol.
>
> Russ
>
> > On Jul 25, 2022, at 4:13 PM, Martin Thomson  wrote:
> >
> > Take this:
> >
> > struct {
> > PathValidationType path_validation_type;
> > select (path_validation_type) {
> >  case scvp: SCVPValidationRequest;
> > } request;
> > } PathValidationRequest;
> > enum { scvp(1), (255) } PathValidationType;
> >
> > This adds a layer of extensibility that doesn't do a lot.  Please
> consider making this less generic.  If we want a different validation
> design, then another extension can be defined.  We have a poor track record
> of being able to use these nested extension points and it will be more
> efficient to just put the SCVP pieces in their own extension.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Extensibility in SCVP draft

[Russ Housley]

I was thinking the same thing during the presentation.  An extension for SCVP 
seems fine to me.  Then in the future, if another validation comes along some 
day, a new extension can be assigned for that protocol.

Russ

> On Jul 25, 2022, at 4:13 PM, Martin Thomson  wrote:
> 
> Take this:
> 
> struct {
> PathValidationType path_validation_type;
> select (path_validation_type) {
>  case scvp: SCVPValidationRequest;
> } request;
> } PathValidationRequest;
> enum { scvp(1), (255) } PathValidationType;
> 
> This adds a layer of extensibility that doesn't do a lot.  Please consider 
> making this less generic.  If we want a different validation design, then 
> another extension can be defined.  We have a poor track record of being able 
> to use these nested extension points and it will be more efficient to just 
> put the SCVP pieces in their own extension.

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

Re: [TLS] Extensibility in SCVP draft

[Salz, Rich]

>  We have a poor track record of being able to use these nested extension 
> points and it will be more efficient to just put the SCVP pieces in their own 
> extension.

Yes!  For example, the "SNI hostname" is such a nested construct, nobody uses 
anything other than "a hostname string."

Wrapping in substructs requires pre-compute, buffering, etc.  Just say what you 
mean :)

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

[TLS] Extensibility in SCVP draft

[Martin Thomson]

Take this:

struct {
 PathValidationType path_validation_type;
 select (path_validation_type) {
  case scvp: SCVPValidationRequest;
 } request;
} PathValidationRequest;
enum { scvp(1), (255) } PathValidationType;

This adds a layer of extensibility that doesn't do a lot.  Please consider 
making this less generic.  If we want a different validation design, then 
another extension can be defined.  We have a poor track record of being able to 
use these nested extension points and it will be more efficient to just put the 
SCVP pieces in their own extension.

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