Re: [Uta] [saag] UTA WG report

[Keith Moore <[e-mail]>]

On 03/30/2017 05:26 PM, Jim Fenton wrote:
> [removing saag list because this is probably at a lower level of 
> detail than appropriate there. But feel free to add them if I'm wrong]
>
> My sense that there is a "BCP part" to the draft is probably more 
> clearly stated that there are really two different things described in 
> the draft, as the draft itself says in section 5 paragraph 4:
>
> "Note that security directives are a separate mechanism from minimum 
> confidentiality assurance levels."
>
> It appears to me that it's possible independently to implement/deploy 
> confidentiality assurance levels and security directives. So I would 
> split them up into separate documents.
>
> I still see confidentiality assurance levels as more of a BCP-ish 
> mechanism. It defines particular security requirements for MUA-MTA 
> connections to meet Confidentiality Assurance Level (CAL) 1, and 
> different ones for CAL 0. That seems like a best current practice to me.

Disagree.  Compliance with both the CAL and the security directives are 
a matter of protocol interaction between client and server. The only 
real difference is that in the CAL case, no new protocol features need 
to be defined (we're talking about new client interactions with existing 
server features); whereas for security directives there are changes to 
the protocols used by the servers. But in both cases these are protocol 
interactions.

A client's compliance with this protocol can be tested, and the protocol 
could reasonably advance to full standard (or not) based on such testing 
with multiple client implementations.   So I don't understand why BCP is 
more appropriate.

(But if that's what IESG wanted to do, I wouldn't fight it.   Let's just 
try to not let this question delay the document, ok?)

I also believe it would be more confusing to have two documents for 
confidentiality assurance level and security directives, because both of 
them require the client to disconnect if the requirements aren't met.    
But I'll think about that some more.   The current document is longer 
than I'd like, and there's a tendency for readers to get overwhelmed by 
long documents and miss things.   But when readers have to read multiple 
documents in order to implement changes, it usually makes the problem 
worse.

> I think we should tease these two things apart into separate 
> specifications so that it's clear you can have one or the other or both.

The only benefit I can see to that is that server implementors and MSPs 
and server implementors wouldn't have to read the CAL document [*], 
since that's all done on the user end.   Offhand, I don't see why it's 
beneficial for an MUA to be able to implement either CAL or security 
directives or both.  The two features were designed to work together.

[*] except that MSPs would still need to know about CAL for customer 
support reasons

Keith